12:18 <z3ntu1> So for some reason on sm6350/sm7225 the mdss_gdsc needs to be off (turned off normally by genpd_power_off_unused) for the display init to succeed, otherwise the screen is stuck on black. I'm guessing doing this is resetting the mdss block? Is there a way to properly put this into dts/driver so that it ensures the mdss has been reset(?) properly before doing the init, otherwise it's just relying on genpd_power_off_unused having run before mdss

12:18 <z3ntu1> initializes which is not great (since it can easily break)..

12:19 <z3ntu1> I thought I read something on the mailing list a while ago regarding something like this, forcing the power domain off somehow to make sure it's resetting but I'm not sure what came of it - or if there's a different solution here. In any case I don't see a 'reset' being registered downstream in the dispcc driver so I don't think we can take something from downstream 1:1

12:26 <aka_[m]> Luca Weiss: have you just tried adding "reset" to dpu/dss?

12:26 <aka_[m]> its consumed on mdss/mdp5 atleast

12:26 <z3ntu1> aka_: what reset?

12:26 <aka_[m]> just like on 8953

12:27 <aka_[m]> https://github.com/msm8953-mainline/linux/blob/6.6.0/main/arch/arm64/boot/dts/qcom/msm8953.dtsi#L1507

12:29 <z3ntu1> Okay, going back from https://github.com/msm8953-mainline/linux/commit/c269caca663562cc20d81e1a17a06bc700a60f76 I see downstream has arch/arm64/boot/dts/qcom/msm8953-mdss-pll.dtsi: <0x0184d074 0x8> (as "gdsc_base")

12:30 <z3ntu1> In lagoon-sde-pll.dtsi downstream I see also gdsc_base with 0xaf03000 and since dispcc is at 0xaf00000 that should mean there's maybe a reset at 0x3000

12:30 <z3ntu1> man, I hate downstream dts :D

12:32 <z3ntu1> but seems at least downstream is only doing a read on this register region for is_gdsc_disabled

13:18 <z3ntu1> okay so what I've tried so far didn't work, still black screen

13:20 <z3ntu1> I've found this commit from konradybcio https://github.com/torvalds/linux/commit/002c3fb6f4f38b50ef0514247c2d55fc6ed8c6d4 , the closest to 0x2000 I can find is <0x5f03000 0x8> (for "gdsc_base") in scube-sde-pll.dtsi but I can't actually find anything for 0x2000. For fun I also tried 0x2000 on sm6350 but also no luck (as with 0x3000)

13:25 <konradybcio> the register maps differ acros ssocs

13:25 <konradybcio> Especially the 2016/17ish 8953 vs the newer design

13:27 <z3ntu1> konradybcio: do you have any insight if such reset exists on 6350/7225 and if so, where?

13:27 <konradybcio> not at the moment

13:27 <z3ntu1> I don't see anything downstream on scuba either so I guess it's not in the dts, or at least not discoverable for me

13:37 <z3ntu1> konradybcio: Could you find this out at some point? Or any suggestion for a different solution? I'm just grasping at anything right now but somehow an explicit reset makes sense in my mind if that somehow exists

14:53 <aka_[m]> Luca Weiss: check flat if you have one

14:54 <aka_[m]> I guess I have no lagoon

16:40 <konradybcio> Luca Weiss: i can try, but no promises

22:12 <aka_[m]> konradybcio: 855/6115 are all dispcc_base+0x2000

22:14 <aka_[m]> finished checking almost most 4.14 soc

22:14 <aka_[m]> renell/saipan too whatever is that

22:14 <aka_[m]> uh Saipan is that i believe

22:15 <aka_[m]> saipan+bitra =lito family

22:17 <aka_[m]> 0x3000 is MDSS_CORE_GDSCR_ADDR

22:17 <aka_[m]> so its reset for gdsc or something?