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

[Rajendra Nayak]

On 03/02/2017 04:43 AM, Rob Herring wrote:
> On Wed, Mar 1, 2017 at 12:27 AM, Rajendra Nayak  wrote:
>>
>>
>> On 02/28/2017 09:22 PM, Rob Herring wrote:
>>> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
 [...]

>> ---> 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?

 This comes from the early design of the generic PM domain, thus I
 assume we have some HW with such complex PM topology. However, I don't
 know if it is actually being used.

 Moreover, the corresponding DT bindings for "power-domains" parents,
 can easily be extended to cover more than one parent. See more in
 Documentation/devicetree/bindings/power/power_domain.txt
>>>
>>> I could easily see device having 2 power domains. For example a cpu
>>> may have separate domains for RAM/caches and logic. And nesting of
>>
>> yet the bindings for power-domains (for consumer devices) only allows for
>> one powerdomain to be associated with a device.
> 
> There's nothing in the binding only allowing that. If that was true,
> then #powerdomain-cells would be pointless

Is't #powerdomain-cells a powerdomain provider property? and used to
specify if a powerdomain provider supports providing 1 or many powerdomains?
I was talking about the power domain consumer property.
Looking at Documentation/devicetree/bindings/power/power_domain.txt..

==PM domain consumers==

Required properties:
 - power-domains : A phandle and PM domain specifier as defined by bindings of
   the power controller specified by phandle.

It clearly says 'A phandle'. If there was a way to specify multiple 
power-domains
for a consumer device should it not be saying a list of phandles? Like we do for
clocks and regulators?

> as the property size would
> tell you the number of cells. Now it may be that we simply don't have
> any cases with more than 1. Hopefully that's not because bindings are
> working around PM domain limitations/requirements.
> 
> Rob
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Rajendra Nayak]

On 03/02/2017 04:43 AM, Rob Herring wrote:
> On Wed, Mar 1, 2017 at 12:27 AM, Rajendra Nayak  wrote:
>>
>>
>> On 02/28/2017 09:22 PM, Rob Herring wrote:
>>> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
 [...]

>> ---> 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?

 This comes from the early design of the generic PM domain, thus I
 assume we have some HW with such complex PM topology. However, I don't
 know if it is actually being used.

 Moreover, the corresponding DT bindings for "power-domains" parents,
 can easily be extended to cover more than one parent. See more in
 Documentation/devicetree/bindings/power/power_domain.txt
>>>
>>> I could easily see device having 2 power domains. For example a cpu
>>> may have separate domains for RAM/caches and logic. And nesting of
>>
>> yet the bindings for power-domains (for consumer devices) only allows for
>> one powerdomain to be associated with a device.
> 
> There's nothing in the binding only allowing that. If that was true,
> then #powerdomain-cells would be pointless

Is't #powerdomain-cells a powerdomain provider property? and used to
specify if a powerdomain provider supports providing 1 or many powerdomains?
I was talking about the power domain consumer property.
Looking at Documentation/devicetree/bindings/power/power_domain.txt..

==PM domain consumers==

Required properties:
 - power-domains : A phandle and PM domain specifier as defined by bindings of
   the power controller specified by phandle.

It clearly says 'A phandle'. If there was a way to specify multiple 
power-domains
for a consumer device should it not be saying a list of phandles? Like we do for
clocks and regulators?

> as the property size would
> tell you the number of cells. Now it may be that we simply don't have
> any cases with more than 1. Hopefully that's not because bindings are
> working around PM domain limitations/requirements.
> 
> Rob
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Rob Herring]

