Hi, On Wed Sep 3, 2025 at 12:33 PM CEST, Ulf Hansson wrote: > On Wed, 3 Sept 2025 at 09:39, Sebin Francis wrote: >> On 01/07/25 17:17, Ulf Hansson wrote: >> > >> > 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/ 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/ 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