On 2/12/26 4:56 PM, 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 PM domain issue here crashes the kernel, so I think this would be
material for drm-misc-fixes .
I added the regressions list onto CC, because this seems like a problem
worth tracking.
Noticed that and wondered what change caused the regression.
I think this one:
330e76d31697 ("drm/imagination: Add power domain control")
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/
Ciao, Thorsten
[1] I guess this was the initial report from Geert?
https://lore.kernel.org/all/camuhmdwapt40hv3c+csbqfow05awcv1a6v_nijygoyi0i9_...@mail.gmail.com/
It is.
I think there are other SoCs which depend on the power domain commit, so
revert is not so clear cut anymore. But SoCs which have hierarchical
power domains and which manage to probe this driver without having a
firmware available for the GPU will simply end with crashed kernel,
which is really not good.
