Plain DFS (no voltage scaling)

Plain DFS (no voltage scaling)

[Mason]

Hello,

I plan to enable the on-demand governor on the tango platform:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi

I found the cpufreq-dt binding doc:

https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt

Something is not clear to me:

If my platform cannot scale the voltage, what information
should I put in the voltage part of the DT?

Regards.

Plain DFS (no voltage scaling)

[Viresh Kumar]

On 02-02-16, 22:11, Mason wrote:
> Hello,
> 
> I plan to enable the on-demand governor on the tango platform:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
> 
> I found the cpufreq-dt binding doc:
> 
> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> 
> Something is not clear to me:
> 
> If my platform cannot scale the voltage, what information
> should I put in the voltage part of the DT?

Wouldn't matter if there is no regulator. i.e. you should keep 0, but
even if they have something non-zero, core code will ignore it. But
yeah, it makes sense to keep it zero.

-- 
viresh

Plain DFS (no voltage scaling)

[Mason]

On 03/02/2016 03:10, Viresh Kumar wrote:
> On 02-02-16, 22:11, Mason wrote:
>> Hello,
>>
>> I plan to enable the on-demand governor on the tango platform:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
>>
>> I found the cpufreq-dt binding doc:
>>
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
>>
>> Something is not clear to me:
>>
>> If my platform cannot scale the voltage, what information
>> should I put in the voltage part of the DT?
> 
> Wouldn't matter if there is no regulator. i.e. you should keep 0, but
> even if they have something non-zero, core code will ignore it. But
> yeah, it makes sense to keep it zero.

Hmmm, I am missing something obvious.

My config contains:

CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPUFREQ_DT=y

Yet, neither dt_cpufreq_probe() nor cpufreq_init() are being called.

Could someone please point to my mistake?

Regards.

Plain DFS (no voltage scaling)

[Viresh Kumar]

On 03-02-16, 16:35, Mason wrote:
> On 03/02/2016 03:10, Viresh Kumar wrote:
> > On 02-02-16, 22:11, Mason wrote:
> >> Hello,
> >>
> >> I plan to enable the on-demand governor on the tango platform:
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
> >>
> >> I found the cpufreq-dt binding doc:
> >>
> >> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
> >> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> >>
> >> Something is not clear to me:
> >>
> >> If my platform cannot scale the voltage, what information
> >> should I put in the voltage part of the DT?
> > 
> > Wouldn't matter if there is no regulator. i.e. you should keep 0, but
> > even if they have something non-zero, core code will ignore it. But
> > yeah, it makes sense to keep it zero.
> 
> Hmmm, I am missing something obvious.
> 
> My config contains:
> 
> CONFIG_CPU_FREQ=y
> CONFIG_CPU_FREQ_GOV_COMMON=y
> CONFIG_CPU_FREQ_STAT=y
> CONFIG_CPU_FREQ_STAT_DETAILS=y
> CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> CONFIG_CPUFREQ_DT=y
> 
> Yet, neither dt_cpufreq_probe() nor cpufreq_init() are being called.
> 
> Could someone please point to my mistake?

You need to create a platform device to get cpufreq-dt driver probed.
Check other users..

-- 
viresh

Plain DFS (no voltage scaling)

[Mason]

On 03/02/2016 17:14, Viresh Kumar wrote:
> On 03-02-16, 16:35, Mason wrote:
>> On 03/02/2016 03:10, Viresh Kumar wrote:
>>> On 02-02-16, 22:11, Mason wrote:
>>>> Hello,
>>>>
>>>> I plan to enable the on-demand governor on the tango platform:
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
>>>>
>>>> I found the cpufreq-dt binding doc:
>>>>
>>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
>>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
>>>>
>>>> Something is not clear to me:
>>>>
>>>> If my platform cannot scale the voltage, what information
>>>> should I put in the voltage part of the DT?
>>>
>>> Wouldn't matter if there is no regulator. i.e. you should keep 0, but
>>> even if they have something non-zero, core code will ignore it. But
>>> yeah, it makes sense to keep it zero.
>>
>> Hmmm, I am missing something obvious.
>>
>> My config contains:
>>
>> CONFIG_CPU_FREQ=y
>> CONFIG_CPU_FREQ_GOV_COMMON=y
>> CONFIG_CPU_FREQ_STAT=y
>> CONFIG_CPU_FREQ_STAT_DETAILS=y
>> CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
>> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
>> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
>> CONFIG_CPUFREQ_DT=y
>>
>> Yet, neither dt_cpufreq_probe() nor cpufreq_init() are being called.
>>
>> Could someone please point to my mistake?
> 
> You need to create a platform device to get cpufreq-dt driver probed.
> Check other users..

