05:55 <narmstrong> aklimov: what’s the patch associated with this commit ?

07:32 <valpackett> aklimov: hm, could https://github.com/linux-surface/kernel/commit/94978c652301fe7916efa62e59f25fe9935bf87c be a hack for exactly that issue?

09:41 <aklimov> narmstrong: sorry, i probably listed some commit from -next, it is just 172320f5ead5 clk: qcom: gdsc: Update the status poll timeout for GDSC

09:42 <aklimov> narmstrong: should be the first top commit on gdsc.c

09:43 <aklimov> valpackett: seems interesting, testing

10:57 <aklimov> valpackett: works like a charm, thank you. 10 sequential boots with display always coming up

10:58 <aklimov> valpackett: do you know if there is a discussion or report on the maillist?

11:29 <konradybcio> aklimov I think I've root-caused it. I sent you an alternative workaround on email, please give it a shot

11:41 <krzk> lumag: konradybcio: don't accept patches with cleanup.h, pleasde

11:41 <krzk> What Kathiravan sent is pure junk

11:41 <krzk> Not mentioning that simple and obvious code of get+put is now changed to unspecific big scope of __free with wrong style

12:17 <lumag> krzk: could you please comment on the ML (I'm sorry if you already did)

12:29 <krzk> Yeah, I also did, but emails can get lost

15:01 <aklimov> konradybcio: thanks, let me test it

17:19 <valpackett> aklimov: (I didn't know about any discussions, i just knew about the surface pro x fork because i'm kinda thinking about getting one of those)

19:25 <aklimov> konradybcio: as far as I can trust my eyes it didn't help, still sometimes fails

19:25 <aklimov> for the record the log is here https://paste.debian.net/1409289/

19:26 <konradybcio> the previous patch shouldn't help given you have an eDP display though..

19:29 <aklimov> previous - the one valpackett pointed to?

19:30 <konradybcio> yes

19:30 <aklimov> well, i am returning back to testing it then, but within 10 boots it definetely fails at least 50% of time

19:31 <aklimov> with that patch there were no problem at all

19:33 <aklimov> konradybcio: with the fix you sent me the rate of sucessfull boots probably were higher, not sure, but on the 4th attempts it failed with the same log (as on paste debian)

19:36 <sgerhold> konradybcio: the regulator-fixed-domain thingy might keep the MMCX permanently on and at nom nom, that thing looks super bugged

19:36 <konradybcio> sgerhold: the patch I sent to Alexey simply bumped up the required-opps under dispcc to nomnom because that's apparently what the running config of disp_pll0 requires

19:37 <aklimov> interesting, now screen fails with the fix valpackett pointed to, the difference is that I disconnected type-c power and running on battery

19:38 <aklimov> konradybcio: your fix actually might work if I keep type-c power cable in, needs more testing

19:39 <konradybcio> please tell me that doesn't make a difference

19:40 <konradybcio> aklimov: please also mention explicitly whether the mdss gdsc is stuck at off vs the display is off

19:40 <konradybcio> the latter your uefi may mess with in case the panel power grid is not properly described

19:42 <aklimov> mdss gdsc is stuck at off or on, i've seen both messages with this issue, display doesn't show anything when this happens

19:57 <konradybcio> they may be separate - if it's stuck at off, it's likely that MMCX is off (or not at a high enough level for that PLL to function)

20:00 <sgerhold> konradybcio: fwiw I'm not sure if the dispcc required-opps will really apply for the gdsc, that thing probably goes through the genpd subdomain stuff which is separate

20:00 <sgerhold> why would it turn on the pll immediately together with the gdsc though?

20:50 <konradybcio> required-opps runs before the device is activated, no?

20:56 <bamse> konradybcio: that (pll0 depending on nom during boot) seems like a quite likely explanation to the whole problem

20:59 <bamse> there has been arguments presented for having the clock controllers voting for the power that the plls requires...i think that that sounds reasonable in theory, but no one has presented the patches yet

21:00 <bamse> for now though, i'd be happy to take the required-opps = <&nom> if that takes care of the problem

21:42 <sgerhold> konradybcio: I’m not sure if the „device“ really gets activated by the gdsc. There is the subdomain relationship, but this is a separate code path that directly associates the gdsc power domain with MMCX as parent

22:34 <konradybcio> And dispcc is runtimepm-enabled with it being the provider.. i would assume it gets enabled but it may be worth checking

23:06 <aklimov> konradybcio: after some rebuilding and verifying, I'd say that the fix you sent doesn't help regardless of type-c power cable plugged in or not

23:06 <aklimov> mdss_gdsc status stuck at 'off' is there