Thread (22 messages) 22 messages, 6 authors, 2025-09-12

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-codec
Yes, 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help