The sunxi guys pointed me in the right direction.

http://lxr.free-electrons.com/source/arch/arm/mach-sunxi/sunxi.c#L20

Why isn't there a compatible string like other drivers?

Such as
  compatible = "cpufreq-dt"
which would enable cpufreq on the platform?

Regards.

Plain DFS (no voltage scaling)

[Viresh Kumar]

On 03-02-16, 19:25, Mason wrote:
> The sunxi guys pointed me in the right direction.
> 
> http://lxr.free-electrons.com/source/arch/arm/mach-sunxi/sunxi.c#L20
> 
> Why isn't there a compatible string like other drivers?
> 
> Such as
>   compatible = "cpufreq-dt"
> which would enable cpufreq on the platform?

Because DT can't have nodes for virtual devices :(

-- 
viresh

Plain DFS (no voltage scaling)

[Mason]

On 02/02/2016 22:11, Mason wrote:

> I plan to enable the on-demand governor on the tango platform:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
> 
> I found the cpufreq-dt binding doc:
> 
> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> 
> Something is not clear to me:
> 
> If my platform cannot scale the voltage, what information
> should I put in the voltage part of the DT?

Someone pointed out that tweaking the frequency without tweaking
the voltage might be counter-productive.

I measured the power consumption of the entire board (at the power outlet)
for 3 CPU frequencies (all other things being equal, I hope).

idle @ 111 MHz = 4.6 W
idle @ 333 MHz = 4.6 W
idle @ 999 MHz = 4.6 W

load @ 111 MHz = 5.0 W
load @ 333 MHz = 5.7 W
load @ 999 MHz = 7.7 W

When idle, the kernel calls WFI, which "turns off" most of the CPU
(clock gating?) such that the actual frequency does not matter.

At full load (I use cpuburn to jog as many FUs simultaneously as
possible) it looks like each additional MHz requires ~3 mW.

So it would appear that an on-demand governor might not help to
save power.

But I have another use-case in mind: CPU throttling on over-heating.
There's a temperature sensor in the CPU, and I'd like to say:
"if temperature exceeds a user-set threshold, don't run at the max
frequency until the temperature becomes reasonable".

And I think that requires cpufreq?

Regards.

Plain DFS (no voltage scaling)

[Viresh Kumar]

On 03-02-16, 16:07, Mason wrote:
> On 02/02/2016 22:11, Mason wrote:
> 
> > I plan to enable the on-demand governor on the tango platform:
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
> > 
> > I found the cpufreq-dt binding doc:
> > 
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> > 
> > Something is not clear to me:
> > 
> > If my platform cannot scale the voltage, what information
> > should I put in the voltage part of the DT?
> 
> Someone pointed out that tweaking the frequency without tweaking
> the voltage might be counter-productive.
> 
> I measured the power consumption of the entire board (at the power outlet)
> for 3 CPU frequencies (all other things being equal, I hope).
> 
> idle @ 111 MHz = 4.6 W
> idle @ 333 MHz = 4.6 W
> idle @ 999 MHz = 4.6 W
> 
> load @ 111 MHz = 5.0 W
> load @ 333 MHz = 5.7 W
> load @ 999 MHz = 7.7 W
> 
> When idle, the kernel calls WFI, which "turns off" most of the CPU
> (clock gating?) such that the actual frequency does not matter.
> 
> At full load (I use cpuburn to jog as many FUs simultaneously as
> possible) it looks like each additional MHz requires ~3 mW.
> 
> So it would appear that an on-demand governor might not help to
> save power.

Why do you say so ?

> But I have another use-case in mind: CPU throttling on over-heating.
> There's a temperature sensor in the CPU, and I'd like to say:
> "if temperature exceeds a user-set threshold, don't run at the max
> frequency until the temperature becomes reasonable".
> 
> And I think that requires cpufreq?
> 
> Regards.

-- 
viresh

Plain DFS (no voltage scaling)

[Mason]

On 03/02/2016 17:13, Viresh Kumar wrote:
> On 03-02-16, 16:07, Mason wrote:
>> On 02/02/2016 22:11, Mason wrote:
>>
>>> I plan to enable the on-demand governor on the tango platform:
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
>>>
>>> I found the cpufreq-dt binding doc:
>>>
>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
>>>
>>> Something is not clear to me:
>>>
>>> If my platform cannot scale the voltage, what information
>>> should I put in the voltage part of the DT?
>>
>> Someone pointed out that tweaking the frequency without tweaking
>> the voltage might be counter-productive.
>>
>> I measured the power consumption of the entire board (at the power outlet)
>> for 3 CPU frequencies (all other things being equal, I hope).
>>
>> idle @ 111 MHz = 4.6 W
>> idle @ 333 MHz = 4.6 W
>> idle @ 999 MHz = 4.6 W
>>
>> load @ 111 MHz = 5.0 W
>> load @ 333 MHz = 5.7 W
>> load @ 999 MHz = 7.7 W
>>
>> When idle, the kernel calls WFI, which "turns off" most of the CPU
>> (clock gating?) such that the actual frequency does not matter.
>>
>> At full load (I use cpuburn to jog as many FUs simultaneously as
>> possible) it looks like each additional MHz requires ~3 mW.
>>
>> So it would appear that an on-demand governor might not help to
>> save power.
> 
> Why do you say so ?

Here's my (possibly incorrect) reasoning:

If the CPU is idle, kernel calls WFI and frequency apparently
doesn't matter.

If the CPU has work to do, the on-demand governor will bump the
frequency to the max (I think).

I don't think the CPU spends a lot of time in the intermediate
frequencies (neither max nor min).

But maybe my logic is flawed?

Also, some users (of our older kernel) reported problems were
they considered the on-demand governor was "too slow" to ramp
the frequency up. (But I don't know if they'd played with the
configuration knobs.)

Regards.

Plain DFS (no voltage scaling)

[Viresh Kumar]

On 03-02-16, 19:19, Mason wrote:
> On 03/02/2016 17:13, Viresh Kumar wrote:
> > On 03-02-16, 16:07, Mason wrote:
> >> On 02/02/2016 22:11, Mason wrote:
> >>
> >>> I plan to enable the on-demand governor on the tango platform:
> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
> >>>
> >>> I found the cpufreq-dt binding doc:
> >>>
> >>> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
> >>> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> >>>
> >>> Something is not clear to me:
> >>>
> >>> If my platform cannot scale the voltage, what information
> >>> should I put in the voltage part of the DT?
> >>
> >> Someone pointed out that tweaking the frequency without tweaking
> >> the voltage might be counter-productive.
> >>
> >> I measured the power consumption of the entire board (at the power outlet)
> >> for 3 CPU frequencies (all other things being equal, I hope).
> >>
> >> idle @ 111 MHz = 4.6 W
> >> idle @ 333 MHz = 4.6 W
> >> idle @ 999 MHz = 4.6 W
> >>
> >> load @ 111 MHz = 5.0 W
> >> load @ 333 MHz = 5.7 W
> >> load @ 999 MHz = 7.7 W
> >>
> >> When idle, the kernel calls WFI, which "turns off" most of the CPU
> >> (clock gating?) such that the actual frequency does not matter.
> >>
> >> At full load (I use cpuburn to jog as many FUs simultaneously as
> >> possible) it looks like each additional MHz requires ~3 mW.
> >>
> >> So it would appear that an on-demand governor might not help to
> >> save power.

IOW, what's so special about how on-demand will behave in your case ?
If it doesn't work properly, then that's the same for everybody, isn't
it ?

> > Why do you say so ?
> 
> Here's my (possibly incorrect) reasoning:
> 
> If the CPU is idle, kernel calls WFI and frequency apparently
> doesn't matter.

Right.

> If the CPU has work to do, the on-demand governor will bump the
> frequency to the max (I think).

Not always, but it will choose the best frequency based on the load.

> I don't think the CPU spends a lot of time in the intermediate
> frequencies (neither max nor min).

It does, it was fixed somewhere in v3.* .

> But maybe my logic is flawed?

Yes.

> Also, some users (of our older kernel) reported problems were
> they considered the on-demand governor was "too slow" to ramp
> the frequency up. (But I don't know if they'd played with the
> configuration knobs.)

Shouldn't be the case anymore, or maybe those guys are more in favor
of the interactive governor :)

-- 
viresh