On 12/02/2026 15:56, Thorsten Leemhuis wrote: > On 2/12/26 15:38, Marek Vasut wrote: >> On 2/12/26 10:00 AM, Matt Coster wrote: >>> On 11/02/2026 19:17, Marek Vasut wrote: >>>> On 1/23/26 2:50 PM, Geert Uytterhoeven wrote: >>>>> On Fri, 23 Jan 2026 at 14:36, Matt Coster <[email protected]> >>>>> wrote: >>>>>> On 22/01/2026 16:08, Geert Uytterhoeven wrote: >>>>>>> Call the dev_pm_domain_attach_list() and dev_pm_domain_detach_list() >>>>>>> helpers instead of open-coding multi PM Domain handling. >>>>>>> >>>>>>> This changes behavior slightly: >>>>>>> - The new handling is also applied in case of a single PM Domain, >>>>>>> - PM Domains are now referred to by index instead of by name, but >>>>>>> "make dtbs_check" enforces the actual naming and ordering >>>>>>> anyway, >>>>>>> - There are no longer device links created between virtual domain >>>>>>> devices, only between virtual devices and the parent device. >>>>>> >>>>>> We still need this guarantee, both at start and end of day. In the >>>>>> current implementation dev_pm_domain_attach_list() iterates forwards, >>>>>> but so does dev_pm_domain_detach_list(). Even if we changed that, I'd >>>>>> prefer not to rely on the implementation details when we can >>>>>> declare the >>>>>> dependencies explicitly. >>>>> >>>>> Note that on R-Car, the PM Domains are nested (see e.g. >>>>> r8a7795_areas[]), >>>>> so they are always (un)powered in the correct order. But that may not >>>>> be the case in the integration on other SoCs. >>>>> >>>>>> We had/have a patch (attached) kicking around internally to use the >>>>>> *_list() functions but keep the inter-domain links in place; it got >>>>>> held >>>>>> up by discussions as to whether we actually need those dependencies >>>>>> for >>>>>> the hardware to behave correctly. Your patch spurred me to run around >>>>>> the office and nag people a bit, and it seems we really do need to >>>>>> care >>>>>> about the ordering. >>>>> >>>>> OK. >>>>> >>>>>> Can you add the links back in for a V2 or I can properly send the >>>>>> attached patch instead, I don't mind either way. >>>>> >>>>> Please move forward with your patch, you are the expert. >>>>> I prefer not to be blamed for any breakage ;-) >>>> >>>> Has there been any progress on fixing this kernel crash ? >>>> >>>> There are already two proposed solutions, but no fix is upstream. >>> >>> Yes and no. Our patch to use dev_pm_domain_attach_list() has landed in >>> drm-misc-next as commit e19cc5ab347e3 ("drm/imagination: Use >>> dev_pm_domain_attach_list()"), but this does not fix the underlying >>> issue of missing synchronization in the PM core[1] is still unresolved >>> as far as I'm aware. >> >> OK, but the pvr driver can currently easily crash the kernel on boot if >> firmware is missing, so that should be fixed soon, right ? > > Well, drm-misc-next afaik means that the above mentioned fix would only > be merged in 7.1, which is ~4 months away, which is not really "soon" > I'd say. Or did I misjudge this?
The above isn't really a "fix" per se, it's just an enhancement. The underlying crash can still happen. We could still pick it into drm-misc-fixes and have it in the next -rc plus backported to stable, but I'm not sure I see the value. > >> I added the regressions list onto CC, because this seems like a problem >> worth tracking. > > Noticed that and wondered what change caused the regression. Did not > find a answer in a quick search on lore[1]. Because if it's a > regression, we maybe should just revert the culprit for now according to > Linus: > https://lore.kernel.org/lkml/CAHk-=wi86aosxs66-yi54+mpqjpu0upxb8zafg+lsmyjmcu...@mail.gmail.com/ > From our side at least, I don't believe this is a regression at all. We haven't been able to reproduce this issue on any of the platforms we have available (although we did stumble on a related bugfix[2] while trying). My current understanding of the situation is that the fix proposed by Marek in the Reneasas driver[3] works, but is not suitable since pm_runtime_barrier() should be inserted by the caller, not the power driver. But it seems that's not always possible (particularly when using devm), so I don't really understand where we go from here. I don't see anything we're doing substantially differently (before or after the commit I mentioned above) from anybody else. Cheers, Matt [2]: TBC [3]: https://lore.kernel.org/r/[email protected]/ > > Ciao, Thorsten > > [1] I guess this was the initial report from Geert? > https://lore.kernel.org/all/camuhmdwapt40hv3c+csbqfow05awcv1a6v_nijygoyi0i9_...@mail.gmail.com/ > -- Matt Coster E: [email protected]
OpenPGP_signature.asc
Description: OpenPGP digital signature
