08:02 <lumag> kholk[m], Marijn[m], konradybcio any idea what can be missing when accessing gfx cpr registers? reading the reg causes reboot. For the test I have marked mmss_rbcpr_clk/mmss_rbcpr_ahb_clk as critical, but this did not help.

08:17 <lumag> Hmm. It looks like I can read status register, but not version.

10:07 <Mis012[m]> lumag: could also be missing power domains?

10:07 <Mis012[m]> pretty sure the HPG will have the requirements listed

10:08 <Mis012[m]> though at least the clock seems to be listed in HRD

10:08 <lumag> Mis012[m], I don't have access to 8996 HPG

10:13 <Mis012[m]> I don't have access to any HPG :P

10:14 <Mis012[m]> 8994 should be similar enough?

10:14 <Mis012[m]> 8998 should definitely be

10:37 <Marijn[m]> lumag: I finally found what change made SDM660 "stop" and reboot after ~30s: The change from `&pdev->dev` to `mdss_dev` as argument to `of_icc_get()`, in https://git.kernel.org/torvalds/c/6874f48bb8b0. Is that known to you?

10:43 <Marijn[m]> lumag: The correct fix is of course to read the comment you added there, and move the interconnect nodes from mdp to mdss :) - I can submit a patch for that as it doesn't seem to be on the list yet? Do you want it before or after https://lore.kernel.org/linux-arm-msm/20220514190138.3179964-9-dmitry.baryshkov@linaro.org/, which also doesn't seem to have been picked into Bjorn's tree yet?

10:57 <lumag> Marijn[m], hmm. For mdp5 the interconnects might be a part of mdp device. See msm8996.dtsi

10:57 <lumag> So the mdp driver should be fixed to accept interconnects from mdp node too.

10:58 <Marijn[m]> It's not documented in mdp5.txt as far as I can tell

10:59 <lumag> Ideally both DPU and MDP5 should accept an interconnect either from mdp or from mdss nodes. Could you please add a helper to msm_drv (or msm_io_util) and use it from both mdp5 and dpu?

10:59 <lumag> Marijn[m], It's not, but if we were using it from the mdp node, I've broken older dts.

10:59 <lumag> And for msm8996 we anyway have landed the icc to the mdp node

11:00 <Mis012[m]> the interconnects are just MMNoC? :P

11:01 <lumag> more or less

11:01 <lumag> For the MDP at least

11:07 <Tooniis[m]> <lumag> "Marijn, It's not, but if we were..." <- can confirm that it is broken on 8996 at the moment. I'm actually working on a dt schema conversion for mdp5 and going to document interconnects properly

11:08 <Mis012[m]> shouldn't the interconnect registers say precisely which amba bus they are for?

11:11 <Marijn[m]> lumag: I couldn't care less about DT backwards compatibility and given the property not being documented in mdp5.txt would rather keep the driver clean than hacking in such fallbacks

11:14 <Mis012[m]> +1 to that, if the binding doesn't mention it let's take advantage of that

11:14 <Mis012[m]> and actually have the binding correctly represent the hw

11:15 <Marijn[m]> Exactly. How many platforms are affected by this, and does any of them (stupidly) ship their DTB separate from the kernel currently?

11:22 <Mis012[m]> well, if anything, we're correcting the kernel to respect the binding :P

11:28 <lumag> Tooniis[m], so tht we do not duplicate the efforts, I reworked mdss/dpu bindings, see https://patchwork.freedesktop.org/series/106157/

11:29 <lumag> Marijn[m], IIUC only msm8996 is affected. Not sure about sdm660.

11:29 <lumag> Others do not have the interconnects yet.

11:30 <lumag> Marijn[m], sdm660 is affected too

11:30 <lumag> So, I'd vote for the helper

11:30 <lumag> Especially since we would need it for DPU to properly support 8996/sdm660

11:31 <Marijn[m]> lumag: I already have a patch for sdm630 (that's what I was using to find this in the first place....)

11:31 <lumag> Also, I'd prefer to have icc in mdp node. It is more logical. MDSS doesn't care about the paths, it's the dpu/mdp5 who cares

11:31 <Marijn[m]> lumag: To support DPU I'd argue it's even better to have interconnect in the right place, if we end up having to change these nodes somewhat _anyway_?

11:31 <Tooniis[m]> lumag: oh nice, I didn't find it while looking

11:32 <Tooniis[m]> lumag: did you also fix the msm8996 dts?

11:33 <lumag> Tooniis[m], it seems, no

11:33 <Marijn[m]> lumag: Well, irrespective of all this I'm very short on time and will be gone for a longer time soon... So I'd rather not pick this up in hopes of being able to resend some other pending series before I'm fully gone

11:34 <lumag> Marijn[m], I'm going to be somewhat off for the next two weeks

11:34 <lumag> So. it seems this leaves Tooniis[m] as the only interested party :-)

11:34 <Marijn[m]> We all need some time off from the kernel 😬

11:35 <Marijn[m]> That leaves Tooniis to decide the best way forward 🤩

11:36 <Tooniis[m]> honestly I don't care about anything, just don't want to get a blue screen of death in linux because that's not where it belongs

11:37 <Tooniis[m]> I'll probably just update dts and forget about it

11:37 <lumag> Tooniis[m], Ugh.

11:38 <lumag> -ENOMAINLINE

11:38 <lumag> ;-)

11:44 <Marijn[m]> Tooniis: For me it's typically a black screen (oh, oled, you don't even know if the device is on and just not displaying again) or lots of funky colors thanks to DSC corruption :D

11:44 <Marijn[m]> s/again/anything

11:56 <lumag> Marijn[m], Tooniis[m]: okay. I have sent the untested RFC. Could you please check it?

11:57 <lumag> (no, unfortunately I don't have time to check that today).

12:09 <lumag> So tested-by/r-b are welcomed

16:42 <Tooniis[m]> lumag: i see you are working on msm8996 idle

16:42 <Tooniis[m]> have you encountered an issue where the big cpus would just completely lock up if put into spc?

16:43 <Tooniis[m]> I've always kept cpu idle disabled because of this

20:16 <lumag> Tooniis[m], yes, I've seen that. It seems that local-timer-stop helps, but I'm not sure if that is a proper fix or just a workaround

20:17 <lumag> My plan is to fix the CPU and GFX CPRs and then to return to cpuidle issues.

20:17 <lumag> So that we can be sure that the lockup is not due to undervolting the CPU