linux-kernel - Re: [PATCH V10 0/3] PM / Domains: Performance state support

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] [day] [month] [year] [list]

Date:   Wed, 4 Oct 2017 09:54:36 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Rafael Wysocki <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Nishanth Menon <nm@...com>, Rob Herring <robh+dt@...nel.org>,
        Lina Iyer <lina.iyer@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Sudeep Holla <sudeep.holla@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>
Subject: Re: [PATCH V10 0/3] PM / Domains: Performance state support

On 4 October 2017 at 08:45, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 03-10-17, 09:52, Ulf Hansson wrote:
>> We sorted out things at LPC!
>>
>> However, the last weeks discussions at Linaro connect, raised a couple
>> of more concerns with the current approach. Let me summarize them
>> here.
>>
>> 1)
>> The ->dev_get_performance_state(), which currently translates
>> frequency for a device to a performance index of its PM domain, is too
>> closely integrated with genpd. Instead this kind of translation rather
>> belongs as a part of the OPP core, because of not limiting this only
>> to translate frequencies, but perhaps *later* also voltages.
>>
>> 2)
>> Propagating an aggregated increased requested performance state index
>> for a genpd, upwards in the hierarchy of its master domains, is
>> currently not needed by any existing SoCs.
>>
>> 3) If some day the need for 2) becomes required, we must not assume a
>> 1 to 1 mapping of the supported performance state index for a
>> master/subdomain. For example a domain may support 1-5, while its
>> master may support 1-8.
>>
>> Taking this into consideration, this series need yet another round of
>> re-spin. The ->dev_get_performance_state() part should be move to the
>> OPP layer and the code dealing with the aggregation of the performance
>> state index can be greatly simplified.
>
> Thanks for the summary.
>
> From the above, it looks like I can send this series right away instead of
> waiting for the multiple genpd per device thing? Is that the case ?

Yes, I think so!

Kind regards
Uffe