On Wed, Mar 1, 2017 at 12:27 AM, Rajendra Nayak  wrote:
>
>
> On 02/28/2017 09:22 PM, Rob Herring wrote:
>> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
>>> [...]
>>>
> ---> 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?
>>>
>>> This comes from the early design of the generic PM domain, thus I
>>> assume we have some HW with such complex PM topology. However, I don't
>>> know if it is actually being used.
>>>
>>> Moreover, the corresponding DT bindings for "power-domains" parents,
>>> can easily be extended to cover more than one parent. See more in
>>> Documentation/devicetree/bindings/power/power_domain.txt
>>
>> I could easily see device having 2 power domains. For example a cpu
>> may have separate domains for RAM/caches and logic. And nesting of
>
> yet the bindings for power-domains (for consumer devices) only allows for
> one powerdomain to be associated with a device.

There's nothing in the binding only allowing that. If that was true,
then #powerdomain-cells would be pointless as the property size would
tell you the number of cells. Now it may be that we simply don't have
any cases with more than 1. Hopefully that's not because bindings are
working around PM domain limitations/requirements.

Rob

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

[Rob Herring]

On Wed, Mar 1, 2017 at 12:27 AM, Rajendra Nayak  wrote:
>
>
> On 02/28/2017 09:22 PM, Rob Herring wrote:
>> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
>>> [...]
>>>
> ---> 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?
>>>
>>> This comes from the early design of the generic PM domain, thus I
>>> assume we have some HW with such complex PM topology. However, I don't
>>> know if it is actually being used.
>>>
>>> Moreover, the corresponding DT bindings for "power-domains" parents,
>>> can easily be extended to cover more than one parent. See more in
>>> Documentation/devicetree/bindings/power/power_domain.txt
>>
>> I could easily see device having 2 power domains. For example a cpu
>> may have separate domains for RAM/caches and logic. And nesting of
>
> yet the bindings for power-domains (for consumer devices) only allows for
> one powerdomain to be associated with a device.

There's nothing in the binding only allowing that. If that was true,
then #powerdomain-cells would be pointless as the property size would
tell you the number of cells. Now it may be that we simply don't have
any cases with more than 1. Hopefully that's not because bindings are
working around PM domain limitations/requirements.

Rob

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

[Viresh Kumar]

On 01-03-17, 09:45, Geert Uytterhoeven wrote:
> On Wed, Mar 1, 2017 at 7:14 AM, Viresh Kumar  wrote:
> > On 28-02-17, 09:52, Rob Herring wrote:
> >> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  
> >> wrote:
> >> > This comes from the early design of the generic PM domain, thus I
> >> > assume we have some HW with such complex PM topology. However, I don't
> >> > know if it is actually being used.
> >> >
> >> > Moreover, the corresponding DT bindings for "power-domains" parents,
> >> > can easily be extended to cover more than one parent. See more in
> >> > Documentation/devicetree/bindings/power/power_domain.txt
> >>
> >> I could easily see device having 2 power domains. For example a cpu
> >> may have separate domains for RAM/caches and logic.
> >
> > An important thing here is that PM domain doesn't support such devices. 
> > i.e. a
> > device isn't allowed to have multiple PM domains today. So a way to support 
> > such
> > devices can be to create a virtual PM domain, that has two parents and 
> > device as
> > its child.
> 
> As clock domains (and their support code) are fairly orthogonal to power
> areas, currently our power area controller driver just forwards the
> clock handling
> to the clock driver (cfr. rcar-sysc).

Perhaps Rajendra can explain better but Qcom have a case where they need to
program two power domains as well.

-- 
viresh

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

[Viresh Kumar]

