Re: [PATCH v1 0/5] CPUFREQ OPP's and Tegra30 support by tegra20-cpufreq driver

[Dmitry Osipenko <digetx@gmail.com>]

On 9/6/18 3:35 PM, Marcel Ziswiler wrote:
> On Thu, 2018-08-30 at 22:43 +0300, Dmitry Osipenko wrote:
>> Hello,
>>
>> This series adds support for CPU frequency scaling on Tegra30 and
>> device
>> tree support that allows to implement thermal throttling and
>> customize
>> available CPU frequencies per-board. The tegra20-cpufreq driver has
>> been
>> re-worked to support that all.
>>
>> Note that Tegra30 support not strictly depends on the clock patches
>> that
>> are under review now, CPUFREQ driver will fail to probe until CCLKG
>> clock
>> will get exposed by the clock driver. Hence this series can be
>> applied
>> independently of the clock patches, CPUFREQ will start to work on
>> Tegra30
>> once both patchsets will be applied.
> 
> In general this seems to work fine both on Colibri T20 as well as
> Apalis/Colibri T30. However I did notice a few things plus have some
> additional questions:
> 
> - Both T20 as well as T30 currently limit the max frequency to 1 GHz
> while there are clearly T30 SKUs which may allow higher frequencies
> (e.g. our regular T30 aka Embedded SKU 1.3 GHz max resp. 1.4 GHz single
> core only, commercial T30 aka AP33 or T33 or whatever it is called up
> to 1.6 GHz max resp. 1.7 GHz single core only). Would I have to allow
> this via custom OPPs in my device tree?

Yes.

> - However, certain OPPs may also require adjusting core/cpu voltages
> which is not yet taken care of as far as I can tell, correct?

Yes, DVFS isn't implemented yet. That could be supported later.

> - I believe in downstream certain OPPs also take silicon parameters aka
> speedo whatever into account. Any comments/plans concerning this?

Good point. There is 'opp-supported-hw' device-tree property which seems is intended
for that purpose. I'll take a look at making use of the property in the next revision,
alternatively that could be implemented later in a distinct patch.

> - With "cpufreq-info -f" I could only observe like the top 3-4 OPPs
> while it does not to go further down even when idling. Why could that
> be resp. what could cause this?

What cpufreq governor are you using?

Here is my 'cpufreq-info --stats' output from Tegra30 after a several minutes of idling after boot:

408000:245884, 456000:445, 608000:251, 760000:151, 816000:82, 912000:75, 1000000:163  (561)

And full cpufreq-info:

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
   driver: tegra
   CPUs which run at the same hardware frequency: 0 1 2 3
   CPUs which need to have their frequency coordinated by software: 0 1 2 3
   maximum transition latency: 50.0 us.
   hardware limits: 408 MHz - 1000 MHz
   available frequency steps: 408 MHz, 456 MHz, 608 MHz, 760 MHz, 816 MHz, 912 MHz, 1000 MHz
   available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
   current policy: frequency should be within 408 MHz and 1000 MHz.
                   The governor "ondemand" may decide which speed to use
                   within this range.
   current CPU frequency is 608 MHz (asserted by call to hardware).
   cpufreq stats: 408 MHz:99.53%, 456 MHz:0.18%, 608 MHz:0.10%, 760 MHz:0.06%, 816 MHz:0.03%, 912 MHz:0.03%, 1000 MHz:0.07%  (563)
analyzing CPU 1:
   driver: tegra
   CPUs which run at the same hardware frequency: 0 1 2 3
   CPUs which need to have their frequency coordinated by software: 0 1 2 3
   maximum transition latency: 50.0 us.
   hardware limits: 408 MHz - 1000 MHz
   available frequency steps: 408 MHz, 456 MHz, 608 MHz, 760 MHz, 816 MHz, 912 MHz, 1000 MHz
   available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
   current policy: frequency should be within 408 MHz and 1000 MHz.
                   The governor "ondemand" may decide which speed to use
                   within this range.
   current CPU frequency is 608 MHz (asserted by call to hardware).
   cpufreq stats: 408 MHz:99.53%, 456 MHz:0.18%, 608 MHz:0.10%, 760 MHz:0.06%, 816 MHz:0.03%, 912 MHz:0.03%, 1000 MHz:0.07%  (563)
analyzing CPU 2:
   driver: tegra
   CPUs which run at the same hardware frequency: 0 1 2 3
   CPUs which need to have their frequency coordinated by software: 0 1 2 3
   maximum transition latency: 50.0 us.
   hardware limits: 408 MHz - 1000 MHz
   available frequency steps: 408 MHz, 456 MHz, 608 MHz, 760 MHz, 816 MHz, 912 MHz, 1000 MHz
   available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
   current policy: frequency should be within 408 MHz and 1000 MHz.
                   The governor "ondemand" may decide which speed to use
                   within this range.
   current CPU frequency is 608 MHz (asserted by call to hardware).
   cpufreq stats: 408 MHz:99.53%, 456 MHz:0.18%, 608 MHz:0.10%, 760 MHz:0.06%, 816 MHz:0.03%, 912 MHz:0.03%, 1000 MHz:0.07%  (563)
analyzing CPU 3:
   driver: tegra
   CPUs which run at the same hardware frequency: 0 1 2 3
   CPUs which need to have their frequency coordinated by software: 0 1 2 3
   maximum transition latency: 50.0 us.
   hardware limits: 408 MHz - 1000 MHz
   available frequency steps: 408 MHz, 456 MHz, 608 MHz, 760 MHz, 816 MHz, 912 MHz, 1000 MHz
   available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
   current policy: frequency should be within 408 MHz and 1000 MHz.
                   The governor "ondemand" may decide which speed to use
                   within this range.
   current CPU frequency is 608 MHz (asserted by call to hardware).
   cpufreq stats: 408 MHz:99.53%, 456 MHz:0.18%, 608 MHz:0.10%, 760 MHz:0.06%, 816 MHz:0.03%, 912 MHz:0.03%, 1000 MHz:0.07%  (563)


> - Unfortunately "cpufreq-info --stats" currently does not seem to
> output anything. Would that require something special to be
> implemented?

Make sure that CONFIG_CPU_FREQ_STAT is enabled in the kernels config.

> Other than that you may add the following to the whole series:
> 
> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>

Thank you very much!