Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1622379 > unrolled thread

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Sudeep Holla <sudeep.holla@arm.com> - 2017-04-12 19:10 +0200
    Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Viresh Kumar <viresh.kumar@linaro.org> - 2017-04-13 08:00 +0200
      Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Sudeep Holla <sudeep.holla@arm.com> - 2017-04-13 15:50 +0200
        Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Viresh Kumar <viresh.kumar@linaro.org> - 2017-04-17 07:40 +0200
          Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Sudeep Holla <sudeep.holla@arm.com> - 2017-04-18 18:10 +0200
            Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Viresh Kumar <viresh.kumar@linaro.org> - 2017-04-19 12:20 +0200

#1622379 — Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 20/03/17 09:32, Viresh Kumar wrote:
[...]

> +
> +Example 7: domain-Performance-state:
> +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2)
> +
> +/ {
> +	domain_opp_table: opp_table0 {
> +		compatible = "operating-points-v2";
> +
> +		opp@1 {
> +			domain-performance-state = <1>;
> +			opp-microvolt = <975000 970000 985000>;
> +		};
> +		opp@2 {
> +			domain-performance-state = <2>;
> +			opp-microvolt = <1075000 1000000 1085000>;
> +		};
> +	};
> +
> +	foo_domain: power-controller@12340000 {
> +		compatible = "foo,power-controller";
> +		reg = <0x12340000 0x1000>;
> +		#power-domain-cells = <0>;
> +		operating-points-v2 = <&domain_opp_table>;
> +	}
> +
> +	cpu0_opp_table: opp_table1 {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp@1000000000 {
> +			opp-hz = /bits/ 64 <1000000000>;
> +			domain-performance-state = <1>;
> +		};
> +		opp@1100000000 {
> +			opp-hz = /bits/ 64 <1100000000>;
> +			domain-performance-state = <2>;
> +		};
> +		opp@1200000000 {
> +			opp-hz = /bits/ 64 <1200000000>;
> +			domain-performance-state = <2>;
> +		};
> +	};
> +
> +	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>;
> +		};
> +	};
> +};


Thinking more about this above example, I think you need more
explanation. So in the above case you have cpu with clock controller,
power-domain and the OPP table info, I can think of few things that need
to be explicit:

1. How does the precedence look like ?

2. Since power-domains with OPP table control the performance state, do
   we ignore clock and operating-points-v2 in the above case completely?

3. Will the power-domain drive the OPP ?

-- 
Regards,
Sudeep

[toc] | [next] | [standalone]

#1622727

On 12-04-17, 18:05, Sudeep Holla wrote:
> 
> 
> On 20/03/17 09:32, Viresh Kumar wrote:
> [...]
> 
> > +
> > +Example 7: domain-Performance-state:
> > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2)
> > +
> > +/ {
> > +	domain_opp_table: opp_table0 {
> > +		compatible = "operating-points-v2";
> > +
> > +		opp@1 {
> > +			domain-performance-state = <1>;
> > +			opp-microvolt = <975000 970000 985000>;
> > +		};
> > +		opp@2 {
> > +			domain-performance-state = <2>;
> > +			opp-microvolt = <1075000 1000000 1085000>;
> > +		};
> > +	};
> > +
> > +	foo_domain: power-controller@12340000 {
> > +		compatible = "foo,power-controller";
> > +		reg = <0x12340000 0x1000>;
> > +		#power-domain-cells = <0>;
> > +		operating-points-v2 = <&domain_opp_table>;
> > +	}
> > +
> > +	cpu0_opp_table: opp_table1 {
> > +		compatible = "operating-points-v2";
> > +		opp-shared;
> > +
> > +		opp@1000000000 {
> > +			opp-hz = /bits/ 64 <1000000000>;
> > +			domain-performance-state = <1>;
> > +		};
> > +		opp@1100000000 {
> > +			opp-hz = /bits/ 64 <1100000000>;
> > +			domain-performance-state = <2>;
> > +		};
> > +		opp@1200000000 {
> > +			opp-hz = /bits/ 64 <1200000000>;
> > +			domain-performance-state = <2>;
> > +		};
> > +	};
> > +
> > +	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>;
> > +		};
> > +	};
> > +};
> 
> 
> Thinking more about this above example, I think you need more
> explanation. So in the above case you have cpu with clock controller,
> power-domain and the OPP table info, I can think of few things that need
> to be explicit:
> 
> 1. How does the precedence look like ?