On 01-03-17, 09:45, Geert Uytterhoeven wrote:
> On Wed, Mar 1, 2017 at 7:14 AM, Viresh Kumar  wrote:
> > On 28-02-17, 09:52, Rob Herring wrote:
> >> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  
> >> wrote:
> >> > This comes from the early design of the generic PM domain, thus I
> >> > assume we have some HW with such complex PM topology. However, I don't
> >> > know if it is actually being used.
> >> >
> >> > Moreover, the corresponding DT bindings for "power-domains" parents,
> >> > can easily be extended to cover more than one parent. See more in
> >> > Documentation/devicetree/bindings/power/power_domain.txt
> >>
> >> I could easily see device having 2 power domains. For example a cpu
> >> may have separate domains for RAM/caches and logic.
> >
> > An important thing here is that PM domain doesn't support such devices. 
> > i.e. a
> > device isn't allowed to have multiple PM domains today. So a way to support 
> > such
> > devices can be to create a virtual PM domain, that has two parents and 
> > device as
> > its child.
> 
> As clock domains (and their support code) are fairly orthogonal to power
> areas, currently our power area controller driver just forwards the
> clock handling
> to the clock driver (cfr. rcar-sysc).

Perhaps Rajendra can explain better but Qcom have a case where they need to
program two power domains as well.

-- 
viresh

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

[Geert Uytterhoeven]

On Wed, Mar 1, 2017 at 7:14 AM, Viresh Kumar  wrote:
> On 28-02-17, 09:52, Rob Herring wrote:
>> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
>> > This comes from the early design of the generic PM domain, thus I
>> > assume we have some HW with such complex PM topology. However, I don't
>> > know if it is actually being used.
>> >
>> > Moreover, the corresponding DT bindings for "power-domains" parents,
>> > can easily be extended to cover more than one parent. See more in
>> > Documentation/devicetree/bindings/power/power_domain.txt
>>
>> I could easily see device having 2 power domains. For example a cpu
>> may have separate domains for RAM/caches and logic.
>
> An important thing here is that PM domain doesn't support such devices. i.e. a
> device isn't allowed to have multiple PM domains today. So a way to support 
> such
> devices can be to create a virtual PM domain, that has two parents and device 
> as
> its child.

As clock domains (and their support code) are fairly orthogonal to power
areas, currently our power area controller driver just forwards the
clock handling
to the clock driver (cfr. rcar-sysc).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Geert Uytterhoeven]

On Wed, Mar 1, 2017 at 7:14 AM, Viresh Kumar  wrote:
> On 28-02-17, 09:52, Rob Herring wrote:
>> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
>> > This comes from the early design of the generic PM domain, thus I
>> > assume we have some HW with such complex PM topology. However, I don't
>> > know if it is actually being used.
>> >
>> > Moreover, the corresponding DT bindings for "power-domains" parents,
>> > can easily be extended to cover more than one parent. See more in
>> > Documentation/devicetree/bindings/power/power_domain.txt
>>
>> I could easily see device having 2 power domains. For example a cpu
>> may have separate domains for RAM/caches and logic.
>
> An important thing here is that PM domain doesn't support such devices. i.e. a
> device isn't allowed to have multiple PM domains today. So a way to support 
> such
> devices can be to create a virtual PM domain, that has two parents and device 
> as
> its child.

As clock domains (and their support code) are fairly orthogonal to power
areas, currently our power area controller driver just forwards the
clock handling
to the clock driver (cfr. rcar-sysc).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Rajendra Nayak]

On 02/28/2017 09:22 PM, Rob Herring wrote:
> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
>> [...]
>>
 ---> 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?
>>
>> This comes from the early design of the generic PM domain, thus I
>> assume we have some HW with such complex PM topology. However, I don't
>> know if it is actually being used.
>>
>> Moreover, the corresponding DT bindings for "power-domains" parents,
>> can easily be extended to cover more than one parent. See more in
>> Documentation/devicetree/bindings/power/power_domain.txt
> 
> I could easily see device having 2 power domains. For example a cpu
> may have separate domains for RAM/caches and logic. And nesting of

yet the bindings for power-domains (for consumer devices) only allows for
one powerdomain to be associated with a device.

> power domains is certainly common, but a power domain being contained
> in 2 different parents? I don't even see how that is possible in the
> physical design. Now if we're mixing PM and power domains again and
> the cpu device is pointing to the cpu PM domain which contains 2 power
> domains, then certainly that is possible.
> 
> Rob
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Rajendra Nayak]

