<bamse>
arnd: you're right, that would been better suited for v6.9-fixes...i'd prefer to avoid rebasing the 6.10 branch at this time though, let me check with the team on the overall state of v6.9...
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
<arnd>
bamse: ok, I've already merged your tags/qcom-arm64-for-6.10, so I also wouldn't want to rebase. I'll hold off merging tags/qcom-arm64-fixes-for-6.9-2 for today then so you can amend it if you decide to add more patches or you let me know if they turn out not to be needed
<cwabbott>
bamse: arnd: you've missed "arm64: dts: qcom: sm8650: Fix GPU cx_mem size" in your devicetree pull
<cwabbott>
it's important to get that in for 6.10 to avoid having to deal with broken devicetrees forever
<marc|gonzalez>
krzk: for the qcom,msm8998-venus compatible, can I do what bryanodonoghue suggested: that is simply add the compatible string to Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml instead of creating a whole new Documentation/devicetree/bindings/media/qcom,msm8998-venus.yaml ?
<krzk>
marc|gonzalez: are the properties the same?
ungeskriptet has joined #linux-msm
<marc|gonzalez>
krzk: Same, except interconnects is not supported yet (on the TODO list)
<aka_[m]>
konradybcio: don't you have 8998 icc driver?
<marc|gonzalez>
aka_[m]: the work has been done, but there remains 90% of the work: getting it accepted by the gate keepers :p
ungeskriptet has joined #linux-msm
<krzk>
marc|gonzalez: support or not is driver aspect, not bindings.
<krzk>
marc|gonzalez: they should be merged, no need to create unnecessary binding files for the same stuff
ungeskriptet has quit []
<marc|gonzalez>
krzk: oh I thought you would go the other way, good to know
<marc|gonzalez>
I think I saw a syntax error when I had the interconnect property in the DT... Will have to investigate
ungeskriptet has joined #linux-msm
<marc|gonzalez>
krzk: I don't understand Konrad's remark about the video-decoder sub nodes. Last year, you wrote "Once all bindings are converted to new one (clocks in main/parent node), then we can drop the children and instantiate devices as MFD."
<marc|gonzalez>
As far as I can tell, this conversion has not happened at the moment, right?
<marc|gonzalez>
Should I change Stan's email address while I'm at it, or does a totally unrelated change risk side-tracking the series?
<marc|gonzalez>
svarbanov: watchu think?
<bamse>
arnd: okay, thanks
* marc|gonzalez
waves at bamse
<bamse>
cwabbott: i have picked that up in my local tree, aimed at 6.10...
<bamse>
marc|gonzalez: good morning
<marc|gonzalez>
my morning is long gone, westerner :D
<svarbanov>
marc|gonzalez, which email to change?
<marc|gonzalez>
svarbanov: in Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml there is a Stanimir Varbanov <stanimir.varbanov@linaro.org>
<marc|gonzalez>
Though it might be pointless to maintain a maintainer email in every binding document
<marc|gonzalez>
Whoever thought that would scale?
<cwabbott>
bamse: ok, thx
<marc|gonzalez>
I guess it's because bindings might be distributed outside the linux project?
<marc|gonzalez>
svarbanov: forget it, it makes no sense to change just that one, when there are 9 instances.
<svarbanov>
marc|gonzalez, hmm, yep, the email is invalid. Maybe be have to send a patch to remove the mail or change it, have to see
<marc|gonzalez>
There are 11 instances of the old address in 6.9-rc1 FWIW ;)
f_ is now known as f_[mtrx]
f_[mtrx] is now known as f_
adomerle has joined #linux-msm
aedancullen has joined #linux-msm
AffeNull[m] has joined #linux-msm
ajhalaney[m] has joined #linux-msm
alfayt[m] has joined #linux-msm
alikateshethey[m] has joined #linux-msm
anuw[m] has joined #linux-msm
ArianK16a[m] has joined #linux-msm
blacksilver[m] has joined #linux-msm
bzy-080408[m] has joined #linux-msm
Leandro[m]12 has joined #linux-msm
cmeerw[m] has joined #linux-msm
Degdag_Med[m] has joined #linux-msm
dehirt5212[m] has joined #linux-msm
danylo1 has joined #linux-msm
DylanVanAssche has joined #linux-msm
elektrino[m] has joined #linux-msm
eliaselias[m] has joined #linux-msm
exkc has joined #linux-msm
felixwither[m] has joined #linux-msm
FieryFlames[m] has joined #linux-msm
flamingradian[m] has joined #linux-msm
Adrian[m] has joined #linux-msm
go4godvin has joined #linux-msm
jrole_8tst-j[m] has joined #linux-msm
JIaxyga[m] has joined #linux-msm
JoelSelvaraj[m] has joined #linux-msm
go4godvin is now known as Guest2698
jrfern[m] has joined #linux-msm
KieranBingham[m] has joined #linux-msm
konradybcio has joined #linux-msm
z3ntu has joined #linux-msm
luka177[m] has joined #linux-msm
Marijn[m] has joined #linux-msm
Steve[m]123 has joined #linux-msm
matrix638[m] has joined #linux-msm
maxim[m] has joined #linux-msm
minecrell[m] has joined #linux-msm
Caterpillar has joined #linux-msm
mirsal has joined #linux-msm
Mis012[m] has joined #linux-msm
MollySophia[m] has joined #linux-msm
mothenjoyer69 has joined #linux-msm
nergzd723 has joined #linux-msm
Newbyte has joined #linux-msm
nick1343[m] has joined #linux-msm
nta has joined #linux-msm
panioluka[m] has joined #linux-msm
Prawn[m] has joined #linux-msm
<marc|gonzalez>
Is 2001:470:1af1:101::1:X a special IPv6 address?
valida-69[m] has joined #linux-msm
RayyanAnsari[m] has joined #linux-msm
Nia[m] has joined #linux-msm
exkcmoeadmin[m] has joined #linux-msm
sepkov[m] has joined #linux-msm
sergi has joined #linux-msm
strongtz[m] has joined #linux-msm
underpantsgnome[m] has joined #linux-msm
TJ[m] has joined #linux-msm
Tooniis[m] has joined #linux-msm
travmurav[m] has joined #linux-msm
uclydde[m] has joined #linux-msm
valentine has joined #linux-msm
vknecht[m] has joined #linux-msm
MatrixTravelerbot[m] has joined #linux-msm
wfranken[m] has joined #linux-msm
xtex[m] has joined #linux-msm
ywnkmn[m] has joined #linux-msm
Guest2698 is now known as go4godvin
<bryanodonoghue>
marc|gonzalez looks fine
<marc|gonzalez>
bryanodonoghue: cool, I'll send a formal submission
<marc|gonzalez>
bryanodonoghue: dunno if you saw anything useful in the debug decoder output?
<bryanodonoghue>
best thing to do is to ping dikshita
<bryanodonoghue>
dikshita agarwal and ask her
<marc|gonzalez>
Ping her on the debug output?
<robher>
marc|gonzalez: Distributed outside the kernel was one reason (now in u-boot for example). The other was entries in MAINTAINERS for bindings was random and would require manual review to require an entry. That being said, it's so many drive-by submissions and maintainers (and then dead emails), I do think about just dropping maintainers from the bindings.
aklimov_ has joined #linux-msm
<robher>
bryanodonoghue: I'm waiting for the advanced course: Get you bindings accepted in less than 4 iterations
<marc|gonzalez>
the crucial command is the one that tests just my binding. I don't have a 64-core system with 2TB of RAM like you kernel madmen! :)
<marc|gonzalez>
make -j16 dt_binding_check DT_SCHEMA_FILES=media/qcom,msm8996-venus.yaml
<krzk>
I should be able to get to 4 iterations :)
<marc|gonzalez>
One might think copy/pasting an existing binding would put a submission on the fast-track, but one would be wrong :p
Caterpillar has quit [Quit: Konversation terminated!]
<krzk>
same for every driver...
<marc|gonzalez>
probably, though it's not as common to dupe driver code.
<marc|gonzalez>
but I remember banging my head against the wall working with maz on an IRQ handler
<krzk>
yeah, but that's no difference here. You take something with technical debt, you grow total technical debt, so Linux community always pushed back on such contributions.
<krzk>
That's the difference between contributing to downstream, where you can copy whatever you wish and keep multiplying technical debt, and upstream.
<marc|gonzalez>
I hear you
<marc|gonzalez>
Sounds like once in a while, it would be good to "level" the code
<krzk>
anyway, your case was obvious that new file was redundant :/
<krzk>
but that's your task to check
<marc|gonzalez>
I did not expect less from you krysztof
<marc|gonzalez>
I don't even know where I would have found the information that I should not have duped the file...
<krzk>
hm, not sure if submitting patches tells this, but several guides on upstreaming are saying: do not add new driver if you can extend existing one for new device
<marc|gonzalez>
As I said, adding the compatible to the old file was actually my first patch
<marc|gonzalez>
then I somehow convinced myself that this was wrong
<marc|gonzalez>
I mean venus is mostly the same of 42 qcom SoCs
<marc|gonzalez>
yet they all have a bindings file
<marc|gonzalez>
If everyone does it wrong, how can I noob do it right?
<marc|gonzalez>
gotta run, can move on to new subsystems this week (hdmi, interconnect, need to scan the todo list)
<aka_[m]>
<marc|gonzalez> "If everyone does it wrong, how..." <- great to see someone sharing similar mindset
<aka_[m]>
konradybcio: any progress on audio?
telent has quit []
telent has joined #linux-msm
<JIaxyga[m]>
<aka_[m]> "konradybcio: any progress on..." <- about sm6115?