Message-ID: <dr5qspjhwxaxutiilgx4rvfbrho4bijoll6lciv2bc7c7e7r7m@pgmxztqje5ux>
Date: Mon, 8 Sep 2025 22:08:41 +0200
From: Sebastian Reichel <sebastian.reichel@...labora.com>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>, 
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org, kernel@...labora.com, 
	linux-rockchip@...ts.infradead.org, Cristian Ciocaltea <cristian.ciocaltea@...labora.com>, 
	Heiko Stuebner <heiko@...ech.de>
Subject: Re: [PATCH] pmdomian: core: don't unset stay_on during sync_state

Hi,

On Mon, Sep 08, 2025 at 03:40:24PM +0200, Ulf Hansson wrote:
> On Mon, 8 Sept 2025 at 15:14, Nicolas Frattaroli wrote:
> > On Friday, 5 September 2025 16:27:27 CEST Ulf Hansson wrote:
> > > I would suggest implementing an auxiliary driver, along with the
> > > rockchip_pm_domain_driver. The main job for the auxiliary driver would
> > > be to get the regulator in its ->probe() - and if it fails because the
> > > regulator isn't available yet, it should keep trying by returning
> > > -EPROBE_DEFER. See more about the auxiliary bus/device/driver in
> > > include/linux/auxiliary_bus.h and module_auxiliary_driver().
> > >
> > > Moreover, when the rockchip_pm_domain_driver probes, it becomes
> > > responsible for pre-parsing the OF nodes for the domain-supply DT
> > > property, for each of the specified power-domains. If it finds a
> > > domain-supply, it should register an auxiliary device that corresponds
> > > to that particular power-domain. This can be done by using
> > > platform-data that is shared with the auxiliary device/driver. See
> > > devm_auxiliary_device_create().
> > >
> > > Furthermore we would need some kind of synchronization mechanism
> > > between the rockchip_pm_domain_driver and the auxiliary driver, to
> > > manage the regulator get/enable/disable. I think that should be rather
> > > easy to work out.
> > >
> > > Do you think this can work?
> >
> > This sounds similar to something Heiko suggested to me, and I agree
> > it could work. It does seem like a pretty painful solution though,
> > in terms of needed additional code and complexity to basically just
> > tell Linux "hey you can't get this regulator yet but please try
> > again later without our involvement".
> 
> Well, I would give this a go and see what you end up with. The nice
> thing with this approach, I think, is that we get a driver and can use
> the -EPROBE_DEFER mechanism.
> 
> Another option would be to explore using fw_devlink/device_links, to
> somehow get a notification as soon as the regulator gets registered.

I think the main pain issue with this is fw_devlink actually. The
power domain consumers are all referencing the main DT node. So once
it has been marked as initialized (of_genpd_add_provider_onecell()
calls fwnode_dev_initialized() at some point), fw_devlink allows the
consumers to be probed. As the DT node must be usable for processing
after the normal pmdomains are registered, this means the consumers
for pmdomains with "domain-supply" will potentially be probed too
early resulting in some extra -EPROBE_DEFER. OTOH that should be the
status quo, so probably it does not matter.

> I think those kinds of dependencies are better solved by using
> fw_devlink/device_links.

I think the regulator dependency tracking would happen automatically
when the auxillary sub-device uses the power-domain sub-node as its
device fwnode.

Greetings,

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists