13:50 <bamse> konradybcio, calebccff: scrolled back and saw your question about sm8150 mdss...there are some patches from microsoft from december(?), the problem is that they didn't work for me

13:50 <bamse> konradybcio, calebccff: i did some research and it seems to be the same problem as i see on sc8180x, that we must hold vddmx at least at nominal at all time

14:06 <calebccff> bamse: huh, that looks fun... Would that also fix the ahb stuck clocks we see on sdm845?

14:10 <konradybcio> Nominal seems rather high.. I wonder what downstream does..

14:58 <bamse> calebccff: i think you're referring to the problem coming when you boot without clk_ignore_unused...that's a separate problem and in the discussion following my proposed fix, we concluded that we should get rid of clk_ignore_unused (i.e. always have it and rely on sync_state instead)

14:59 <bamse> konradybcio: nom is high, the problem is that the mdss_ahb_clk is ticking so fast due to the bootsplash that it's required...once the mdss driver kicks in, we can use the opp tables to adjust it together with the clock

15:43 <calebccff> bootsplash strikes again!

15:45 <Mis012[m]> laughs in no display support in u-boot

15:46 <Mis012[m]> (secretly) cries in no display support in u-boot

16:40 <bamse> z3ntu: did you test v14 of my lpg patches? could you provide a t-b, or perhaps even invest the time towards providing a r-b?

16:41 <bamse> Marijn[m]: ^^?

16:42 <z3ntu> bamse: I did test v12 which worked fine on pm8941/msm8974. I can re-test v14 :)

16:43 <Marijn[m]> bamse: it's on my todo list but I've been living under a proverbial rock (when it comes to mainline) lately

16:43 <bamse> thanks, just would like to make sure that when the maintainer see the patch that it has some positive feedback

16:45 <Marijn[m]> I was hoping to get to it after rebasing our Sony Loire and Nile platforms on 5.18 and upstreaming some more patches, but of course it doesn't work anymore...

16:45 <Marijn[m]> I'm surprised the series is in radio silence where at first it got quite some attention

16:46 <bamse> Marijn[m]: one interpretation is that everyone is happy, which i hope is the case ;)

16:47 <Marijn[m]> bamse: let's hope some r-b + t-b get the whole thing merged ^^

16:48 <Marijn[m]> I also shouldn't forget sending the sdm660 config in that case

16:56 <bamse> Marijn[m]: well, lack of feedback could be interpreted either way by the maintainer...so getting some in place would rule that out

16:56 <bamse> Marijn[m]: right, once we have the base driver we have a bunch of pmics to add

17:14 <Marijn[m]> And unfortunately we have some weird platforms with a "PBS" thing for the LPG

17:16 <z3ntu> I also briefly looked into lpg on pmi632 but it's also a bit weird there

17:17 <Marijn[m]> z3ntu: it's on our sm6125 SoC specifically, so could be pmi632 or some close variant indeed

17:18 <z3ntu> I see ppg_sdam on pmi632 which iirc is the way it stores the lpg patterns there https://github.com/FairphoneMirrors/android_kernel_fairphone_sdm632/blob/master/arch/arm64/boot/dts/qcom/pmi632.dtsi#L575

17:18 <z3ntu> ah and also pmi632_pbs_client3 which seems what you meant

17:25 <Mis012[m]> no hits for ppg

17:26 <Mis012[m]> lots of hits for PBS

17:27 <z3ntu> bamse: sent a tested-by :)

17:27 <z3ntu> Please also pick up https://lore.kernel.org/linux-arm-msm/20220421211936.345168-1-luca@z3ntu.xyz/ for 5.19 if possible

17:28 <z3ntu> found some details on sdam/pbs here https://lore.kernel.org/linux-arm-msm/960f1519-f830-583a-ff10-039d7de83335@codeaurora.org/

17:28 <z3ntu> sdam driver itself is upstream already

17:35 <bamse> z3ntu: looks reasonable, and there's still time for v5.19

17:36 <bamse> z3ntu: ahh nice, didn't know we already had a sdam driver...but yeah we have some stuff that needs to take a different path on sdam targets

17:41 <Mis012[m]> hmkay...

17:41 <Mis012[m]> would be nice to have `#define`s for that

17:41 <Mis012[m]> not least of which because said datasheet is probably not exactly public

17:42 <bamse> Marijn[m]: i am not able to provide you with that...and it seems to differ from platform to platform

17:42 <bamse> sorry pmic to pmic

17:44 <Mis012[m]> for pmi632

17:47 <Mis012[m]> can also provide a syntax file for gedit

18:15 <calebccff> bamse: no luck with LPG on the OnePlus 6

18:16 <calebccff> assuming I haven't made any silly mistakes.. https://p.calebs.dev/37f12f

19:07 <bamse> calebccff: looks reasonable to me, what's the outcome?

19:09 <calebccff> bamse: nothing happens at all

19:09 <calebccff> i've maxed out the multi_intensity and brightness values, anything I'm missing?

19:10 <calebccff> fwiw these are the changes OnePlus did in downstream devicetree: https://p.calebs.dev/d05002@raw

19:12 <bamse> calebccff: maxed out means max_brightness, right?

19:13 <bamse> or perhaps max_intensity is [0,256)

19:13 <bamse> ?

19:13 <calebccff> bamse: yeah, here's sysfs https://p.calebs.dev/d7ac24@raw

19:14 <calebccff> i checked the docs and multi_intensity is apparently 0 to max_brightness, it's scaled automatically

19:14 <calebccff> led_brightness = brightness * multi_intensity/max_brightness

19:16 <bamse> calebccff: and the led stays off?

19:16 <bamse> calebccff: and it worked with a previous iteration of the patches? or could we be missing something external to the driver?

19:38 <calebccff> bamse: i think i tested some older version which also didn't work, it's been a while though

19:49 <bamse> calebccff: i will interpret that as we're missing something for driving your rgb off pmi8998

19:50 <bamse> calebccff: i don't remember if i tested the last version on rb3 (db845c)...but previous revisions worked there

21:05 <calebccff> bamse: hmm yeah, I think deathmist1 also had it working on the OnePlus 5 on prior revisions but not recently