linux-kernel - Re: [PATCH 3/3] PM: domains: Add a ->dev_get_performance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1124dae5-478f-f0ca-ea91-b6945f7c9254@gmail.com>
Date:   Fri, 3 Sep 2021 13:06:27 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Stephan Gerhold <stephan@...hold.net>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: 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 <digetx@...il.com> wrote:
>>
>> 02.09.2021 13:16, Ulf Hansson пишет:
>>> 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 <ulf.hansson@...aro.org>
>>> ---
>>>  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?


>> 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').
> 
>>
>> 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.
>> [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.