On 02/28/2017 09:22 PM, Rob Herring wrote:
> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
>> [...]
>>
 ---> 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?
>>
>> This comes from the early design of the generic PM domain, thus I
>> assume we have some HW with such complex PM topology. However, I don't
>> know if it is actually being used.
>>
>> Moreover, the corresponding DT bindings for "power-domains" parents,
>> can easily be extended to cover more than one parent. See more in
>> Documentation/devicetree/bindings/power/power_domain.txt
> 
> I could easily see device having 2 power domains. For example a cpu
> may have separate domains for RAM/caches and logic. And nesting of

yet the bindings for power-domains (for consumer devices) only allows for
one powerdomain to be associated with a device.

> power domains is certainly common, but a power domain being contained
> in 2 different parents? I don't even see how that is possible in the
> physical design. Now if we're mixing PM and power domains again and
> the cpu device is pointing to the cpu PM domain which contains 2 power
> domains, then certainly that is possible.
> 
> Rob
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Viresh Kumar]

On 28-02-17, 08:10, Rob Herring wrote:
> On Tue, Feb 28, 2017 at 12:57 AM, Viresh Kumar  
> wrote:
> > 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)

Okay, how about this case first? Should we still use a phandle or an index
value?

> >
> > ---> 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?

The framework supported it and so I thought it should be fairly common. Even in
the last version, I coded the notifier to handle cases where we have only one
parent domain. But then Kevin pointed out that we shouldn't be doing any such
special things. But binding doesn't say anything about it though, and I was just
presenting an example.

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

Right now I have used the same performance state for both the domains in the
code, as I am not sure if we will have such a case. And probably we can figure
this out when we have a case with separate levels for both parents. It would be
trivial to extend the bindings to include a list instead of a single value here.

So, to conclude, should I use a phandle here or it is fine the way it is written
right now ? With direct numbers, its easy to parse it in the OPP framework for
example, as that's the value the QoS framework will use. Else we need to parse
the phandle and read the "reg" value from there.

-- 
viresh

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

[Viresh Kumar]

On 28-02-17, 08:10, Rob Herring wrote:
> On Tue, Feb 28, 2017 at 12:57 AM, Viresh Kumar  
> wrote:
> > 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)

Okay, how about this case first? Should we still use a phandle or an index
value?

> >
> > ---> 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?

The framework supported it and so I thought it should be fairly common. Even in
the last version, I coded the notifier to handle cases where we have only one
parent domain. But then Kevin pointed out that we shouldn't be doing any such
special things. But binding doesn't say anything about it though, and I was just
presenting an example.

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

Right now I have used the same performance state for both the domains in the
code, as I am not sure if we will have such a case. And probably we can figure
this out when we have a case with separate levels for both parents. It would be
trivial to extend the bindings to include a list instead of a single value here.

So, to conclude, should I use a phandle here or it is fine the way it is written
right now ? With direct numbers, its easy to parse it in the OPP framework for
example, as that's the value the QoS framework will use. Else we need to parse
the phandle and read the "reg" value from there.

-- 
viresh

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

[Viresh Kumar]

On 28-02-17, 09:52, Rob Herring wrote:
> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
> > This comes from the early design of the generic PM domain, thus I
> > assume we have some HW with such complex PM topology. However, I don't
> > know if it is actually being used.
> >
> > Moreover, the corresponding DT bindings for "power-domains" parents,
> > can easily be extended to cover more than one parent. See more in
> > Documentation/devicetree/bindings/power/power_domain.txt
> 
> I could easily see device having 2 power domains. For example a cpu
> may have separate domains for RAM/caches and logic.

An important thing here is that PM domain doesn't support such devices. i.e. a
device isn't allowed to have multiple PM domains today. So a way to support such
devices can be to create a virtual PM domain, that has two parents and device as
its child.

-- 
viresh

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

[Viresh Kumar]

On 28-02-17, 09:52, Rob Herring wrote:
> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
> > This comes from the early design of the generic PM domain, thus I
> > assume we have some HW with such complex PM topology. However, I don't
> > know if it is actually being used.
> >
> > Moreover, the corresponding DT bindings for "power-domains" parents,
> > can easily be extended to cover more than one parent. See more in
> > Documentation/devicetree/bindings/power/power_domain.txt
> 
> I could easily see device having 2 power domains. For example a cpu
> may have separate domains for RAM/caches and logic.

An important thing here is that PM domain doesn't support such devices. i.e. a
device isn't allowed to have multiple PM domains today. So a way to support such
devices can be to create a virtual PM domain, that has two parents and device as
its child.

-- 
viresh

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

[Geert Uytterhoeven]

Hi Rob,

On Tue, Feb 28, 2017 at 4:52 PM, Rob Herring  wrote:
> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
>> [...]
>>
 ---> 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?
>>
>> This comes from the early design of the generic PM domain, thus I
>> assume we have some HW with such complex PM topology. However, I don't
>> know if it is actually being used.
>>
>> Moreover, the corresponding DT bindings for "power-domains" parents,
>> can easily be extended to cover more than one parent. See more in
>> Documentation/devicetree/bindings/power/power_domain.txt
>
> I could easily see device having 2 power domains. For example a cpu
> may have separate domains for RAM/caches and logic. And nesting of
> power domains is certainly common, but a power domain being contained
> in 2 different parents? I don't even see how that is possible in the
> physical design. Now if we're mixing PM and power domains again and
> the cpu device is pointing to the cpu PM domain which contains 2 power
> domains, then certainly that is possible.

One of them could be a power area, the other a clock domain.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Geert Uytterhoeven]

Hi Rob,

On Tue, Feb 28, 2017 at 4:52 PM, Rob Herring  wrote:
> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
>> [...]
>>
 ---> 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?
>>
>> This comes from the early design of the generic PM domain, thus I
>> assume we have some HW with such complex PM topology. However, I don't
>> know if it is actually being used.
>>
>> Moreover, the corresponding DT bindings for "power-domains" parents,
>> can easily be extended to cover more than one parent. See more in
>> Documentation/devicetree/bindings/power/power_domain.txt
>
> I could easily see device having 2 power domains. For example a cpu
> may have separate domains for RAM/caches and logic. And nesting of
> power domains is certainly common, but a power domain being contained
> in 2 different parents? I don't even see how that is possible in the
> physical design. Now if we're mixing PM and power domains again and
> the cpu device is pointing to the cpu PM domain which contains 2 power
> domains, then certainly that is possible.

One of them could be a power area, the other a clock domain.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Rob Herring]

On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
> [...]
>
>>> ---> 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?
>
> This comes from the early design of the generic PM domain, thus I
> assume we have some HW with such complex PM topology. However, I don't
> know if it is actually being used.
>
> Moreover, the corresponding DT bindings for "power-domains" parents,
> can easily be extended to cover more than one parent. See more in
> Documentation/devicetree/bindings/power/power_domain.txt

I could easily see device having 2 power domains. For example a cpu
may have separate domains for RAM/caches and logic. And nesting of
power domains is certainly common, but a power domain being contained
in 2 different parents? I don't even see how that is possible in the
physical design. Now if we're mixing PM and power domains again and
the cpu device is pointing to the cpu PM domain which contains 2 power
domains, then certainly that is possible.

Rob

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

[Rob Herring]

On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson  wrote:
> [...]
>
>>> ---> 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?
>
> This comes from the early design of the generic PM domain, thus I
> assume we have some HW with such complex PM topology. However, I don't
> know if it is actually being used.
>
> Moreover, the corresponding DT bindings for "power-domains" parents,
> can easily be extended to cover more than one parent. See more in
> Documentation/devicetree/bindings/power/power_domain.txt

