Re: [PATCH 0/5] pmdomain: Restore behaviour for disabling unused PM domains
From: Saravana Kannan <hidden>
Date: 2025-09-12 18:32:48
Also in:
linux-pm, linux-rockchip, lkml
On Thu, Sep 11, 2025 at 1:26 AM Diederik de Haas [off-list ref] wrote:
Hi Geert, On Thu Sep 11, 2025 at 9:18 AM CEST, Geert Uytterhoeven wrote:quoted
On Wed, 10 Sept 2025 at 21:33, Diederik de Haas [off-list ref] wrote:quoted
On Tue Sep 9, 2025 at 1:11 PM CEST, Ulf Hansson wrote:quoted
Recent changes to genpd prevents those PM domains being powered-on during initialization from being powered-off during the boot sequence. Based upon whether CONFIG_PM_CONFIG_PM_GENERIC_DOMAINS_OF is set of not, genpd relies on the sync_state mechanism or the genpd_power_off_unused() (which is a late_initcall_sync), to understand when it's okay to allow these PM domains to be powered-off. This new behaviour in genpd has lead to problems on different platforms [1]. In this series, I am therefore suggesting to restore the behavior of genpd_power_off_unused() along with introducing a new genpd config flag, GENPD_FLAG_NO_STAY_ON, to allow genpd OF providers to opt-out from the new behaviour.Is it expected that I'm still seeing this on a Rock64 (rk3328), just like before [1]? [ 17.124202] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff300000.gpu [ 17.129799] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff350000.video-codec [ 17.140003] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff360000.video-codecYes, as the sync state is still blocked on them. Disabling unused PM Domains is done independently of sync state.quoted
This is with a 6.17-rc5 kernel with this patch set applied. And it also has this patch from Christian Hewitt added, now in v3: https://lore.kernel.org/linux-rockchip/20250906120810.1833016-1-christianshewitt@gmail.com/ (local) When I boot into a 6.17-rc5 kernel without any patches applied, I do get the 2 for ff350000.video-codec and ff360000.video-codec, but not the ff300000.gpu one. Interestingly: ff300000.gpu -> power-domains = <&power RK3328_PD_GPU>; ff350000.video-codec -> power-domains = <&power RK3328_PD_VPU>; ff360000.video-codec -> power-domains = <&power RK3328_PD_VIDEO>; I would be surprised if that was a coincidence.Fw_devlinks ignores the index cell (RK3328_PD_*), hence all links are created pointing to the pmdomain controller (in case it has a platform driver) or the first pmdomain (in case it has not). thus blocking the sync state call and power-down for _all_ pmdomains managed by the controller.I don't think I fully understand this (not your problem due to lack of knowledge on my part), but you mentioning 'fw_devlink' rang a bell. Some time ago Nicolas Frattaroli and I worked on an image for PINE64's *Quartz* devices and that added ``fw_devlink=off`` to cmdline. I've been using it on all my Rockchip based devices, without understanding that parameter ... but (apparently) on my 'rock64-test' device, where I tested it with, I had removed that parameter. Putting that parameter back ... and those warnings are gone! Thanks a LOT for that hint!
Please don't just disable fw_devlink using fw_devlink=off. We want to fix any issues you are hitting with it. I might even delete this "off" option sometime. It was meant as an early debug option. Thanks, Saravana