mbox series

[0/7] OPP/pmdomain: Assign required_devs for required OPPs through genpd

Message ID 20240619140849.368580-1-ulf.hansson@linaro.org (mailing list archive)
Headers show
Series OPP/pmdomain: Assign required_devs for required OPPs through genpd | expand

Message

Ulf Hansson June 19, 2024, 2:08 p.m. UTC
Through dev_pm_opp_set_config() the _opp_attach_genpd() allows consumer
drivers to hook up a device to its PM domains. This works for both a single
and multiple PM domains. Their corresponding virtual devices that are
created by genpd during attach, are later being assigned as the
required_devs for the corresponding required OPPs.

In principle this works fine, but there are some problems. Especially as
the index for a "required-opps" may not necessarily need to match the index
for the "power-domain" in DT, in which case things gets screwed up.

This series intends to improve the situation, but it's also the first step to
enable consumers of _opp_attach_genpd() to start migrating to use the new
dev_pm_domain_attach_list() instead. Down the road, we should then be able to
drop _opp_attach_genpd() completely.

To test this, I have used a QEMU setup, with local PM test-drivers to try to
test all various combinations of single/multi power/performance PM domains for
a device. Hopefully I have covered it all, but I would certainly appreciate if
someone could help to run a slew of tests on some HWs.

Note: Patch1 is actually a fix that has been posted [1] separately too. I
decided to include here for completeness.

Kind regards
Ulf Hansson

[1]
https://lore.kernel.org/linux-kernel/20240618155013.323322-1-ulf.hansson@linaro.org/

Ulf Hansson (7):
  OPP: Fix support for required OPPs for multiple PM domains
  OPP: Drop a redundant in-parameter to _set_opp_level()
  OPP: Rework _set_required_devs() to manage a single device per call
  OPP: Introduce an OF helper function to inform if required-opps is
    used
  pmdomain: core: Manage the default required OPP from a separate
    function
  OPP/pmdomain: Set the required_dev for a required OPP during genpd
    attach
  pmdomain: core: Drop the redundant dev_to_genpd_dev()

 drivers/opp/core.c        | 185 ++++++++++++++++++--------------------
 drivers/opp/of.c          |  32 +++++++
 drivers/opp/opp.h         |   4 +-
 drivers/pmdomain/core.c   | 103 ++++++++++++++++-----
 include/linux/pm_domain.h |   6 --
 include/linux/pm_opp.h    |  16 +++-
 6 files changed, 215 insertions(+), 131 deletions(-)

Comments

Konrad Dybcio June 22, 2024, 12:18 p.m. UTC | #1
On 19.06.2024 4:08 PM, Ulf Hansson wrote:
> Through dev_pm_opp_set_config() the _opp_attach_genpd() allows consumer
> drivers to hook up a device to its PM domains. This works for both a single
> and multiple PM domains. Their corresponding virtual devices that are
> created by genpd during attach, are later being assigned as the
> required_devs for the corresponding required OPPs.
> 
> In principle this works fine, but there are some problems. Especially as
> the index for a "required-opps" may not necessarily need to match the index
> for the "power-domain" in DT, in which case things gets screwed up.

So, is this series essentially tackling a problem like this:

pdp_A: power-domain-provider@aaaaaa {
	[...]

	opp-table {
		pdp_A_opp0: opp-0 {
			opp-level = <0>;
		};
	};
};

pdp_B: power-domain-provider@bbbbbbb {
	[...]

	opp-table {
		pdp_B_opp0: opp-0 {
			opp-level = <0>;
		};
	};
};

nice-device@ccccccc {
	[...]

	power-domains = <&pdp_A>,
			<&pdp_B>;
	// order doesn't match /\
	required-opps = <&pdp_B_opp0>,
			<&pdp_A_opp0>;
};


?

Konrad
Ulf Hansson June 24, 2024, 3:02 p.m. UTC | #2
On Sat, 22 Jun 2024 at 14:18, Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>
> On 19.06.2024 4:08 PM, Ulf Hansson wrote:
> > Through dev_pm_opp_set_config() the _opp_attach_genpd() allows consumer
> > drivers to hook up a device to its PM domains. This works for both a single
> > and multiple PM domains. Their corresponding virtual devices that are
> > created by genpd during attach, are later being assigned as the
> > required_devs for the corresponding required OPPs.
> >
> > In principle this works fine, but there are some problems. Especially as
> > the index for a "required-opps" may not necessarily need to match the index
> > for the "power-domain" in DT, in which case things gets screwed up.
>
> So, is this series essentially tackling a problem like this:
>
> pdp_A: power-domain-provider@aaaaaa {
>         [...]
>
>         opp-table {
>                 pdp_A_opp0: opp-0 {
>                         opp-level = <0>;
>                 };
>         };
> };
>
> pdp_B: power-domain-provider@bbbbbbb {
>         [...]
>
>         opp-table {
>                 pdp_B_opp0: opp-0 {
>                         opp-level = <0>;
>                 };
>         };
> };
>
> nice-device@ccccccc {
>         [...]
>
>         power-domains = <&pdp_A>,
>                         <&pdp_B>;
>         // order doesn't match /\
>         required-opps = <&pdp_B_opp0>,
>                         <&pdp_A_opp0>;
> };
>
>
> ?
>

Correct, this should be taken care off by $subject series.

Kind regards
Uffe