I could easily see device having 2 power domains. For example a cpu
may have separate domains for RAM/caches and logic. And nesting of
power domains is certainly common, but a power domain being contained
in 2 different parents? I don't even see how that is possible in the
physical design. Now if we're mixing PM and power domains again and
the cpu device is pointing to the cpu PM domain which contains 2 power
domains, then certainly that is possible.

Rob

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

[Ulf Hansson]

[...]

>> ---> 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?

This comes from the early design of the generic PM domain, thus I
assume we have some HW with such complex PM topology. However, I don't
know if it is actually being used.

Moreover, the corresponding DT bindings for "power-domains" parents,
can easily be extended to cover more than one parent. See more in
Documentation/devicetree/bindings/power/power_domain.txt

[...]

Kind regards
Uffe

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

[Ulf Hansson]

[...]

>> ---> 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?

This comes from the early design of the generic PM domain, thus I
assume we have some HW with such complex PM topology. However, I don't
know if it is actually being used.

Moreover, the corresponding DT bindings for "power-domains" parents,
can easily be extended to cover more than one parent. See more in
Documentation/devicetree/bindings/power/power_domain.txt

[...]

Kind regards
Uffe

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

[Rob Herring]

On Tue, Feb 28, 2017 at 12:57 AM, Viresh Kumar  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@10 {
>> > +   opp-hz = /bits/ 64 <10>;
>>
>> 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 = <_controller 0>;
>> > +   clock-names = "cpu";
>> > +   operating-points-v2 = <_opp_table>;
>> > +   power-domains = <_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

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

[Rob Herring]

On Tue, Feb 28, 2017 at 12:57 AM, Viresh Kumar  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@10 {
>> > +   opp-hz = /bits/ 64 <10>;
>>
>> 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 = <_controller 0>;
>> > +   clock-names = "cpu";
>> > +   operating-points-v2 = <_opp_table>;
>> > +   power-domains = <_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

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

[Viresh Kumar]

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@10 {
> > +   opp-hz = /bits/ 64 <10>;
> 
> 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 = <_controller 0>;
> > +   clock-names = "cpu";
> > +   operating-points-v2 = <_opp_table>;
> > +   power-domains = <_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)


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

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

[Viresh Kumar]

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@10 {
> > +   opp-hz = /bits/ 64 <10>;
> 
> 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 = <_controller 0>;
> > +   clock-names = "cpu";
> > +   operating-points-v2 = <_opp_table>;
> > +   power-domains = <_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)


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

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

[Rob Herring]

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?

> Signed-off-by: Viresh Kumar 
> Tested-by: Rajendra Nayak 
> ---
>  Documentation/devicetree/bindings/opp/opp.txt | 64 
> +++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
> b/Documentation/devicetree/bindings/opp/opp.txt
> index 9f5ca4457b5f..7f6bb52521b6 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -154,6 +154,15 @@ properties.
>  
>  - status: Marks the node enabled/disabled.
>  
> +- domain-performance-state: A positive integer value representing the minimum
> +  performance level (of the parent domain) required by the consumer as 
> defined
> +  by ../power/power_domain.txt binding document. The OPP nodes can contain 
> the
> +  "domain-performance-state" property, only if the device node contains a
> +  "power-domains" property. The OPP nodes aren't allowed to contain the
> +  "domain-performance-state" property partially, i.e. Either all OPP nodes in
> +  the OPP table have the "domain-performance-state" property or none of them
> +  have it.
> +
>  Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states 
> together.
>  
>  / {
> @@ -528,3 +537,58 @@ Example 5: opp-supported-hw
>   };
>   };
>  };
> +
> +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@10 {
> + opp-hz = /bits/ 64 <10>;
> + domain-performance-state = <1>;

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?

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.

> + };
> + opp@11 {
> + opp-hz = /bits/ 64 <11>;
> + domain-performance-state = <2>;
> + };
> + opp@12 {
> + opp-hz = /bits/ 64 <12>;
> + domain-performance-state = <2>;
> + };
> + };
> +
> + foo_domain: power-controller@1234 {
> + compatible = "foo,power-controller";
> + reg = <0x1234 0x1000>;
> + #power-domain-cells = <0>;
> +
> + performance-states {
> + compatible = "domain-performance-state";
> + pstate@1 {
> + reg = <1>;
> + domain-microvolt = <97 975000 985000>;
> + };
> + pstate@2 {
> + reg = <2>;
> + domain-microvolt = <100 1075000 1085000>;
> + };
> + };
> + }
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + compatible = "arm,cortex-a9";
> + reg = <0>;
> + clocks = <_controller 0>;
> + clock-names = "cpu";
> + operating-points-v2 = <_opp_table>;
> + power-domains = <_domain>;
> + };
> + };
> +};
> -- 
> 2.7.1.410.g6faf27b
> 

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

