Hi,

On Wed Sep 3, 2025 at 12:33 PM CEST, Ulf Hansson wrote:

On Wed, 3 Sept 2025 at 09:39, Sebin Francis [off-list ref] wrote:

quoted

On 01/07/25 17:17, Ulf Hansson wrote:

quoted

If a PM domain (genpd) is powered-on during boot, there is probably a good
reason for it. Therefore it's known to be a bad idea to allow such genpd to be
powered-off before all of its consumer devices have been probed. This series
intends to fix this problem.

We have been discussing these issues at LKML and at various Linux-conferences
in the past. I have therefore tried to include the people I can recall being
involved, but I may have forgotten some (my apologies), feel free to loop them
in.

Please help review and test!

During testing on a TI platform, I observed new kernel warnings after
applying this patch series:

ti_sci_pm_domains 44043000.system-controller:power-controller:
sync_state() pending due to fd00000.gpu

These warnings occur when a device (in this case, the GPU) has no driver
bound to it. The fw_devlink_dev_sync_state[0] in the core has a check
before printing this warning. It checks whether the device driver has a
sync_state handler OR the device bus has a sync_state handler in the
dev_has_sync_state[1]. If both conditions are false,
fw_devlink_dev_sync_state[0] performs an early return before printing
the warning.

Before this patch series, both handlers were absent for device driver
ti_sci_pm_domains and the device bus, so both conditions failed and no
warnings were printed.

This patch series adds a sync_state handler for the bus, which now
satisfies the second condition. So it doesn't do an early return and
proceeds to print the warning.

Thanks for the report and testing!

Indeed this is the new and expected behaviour. I agree that it's
certainly questionable if those prints should be at the warning level.

We should probably downgrade those to dev_info(), at least. Let me
send a patch to see what Saravana and others are thinking about it!

I want to report that I see similar warnings on Rock64 (rk3328):

[   16.868033] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff300000.gpu
[   16.873637] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff350000.video-codec
[   16.896495] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff360000.video-codec

This is with a 6.17-rc3 kernel with various rkvdec patches and in dmesg
I later see msgs wrt ff300000.gpu (lima) and ff350000.video-codec
(hantro-vpu), but not ff360000.video-codec (rkvdec). Full dmesg:
https://paste.sr.ht/~diederik/951b54ea8422756e5efaa61d6bcefb575cfe28a4

But there were also USB issues (not sure why), so I rebooted and then I
did see msgs wrt rkvdec. Full dmesg:
https://paste.sr.ht/~diederik/156f65fc6be05d02484568dfd303c46ba76b3a8e

I also have a 6.17-rc4 kernel which is clean upstream, thus without any
media patches. This time no USB issues (also no USB device plugged in)
and I see msgs wrt lima and hantro-vpu, but not rkvdec. Full dmesg:
https://paste.sr.ht/~diederik/4affea034b0c9fb522a8ad5b90e8b59b4bd856ec

What's possibly relevant is that the 6.17-rc3+unreleased kernel also has
this patch added, which adds 'power-domain@RK3328_PD_GPU' to rk3328.dtsi
https://lore.kernel.org/linux-rockchip/20250830115135.3549305-1-christianshewitt@gmail.com/ (local)

I actually found this thread because I too couldn't find the commit ID
Nicolas referenced in this post:
https://lore.kernel.org/linux-rockchip/20250902-rk3576-lockup-regression-v1-1-c4a0c9daeb00@collabora.com/ (local)

I have no idea whether it's related though (I have no rk3576 device).

I haven't tried (yet) whether the sync_state() msg is also present on
other Rockchip based devices.

Cheers,
  Diederik