| Message ID | 20180830194356.14059-1-digetx@gmail.com |
|---|---|
| Headers | show |
| Series | CPUFREQ OPP's and Tegra30 support by tegra20-cpufreq driver | expand |
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? - However, certain OPPs may also require adjusting core/cpu voltages which is not yet taken care of as far as I can tell, correct? - I believe in downstream certain OPPs also take silicon parameters aka speedo whatever into account. Any comments/plans concerning this? - 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? - Unfortunately "cpufreq-info --stats" currently does not seem to output anything. Would that require something special to be implemented? Other than that you may add the following to the whole series: Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> > Dmitry Osipenko (5): > dt-bindings: cpufreq: Add binding for NVIDIA Tegra20/30 > cpufreq: tegra20: Support OPP, thermal cooling and Tegra30 > ARM: tegra: Create tegra20-cpufreq device on Tegra30 > ARM: dts: tegra20: Add CPU Operating Performance Points > ARM: dts: tegra30: Add CPU Operating Performance Points > > .../cpufreq/nvidia,tegra20-cpufreq.txt | 38 ++ > arch/arm/boot/dts/tegra20.dtsi | 58 +++ > arch/arm/boot/dts/tegra30.dtsi | 65 ++++ > arch/arm/mach-tegra/tegra.c | 4 + > drivers/cpufreq/Kconfig.arm | 2 + > drivers/cpufreq/cpufreq-dt-platdev.c | 2 + > drivers/cpufreq/tegra20-cpufreq.c | 334 +++++++++++++--- > -- > 7 files changed, 422 insertions(+), 81 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
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!
On Fri, 2018-09-07 at 19:59 +0300, Dmitry Osipenko wrote: - snip - > > - 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? ondemand > 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. Yes, sorry. That was it, of course. Just wondering why that one isn't enabled in tegra_defconfig... > > Other than that you may add the following to the whole series: > > > > Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> > > Thank you very much! You are very welcome. Thank you!
On 9/11/18 11:27 AM, Marcel Ziswiler wrote: > On Fri, 2018-09-07 at 19:59 +0300, Dmitry Osipenko wrote: > > - snip - > >>> - 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? > > ondemand > >> 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. > > Yes, sorry. That was it, of course. Just wondering why that one isn't > enabled in tegra_defconfig... That option isn't essential for the kernel, though usually such useful and low-overhead features are welcome. IIRC, tegra_defconfig misses more important options (like namespaces) that are required by Linux distro's to work properly. >>> Other than that you may add the following to the whole series: >>> >>> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> >> >> Thank you very much! > > You are very welcome. Thank you! >
On 30/08/2018 20:43, Dmitry Osipenko wrote: > Add support for thermal throttling and Operating Performance Points. > Driver now relies on OPP's supplied via device tree and therefore will > work only on devices that use the updated device tree. The generalization > of the driver allows to transparently support Tegra30. Thierry, can we or should we do this? Cheers Jon
On 30/08/2018 20:43, Dmitry Osipenko wrote: > Tegra20-cpufreq driver require a platform device in order to be loaded, > instantiate a simple platform device for the driver during of the machines > late initialization. Driver now supports Tegra30 SoC's, hence create the > device on Tegra30 machines. > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > arch/arm/mach-tegra/tegra.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c > index 67d8ae60ac67..b559e22eab76 100644 > --- a/arch/arm/mach-tegra/tegra.c > +++ b/arch/arm/mach-tegra/tegra.c > @@ -111,6 +111,10 @@ static void __init tegra_dt_init_late(void) > if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) && > of_machine_is_compatible("nvidia,tegra20")) > platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0); > + > + if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC) && > + of_machine_is_compatible("nvidia,tegra30")) > + platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0); > } > > static const char * const tegra_dt_board_compat[] = { Not sure why you would do this if now the driver only works with DT. Am I missing something? Cheers Jon
On 17/10/2018 09:49, Jon Hunter wrote: > > On 30/08/2018 20:43, Dmitry Osipenko wrote: >> Tegra20-cpufreq driver require a platform device in order to be loaded, >> instantiate a simple platform device for the driver during of the machines >> late initialization. Driver now supports Tegra30 SoC's, hence create the >> device on Tegra30 machines. >> >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >> --- >> arch/arm/mach-tegra/tegra.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c >> index 67d8ae60ac67..b559e22eab76 100644 >> --- a/arch/arm/mach-tegra/tegra.c >> +++ b/arch/arm/mach-tegra/tegra.c >> @@ -111,6 +111,10 @@ static void __init tegra_dt_init_late(void) >> if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) && >> of_machine_is_compatible("nvidia,tegra20")) >> platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0); >> + >> + if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC) && >> + of_machine_is_compatible("nvidia,tegra30")) >> + platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0); >> } >> >> static const char * const tegra_dt_board_compat[] = { > > Not sure why you would do this if now the driver only works with DT. Am > I missing something? Actually, not sure why we just don't move this into the actual driver itself like we have for tegra124. Cheers Jon
On 10/17/18 12:54 PM, Jon Hunter wrote: > > On 17/10/2018 09:49, Jon Hunter wrote: >> >> On 30/08/2018 20:43, Dmitry Osipenko wrote: >>> Tegra20-cpufreq driver require a platform device in order to be loaded, >>> instantiate a simple platform device for the driver during of the machines >>> late initialization. Driver now supports Tegra30 SoC's, hence create the >>> device on Tegra30 machines. >>> >>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>> --- >>> arch/arm/mach-tegra/tegra.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c >>> index 67d8ae60ac67..b559e22eab76 100644 >>> --- a/arch/arm/mach-tegra/tegra.c >>> +++ b/arch/arm/mach-tegra/tegra.c >>> @@ -111,6 +111,10 @@ static void __init tegra_dt_init_late(void) >>> if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) && >>> of_machine_is_compatible("nvidia,tegra20")) >>> platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0); >>> + >>> + if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC) && >>> + of_machine_is_compatible("nvidia,tegra30")) >>> + platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0); >>> } >>> >>> static const char * const tegra_dt_board_compat[] = { >> >> Not sure why you would do this if now the driver only works with DT. Am >> I missing something? > > Actually, not sure why we just don't move this into the actual driver > itself like we have for tegra124. Tegra124 has specific HW for the CPUFreq, T20/30 do not. Hence on T20/30 CPUFreq control is implemented purely in software and there is no real HW device for the driver.