linux-kernel - Re: [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqLx6Y=JgaVtJPFwERQ_=5qwqp5EY1+B=cdfBJO55Vct4w@mail.gmail.com>
Date:   Tue, 28 Feb 2017 08:10:01 -0600
From:   Rob Herring <robh@...nel.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Rafael Wysocki <rjw@...ysocki.net>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Kevin Hilman <khilman@...aro.org>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        "linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Lina Iyer <lina.iyer@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state"
 binding to OPP nodes

On Tue, Feb 28, 2017 at 12:57 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 27-02-17, 18:39, Rob Herring wrote:
>> On Fri, Feb 24, 2017 at 02:36:34PM +0530, Viresh Kumar wrote:
>> > If the consumers don't need the capability of switching to different
>> > domain performance states at runtime, then they can simply define their
>> > required domain performance state in their nodes directly.
>> >
>> > But if the device needs the capability of switching to different domain
>> > performance states, as they may need to support different clock rates,
>> > then the per OPP node can be used to contain that information.
>> >
>> > This patch introduces the domain-performance-state (already defined by
>> > Power Domain bindings) to the per OPP node.
>> >
>>
>> We already have OPP voltages, why are those not sufficient?
>
> Those are for the regulator that ONLY controls the device, and
> domain-performance-state belongs to the parent domain which controls many
> devices.
>
>> > +Example 7: domain-Performance-state:
>> > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2)
>> > +
>> > +/ {
>> > +   cpu0_opp_table: opp_table0 {
>> > +           compatible = "operating-points-v2";
>> > +           opp-shared;
>> > +
>> > +           opp@...0000000 {
>> > +                   opp-hz = /bits/ 64 <1000000000>;
>>
>> Thinking about this some more, there's a problem here that you have no
>> link to foo_domain. I guess that resides in the cpu's node?
>
> Right, the "cpus" node below demonstrates that.
>
>> > +   cpus {
>> > +           #address-cells = <1>;
>> > +           #size-cells = <0>;
>> > +
>> > +           cpu@0 {
>> > +                   compatible = "arm,cortex-a9";
>> > +                   reg = <0>;
>> > +                   clocks = <&clk_controller 0>;
>> > +                   clock-names = "cpu";
>> > +                   operating-points-v2 = <&cpu0_opp_table>;
>> > +                   power-domains = <&foo_domain>;
>> > +           };
>> > +   };
>> > +};
>
>> > +                   domain-performance-state = <1>;
>
>> Perhaps instead of a number, this should be a phandle to pstate@1. Then
>> you just get the parent if you need to know the domain.
>
> That's what I did in V2, but then I turned it down considering the parent/child
> relationships we may have.
>
> There are multiple cases we can have:
>
> A.) DeviceX  --->  Parent-domain-1 (Contains Perfomance states)
>
> B.) DeviceX  --->  Parent-domain-1  ---> Parent domain-2 (Contains Perfomance states)
>
>                                     ---> Parent domain-2 (Contains Perfomance states)
>                                     |
>                                     |
> C.) DeviceX  --->  Parent-domain-1  |
>                                     |
>                                     |
>                                     ---> Parent domain-3 (Contains Perfomance states)

I'm a bit confused. How does a domain have 2 parent domains?

You have the same problem either way. If I have performance state 2
for the device, that corresponds to domain 2 or 3?

> The case A.) represents a simple case where the parent domain of the device
> contains the performance states. The phandle can work pretty well in this case.
> But the other cases B.) and C.) are a bit complicated as the direct parent
> domain doesn't allow changing the performance states, but its parents. And so I
> went ahead with numbers instead of phandles. Yes, we will still be able to get
> to the performance state node with the help of phandles, but will that be the
> right thing to do ?
>
> --
> viresh