[Rob Herring]

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?

> Signed-off-by: Viresh Kumar 
> Tested-by: Rajendra Nayak 
> ---
>  Documentation/devicetree/bindings/opp/opp.txt | 64 
> +++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
> b/Documentation/devicetree/bindings/opp/opp.txt
> index 9f5ca4457b5f..7f6bb52521b6 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -154,6 +154,15 @@ properties.
>  
>  - status: Marks the node enabled/disabled.
>  
> +- domain-performance-state: A positive integer value representing the minimum
> +  performance level (of the parent domain) required by the consumer as 
> defined
> +  by ../power/power_domain.txt binding document. The OPP nodes can contain 
> the
> +  "domain-performance-state" property, only if the device node contains a
> +  "power-domains" property. The OPP nodes aren't allowed to contain the
> +  "domain-performance-state" property partially, i.e. Either all OPP nodes in
> +  the OPP table have the "domain-performance-state" property or none of them
> +  have it.
> +
>  Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states 
> together.
>  
>  / {
> @@ -528,3 +537,58 @@ Example 5: opp-supported-hw
>   };
>   };
>  };
> +
> +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@10 {
> + opp-hz = /bits/ 64 <10>;
> + domain-performance-state = <1>;

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?

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.

> + };
> + opp@11 {
> + opp-hz = /bits/ 64 <11>;
> + domain-performance-state = <2>;
> + };
> + opp@12 {
> + opp-hz = /bits/ 64 <12>;
> + domain-performance-state = <2>;
> + };
> + };
> +
> + foo_domain: power-controller@1234 {
> + compatible = "foo,power-controller";
> + reg = <0x1234 0x1000>;
> + #power-domain-cells = <0>;
> +
> + performance-states {
> + compatible = "domain-performance-state";
> + pstate@1 {
> + reg = <1>;
> + domain-microvolt = <97 975000 985000>;
> + };
> + pstate@2 {
> + reg = <2>;
> + domain-microvolt = <100 1075000 1085000>;
> + };
> + };
> + }
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + compatible = "arm,cortex-a9";
> + reg = <0>;
> + clocks = <_controller 0>;
> + clock-names = "cpu";
> + operating-points-v2 = <_opp_table>;
> + power-domains = <_domain>;
> + };
> + };
> +};
> -- 
> 2.7.1.410.g6faf27b
> 

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

[Viresh Kumar]

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.

Signed-off-by: Viresh Kumar 
Tested-by: Rajendra Nayak 
---
 Documentation/devicetree/bindings/opp/opp.txt | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
b/Documentation/devicetree/bindings/opp/opp.txt
index 9f5ca4457b5f..7f6bb52521b6 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -154,6 +154,15 @@ properties.
 
 - status: Marks the node enabled/disabled.
 