Just think of the power-domain as a regulator here. If we are
increasing frequency of the device, power-domain needs to be
programmed first followed by the clock.

> 2. Since power-domains with OPP table control the performance state, do

They control performance state of the domains, not the devices.

>    we ignore clock and operating-points-v2 in the above case completely?

No. They are separate.

> 
> 3. Will the power-domain drive the OPP ?

power-domain will driver its own state using its own OPP table.
Devices may fine tune within those states.

-- 
viresh

[toc] | [prev] | [next] | [standalone]

#1623042

On 13/04/17 06:50, Viresh Kumar wrote:
> On 12-04-17, 18:05, Sudeep Holla wrote:
>>
>>
>> On 20/03/17 09:32, Viresh Kumar wrote:

[...]

>>
>> Thinking more about this above example, I think you need more
>> explanation. So in the above case you have cpu with clock controller,
>> power-domain and the OPP table info, I can think of few things that need
>> to be explicit:
>>
>> 1. How does the precedence look like ?
> 
> Just think of the power-domain as a regulator here. If we are
> increasing frequency of the device, power-domain needs to be
> programmed first followed by the clock.
> 

Interesting. My understand of power domain and in particular power
domain performance was that it would control both. The abstract number
you introduce would hide clocks and regulators.

But if the concept treats it just as yet another regulator, we do we
need these at all. Why don't we relate this performance to regulator
values and be done with it ?

Sorry if I am missing to understand something here. I would look this as
replacement for both clocks and regulators, something similar to ACPI
CPPC. If not, it looks unnecessary to me with the information I have got
so far.

>> 2. Since power-domains with OPP table control the performance state, do
> 
> They control performance state of the domains, not the devices.
> 
>>    we ignore clock and operating-points-v2 in the above case completely?
> 
> No. They are separate.
>

Understood now, but still trying to understand the complexity introduced
here.

>>
>> 3. Will the power-domain drive the OPP ?
> 
> power-domain will driver its own state using its own OPP table.
> Devices may fine tune within those states.
> 

I fail to understand here. This makes me think this power domain is same
as regulators as you pointed out earlier. So, we do we need all these
extra things. I was hoping this to be something like ACPI CPPC that hide
away clock and regulators.

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1624535

On 13-04-17, 14:43, Sudeep Holla wrote:
> Interesting. My understand of power domain and in particular power
> domain performance was that it would control both. The abstract number
> you introduce would hide clocks and regulators.
> 
> But if the concept treats it just as yet another regulator, we do we
> need these at all. Why don't we relate this performance to regulator
> values and be done with it ?
> 
> Sorry if I am missing to understand something here. I would look this as
> replacement for both clocks and regulators, something similar to ACPI
> CPPC. If not, it looks unnecessary to me with the information I have got
> so far.

I kind of answered that in the other email.

Some background may be good here. So Qcom tried to solve all this with virtual
regulators, but the problem was that they need to talk in terms of integer
values (1, 2, 3..) and not voltages and so they can't use the regulator
framework straight away. And so we are doing all this.

-- 
viresh

[toc] | [prev] | [next] | [standalone]

#1625422

On 17/04/17 06:33, Viresh Kumar wrote:
> On 13-04-17, 14:43, Sudeep Holla wrote:
>> Interesting. My understand of power domain and in particular power
>> domain performance was that it would control both. The abstract number
>> you introduce would hide clocks and regulators.
>>
>> But if the concept treats it just as yet another regulator, we do we
>> need these at all. Why don't we relate this performance to regulator
>> values and be done with it ?
>>
>> Sorry if I am missing to understand something here. I would look this as
>> replacement for both clocks and regulators, something similar to ACPI
>> CPPC. If not, it looks unnecessary to me with the information I have got
>> so far.
> 
> I kind of answered that in the other email.
> 
> Some background may be good here. So Qcom tried to solve all this with virtual
> regulators, but the problem was that they need to talk in terms of integer
> values (1, 2, 3..) and not voltages and so they can't use the regulator
> framework straight away. And so we are doing all this.
> 

Was it posted externally ? Was there any objections for that approach ?
IMO that's better approach but if I am late to the party, I would like
to read through the discussions that happened on it(if any)

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1625994

On 18-04-17, 17:03, Sudeep Holla wrote:
> Was it posted externally ? Was there any objections for that approach ?
> IMO that's better approach but if I am late to the party, I would like
> to read through the discussions that happened on it(if any)

Maybe Stephen can tell more about it. AFAIK, there were some offline
discussions around it.

-- 
viresh

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web