steev has quit [Read error: Connection reset by peer]
steev has joined #linux-msm
dianders_ has quit [Remote host closed the connection]
dianders has joined #linux-msm
minecrell has quit [Quit: :( ]
minecrell has joined #linux-msm
minecrell has quit [Quit: :( ]
minecrell has joined #linux-msm
enok has quit [Read error: Connection reset by peer]
enok has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
<bamse>
Danct12: really appreciate that, unfortunately it's hard to merge treewide changes
elder_ has quit [Read error: Connection reset by peer]
robclark has quit [Ping timeout: 480 seconds]
arnd_ has quit [Read error: Connection reset by peer]
robclark has joined #linux-msm
jstultz has quit [Ping timeout: 480 seconds]
arnd_ has joined #linux-msm
elder_ has joined #linux-msm
jstultz has joined #linux-msm
<Danct12>
bamse, sorry for asking, but should i make a patchset with all of the changes for each maintainer or send them individually?
<bamse>
Danct12: given that there's no dependency between them it's better to just send them separately
<bamse>
Danct12: if you group them, each of the 4 maintainers would have to conclude by themselves that they can pick their patch in the series without caring about the others
<bamse>
Danct12: and don't feel sorry for asking, it's a good question that i wish more people would ask ;)
thara has quit [Read error: Connection reset by peer]
thara has joined #linux-msm
<Danct12>
i've splitted the patch for both arm32/arm64
<Marijn[m]>
> it's a good question that i wish more people would ask ;)
<Marijn[m]>
Hehe next time I'll submit wled/driver changes separate from dts changes :)
<Marijn[m]>
* > it's a good question that i wish more people would ask ;)
<Marijn[m]>
Hehe next time I'll submit wled/driver changes separate from dts changes - except that they are related timing-wise ;)
anholt_ has quit [Remote host closed the connection]
anholt has joined #linux-msm
<bamse>
Marijn[m]: if i can merge the dts patches without having to care about the driver changes, please do
<bamse>
Marijn[m]: if on the other hand i need to sync with Daniel to make sure that he has merged the driver changes before, then it's more work for me
<bamse>
well in particular it's an effort that's not clearly communicated by putting them in a series
svarbanov has quit [Ping timeout: 480 seconds]
<Marijn[m]>
bamse: I may have not been super clear about the time dependency in this series, but decided not to mention it in order to not cause a revert-storm expecting the driver changes to also reach -next and the stable trees at about the same moment
<Marijn[m]>
I think I put something in along the lines of "now that the driver does abc we can change the DT to do/drop xyz", implying that "abc" was a change performed in the driver part of the series
<Marijn[m]>
But I haven't really found a good workflow nor docs for getting these sort of patches done
<Marijn[m]>
Except splitting them in two series, waiting for the driver part to get merged before submitting the DT, and pointing to it with a link
<bamse>
Marijn[m]: i think that's the best we can do, either you take the responsibility of timing things or you express the dependency in the cover letter
<bamse>
Marijn[m]: and i can assure you that i appreciate the prior :)
<Marijn[m]>
bamse: Checking for conflicts now: it seems the xiaomi-gemini got its backlight enabled right around the same time my patch for moving num-strings from pmi8994 to sony-tone got applied. That device better uses all four strings or it'll run into the ovp interrupt
<Marijn[m]>
In any case removing `enabled-strings` (from pmi8994) without the wled driver change (that has been accepted but not landed yet) will make these devices only turn on string `0`, since wled4/5 don't have a default array of 0,1,2,3 set 🤦♂️
<Marijn[m]>
> and i can assure you that i appreciate the prior :)
<Marijn[m]>
I guess that's tricky to do for external contributors, when wading through all the upstream repositories _and branches and tags_. At least I'm not sure when is soon enough - when it reached your `arm64-5.xx` branch?
<Marijn[m]>
(The other way around for the driver change, of course)
<Marijn[m]>
Fwiw I assumed this ordering was implied when driver changes are sent together with DT changes as one set - especially when the DT changes are ordered towards the end 😉
<bamse>
right, sending it together as a series implies an ordering requirement
<bamse>
if i end up not following that, then that's a bug on my side
<bamse>
then again, we still have the problem that Daniel and my trees might be merged in the wrong order into Torvalds' tree
<bamse>
and for that i don't have a solution
<Marijn[m]>
Yeah exactly - bar waiting for it to reach Torvalds tree and submitting it after that - but the delay between submitting and reaching there may be substantial
<Marijn[m]>
Anyway, it doesn't look like we're in too much trouble
<Marijn[m]>
Only pmi8994 devices (xiaomi-gemini and the Sony Tone series) will run around with just string 0 enabled for a bit
<bamse>
could have been worse
<Marijn[m]>
The rest of the patches are fine to be applied regardless - `pm660l_wled` doesn't even have a single user just yet
<Marijn[m]>
(ie. the `eternal` typo fix, and removing board-specific electrical config needed to happen regardless of the driver)
<Marijn[m]>
^ that may have actually contributed to the confusion of these patch(es) depending on the rest of the series or not
pevik_ has quit [Quit: Lost terminal]
<Marijn[m]>
Anyway, for something else: I see you submitted some extra DPU INTF interrupt ranges, but they are not used (ie. turned on) anywhere right? I'm working on a similar change for the tear block that is now moved from PP to the INTF, which requires an extra range here too, and I added index initialization so that there isn't this fragile "keep in the same order" dependency between `dpu_hw_intr_reg` and `dpu_intr_set`. Perhaps that should be
<Marijn[m]>
submitted already to prevent future conflicts, also given that implementing "INTF TE" has proven a bit more work than expected?
<bamse>
the current method is way better than what it was a few months back, but there's definitely room for some really strange errors
<Marijn[m]>
Let's not speak of how it was implemented in techpack... Except that that's what I have to use as reference implementation
<bamse>
there's some more thing that has to fall in place for that patch to be used, so i shouldn't have posted it yet...but i think we have 2-3 different projects that would benefit from it
pevik_ has joined #linux-msm
<Marijn[m]>
For us pretty much all the Sony devices beyond sdm845 would benefit from INTF TE - display refuses to work without it - I'm pretty much holding back our entire mainlining operation by not finishing it ^^
<Marijn[m]>
In any case, the reason I'm mentioning this: maybe you happen to know if there are more boards/projects with cmdmode displays out there that need this implemented - perhaps someone else is working it already as well?
<bamse>
Marijn[m]: i'm not aware of any work in that area
<Marijn[m]>
bamse: Alright, I'll keep working on it then :). Do get in touch if the need shows up but our patches haven't reached the list yet
pevik_ has quit [Ping timeout: 480 seconds]
flto has quit [Quit: Leaving]
flto has joined #linux-msm
flto has quit [Remote host closed the connection]
flto has joined #linux-msm
flto has quit [Read error: Connection reset by peer]