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

Message-ID: <CAPDyKFoG7MovwoSfagw-CTo7WBGcQGjHgNtornNKGXNJ_AxLag@mail.gmail.com>
Date:   Tue, 3 Oct 2017 09:52:50 +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 20 September 2017 at 00:32, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> Hi Ulf,
>
> This version contains the changes we discussed during the LPC.
>
> Some platforms have the capability to configure the performance state of
> their power domains. The process of configuring the performance state is
> pretty much platform dependent and we may need to work with a wide range
> of configurables.  For some platforms, like Qcom, it can be a positive
> integer value alone, while in other cases it can be voltage levels, etc.
>
> The power-domain framework until now was only designed for the idle
> state management of the device and this needs to change in order to
> reuse the power-domain framework for active state management of the
> devices.
>
> The first patch updates the genpd framework to supply new APIs to
> support active state management and the second patch uses them from the
> OPP core. The third patch adds some more checks to the genpd core to
> catch bugs.
>
> Rest of the patches [4-7/7] are included just to show how user drivers
> would end up using the new APIs and these patches aren't there to get
> merged and are marked clearly like that.
>
> The ideal way is still to get the relation between device and domain
> states via the DT instead of platform code, but that can be done
> incrementally later once we have some users for it upstream.
>
> This is currently tested by:
> - /me by hacking the kernel a bit with virtual power-domains for the ARM
>   64 hikey platform. I have also tested the complex cases where the
>   device's parent power domain doesn't have set_performance_state()
>   callback set, but parents of that domains have it. Lockdep configs
>   were enabled for these tests.
> - Rajendra Nayak, on msm8996 platform (Qcom) with MMC controller.
>
> Thanks Rajendra for helping me testing this out.
>
> I also had a chat with Rajendra and we should be able to get a Qualcomm
> specific power domain driver (which uses these changes) in coming weeks.
> Though it wouldn't solve all the problems around corners they have, as
> they need more updates later on (Like support for multiple masters for a
> device, etc).

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.

[...]

Kind regards
Uffe