+- domain-performance-state: A positive integer value representing the minimum
+  performance level (of the parent domain) required by the consumer as defined
+  by ../power/power_domain.txt binding document. The OPP nodes can contain the
+  "domain-performance-state" property, only if the device node contains a
+  "power-domains" property. The OPP nodes aren't allowed to contain the
+  "domain-performance-state" property partially, i.e. Either all OPP nodes in
+  the OPP table have the "domain-performance-state" property or none of them
+  have it.
+
 Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
 
 / {
@@ -528,3 +537,58 @@ Example 5: opp-supported-hw
};
};
 };
+
+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@10 {
+   opp-hz = /bits/ 64 <10>;
+   domain-performance-state = <1>;
+   };
+   opp@11 {
+   opp-hz = /bits/ 64 <11>;
+   domain-performance-state = <2>;
+   };
+   opp@12 {
+   opp-hz = /bits/ 64 <12>;
+   domain-performance-state = <2>;
+   };
+   };
+
+   foo_domain: power-controller@1234 {
+   compatible = "foo,power-controller";
+   reg = <0x1234 0x1000>;
+   #power-domain-cells = <0>;
+
+   performance-states {
+   compatible = "domain-performance-state";
+   pstate@1 {
+   reg = <1>;
+   domain-microvolt = <97 975000 985000>;
+   };
+   pstate@2 {
+   reg = <2>;
+   domain-microvolt = <100 1075000 1085000>;
+   };
+   };
+   }
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "arm,cortex-a9";
+   reg = <0>;
+   clocks = <_controller 0>;
+   clock-names = "cpu";
+   operating-points-v2 = <_opp_table>;
+   power-domains = <_domain>;
+   };
+   };
+};
-- 
2.7.1.410.g6faf27b

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

[Viresh Kumar]

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.

Signed-off-by: Viresh Kumar 
Tested-by: Rajendra Nayak 
---
 Documentation/devicetree/bindings/opp/opp.txt | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
b/Documentation/devicetree/bindings/opp/opp.txt
index 9f5ca4457b5f..7f6bb52521b6 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -154,6 +154,15 @@ properties.
 
 - status: Marks the node enabled/disabled.
 
+- domain-performance-state: A positive integer value representing the minimum
+  performance level (of the parent domain) required by the consumer as defined
+  by ../power/power_domain.txt binding document. The OPP nodes can contain the
+  "domain-performance-state" property, only if the device node contains a
+  "power-domains" property. The OPP nodes aren't allowed to contain the
+  "domain-performance-state" property partially, i.e. Either all OPP nodes in
+  the OPP table have the "domain-performance-state" property or none of them
+  have it.
+
 Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
 
 / {
@@ -528,3 +537,58 @@ Example 5: opp-supported-hw
};
};
 };
+
+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@10 {
+   opp-hz = /bits/ 64 <10>;
+   domain-performance-state = <1>;
+   };
+   opp@11 {
+   opp-hz = /bits/ 64 <11>;
+   domain-performance-state = <2>;
+   };
+   opp@12 {
+   opp-hz = /bits/ 64 <12>;
+   domain-performance-state = <2>;
+   };
+   };
+
+   foo_domain: power-controller@1234 {
+   compatible = "foo,power-controller";
+   reg = <0x1234 0x1000>;
+   #power-domain-cells = <0>;
+
+   performance-states {
+   compatible = "domain-performance-state";
+   pstate@1 {
+   reg = <1>;
+   domain-microvolt = <97 975000 985000>;
+   };
+   pstate@2 {
+   reg = <2>;
+   domain-microvolt = <100 1075000 1085000>;
+   };
+   };
+   }
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "arm,cortex-a9";
+   reg = <0>;
+   clocks = <_controller 0>;
+   clock-names = "cpu";
+   operating-points-v2 = <_opp_table>;
+   power-domains = <_domain>;
+   };
+   };
+};
-- 
2.7.1.410.g6faf27b