Re: [PATCH 3/3] PM: domains: Add a ->dev_get_performance_state() callback to genpd

03.09.2021 11:55, Ulf Hansson пишет:

On Fri, 3 Sept 2021 at 08:00, Dmitry Osipenko [off-list ref] wrote:

quoted

02.09.2021 13:16, Ulf Hansson пишет:

quoted

Hardware may be preprogrammed to a specific performance state, which may
not be zero initially during boot. This may lead to that genpd's current
performance state becomes inconsistent with the state of the hardware. To
deal with this, the driver for a device that is being attached to its
genpd, need to request an initial performance state vote, which is
typically done by calling some of the OPP APIs while probing.

In some cases this would lead to boilerplate code in the drivers. Let's
make it possible to avoid this, by adding a new optional callback to genpd
and invoke it per device during the attach process. In this way, the genpd
provider driver can inform genpd about the initial performance state that
is needed for the device.

Signed-off-by: Ulf Hansson <redacted>
---
 drivers/base/power/domain.c | 8 +++++---
 include/linux/pm_domain.h   | 2 ++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 800adf831cae..1a6f3538af8d 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c

@@ -2640,13 +2640,15 @@ static void genpd_dev_pm_sync(struct device *dev)
      genpd_queue_power_off_work(pd);
 }

-static int genpd_get_default_performance_state(struct device *dev,
+static int genpd_get_default_performance_state(struct generic_pm_domain *genpd,
+                                            struct device *dev,
                                             unsigned int index)
 {
      int pstate = of_get_required_opp_performance_state(dev->of_node, index);

      if (pstate == -ENODEV || pstate == -EOPNOTSUPP)
-             return 0;
+             pstate = genpd->dev_get_performance_state ?
+                      genpd->dev_get_performance_state(genpd, dev) : 0;

      return pstate;
 }

@@ -2701,7 +2703,7 @@ static int __genpd_dev_pm_attach(struct device *dev, struct device *base_dev,
      }

      /* Set the default performance state */
-     pstate = genpd_get_default_performance_state(dev, index);
+     pstate = genpd_get_default_performance_state(pd, dev, index);

If base device is suspended, then its performance state is zero.

When device will be rpm-resumed, then its performance should be set to
the default state.
You're setting performance state of the wrong device, it should be the

Are you okay with my variant of handling the suspended device?

quoted

base device and not the virtual domain device.

No I am not. :-) Let me elaborate.

For the single PM domain case, 'dev' and 'base_dev' are pointing to
the same device. So this works fine.

For the multiple PM domain case or when attaching goes via
genpd_dev_pm_attach_by_id(), 'dev' is the virtual device registered in
genpd_dev_pm_attach_by_id(). In this case, it's 'dev' that is becoming
attached to genpd and not the 'base_dev'. Note also that, runtime PM
has not been enabled for 'dev' yet at this point and 'dev' has been
assigned the same OF node as 'base_dev", to allow OF parsing to work
as is for it.

Moreover, to deal with runtime PM in the multiple PM domain case, the
consumer driver should create a device link. Along the lines of this:
device_link_add(base_dev, dev, DL_FLAG_PM_RUNTIME |
DL_FLAG_STATELESS), thus assigning the virtual device ('dev') as the
supplier for its consumer device ('base_dev').

quoted

These all is handled properly by my patch [1]. Hence it's complicated
for the reason.

See above. It shouldn't have to be complicated. If it still is, there
is something to fix for the multiple PM domain case.

quoted

[1]

Alright, it actually works now on Tegra using the dev in the callback
for the case of multiple domains, I re-checked it. Previously, when I
tried that, there was a conflict in regards to OPP usage, I don't
remember details anymore. Maybe the recent changes that were suggested
by Viresh helped with that. So yes, there is no need to pass the base
device anymore.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel