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

Groups > linux.kernel > #1552037 > unrolled thread

[PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS

Back to article view | Back to linux.kernel

Contents

  [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS Neil Armstrong <narmstrong@baylibre.com> - 2017-01-05 16:10 +0100
    Re: [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS Michał Zegan <webczat_200@poczta.onet.pl> - 2017-01-05 20:20 +0100
      Re: [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS Neil Armstrong <narmstrong@baylibre.com> - 2017-01-06 09:10 +0100
      Re: [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS Michał Zegan <webczat_200@poczta.onet.pl> - 2017-01-06 14:30 +0100

#1552037 — [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS

The current hardware is not able to run with all cores enabled at a
cluster frequency superior at 1536MHz.
But the currently shipped u-boot for the platform still reports an OPP
table with possible DVFS frequency up to 2GHz, and will not change since
the off-tree linux tree supports limiting the OPPs with a kernel parameter.
A recent u-boot change reports the boot-time DVFS around 100MHz and
the default performance cpufreq governor sets the maximum frequency.
Previous version of u-boot reported to be already at the max OPP and
left the OPP as is.
Nevertheless, other governors like ondemand could setup the max frequency
and make the system crash.

This patch disables the DVFS clock and disables cpufreq.

Fixes: 70db166a2baa ("ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..5e63e3b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -137,6 +137,10 @@
 	};
 };
 
+&scpi_dvfs {
+	status = "disabled";
+};
+
 &uart_AO {
 	status = "okay";
 	pinctrl-0 = <&uart_ao_a_pins>;
-- 
1.9.1

[toc] | [next] | [standalone]

#1552265

[Multipart message — attachments visible in raw view] — view raw

Hello.

The patch causes cpufreq module (scpi-cpufreq) not to detect cpufreq, so
it actually works, but...
Loading the module causes few errors because of not found frequencies or
something, then it is all okay. However after loading scpi-cpufreq you
cannot actually power the cpu off and on. You will power it off
successfully, but when trying to power it on, the cpufreq driver will
error out, and then after it happens, the cpu that was trying to go
online will be offline again, and that is a little... unfortunate. The
question is, and I cannot really test that: will the module actually
autoload after this change?

W dniu 05.01.2017 o 16:02, Neil Armstrong pisze:
> The current hardware is not able to run with all cores enabled at a
> cluster frequency superior at 1536MHz.
> But the currently shipped u-boot for the platform still reports an OPP
> table with possible DVFS frequency up to 2GHz, and will not change since
> the off-tree linux tree supports limiting the OPPs with a kernel parameter.
> A recent u-boot change reports the boot-time DVFS around 100MHz and
> the default performance cpufreq governor sets the maximum frequency.
> Previous version of u-boot reported to be already at the max OPP and
> left the OPP as is.
> Nevertheless, other governors like ondemand could setup the max frequency
> and make the system crash.
> 
> This patch disables the DVFS clock and disables cpufreq.
> 
> Fixes: 70db166a2baa ("ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbea..5e63e3b 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -137,6 +137,10 @@
>  	};
>  };
>  
> +&scpi_dvfs {
> +	status = "disabled";
> +};
> +
>  &uart_AO {
>  	status = "okay";
>  	pinctrl-0 = <&uart_ao_a_pins>;
> 

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

#1552585

[Multipart message — attachments visible in raw view] — view raw

On 01/05/2017 08:04 PM, Michał Zegan wrote:
> Hello.
> 
> The patch causes cpufreq module (scpi-cpufreq) not to detect cpufreq, so
> it actually works, but...
> Loading the module causes few errors because of not found frequencies or
> something, then it is all okay. However after loading scpi-cpufreq you
> cannot actually power the cpu off and on. You will power it off
> successfully, but when trying to power it on, the cpufreq driver will
> error out, and then after it happens, the cpu that was trying to go
> online will be offline again, and that is a little... unfortunate. The
> question is, and I cannot really test that: will the module actually
> autoload after this change?

Hi Michal,

You are right, it breaks cpufreq and the cpu hotplug feature, I will send a v2 completely disabling cpufreq instead.

For the module autoloading, the arm_scpi.ko must be loaded before the other scpi modules.

Please ask Sudeep Holla <sudeep.holla@arm.com> if module autoloading for scpi is meant to work.

Neil


> 
> W dniu 05.01.2017 o 16:02, Neil Armstrong pisze:
>> The current hardware is not able to run with all cores enabled at a
>> cluster frequency superior at 1536MHz.
>> But the currently shipped u-boot for the platform still reports an OPP
>> table with possible DVFS frequency up to 2GHz, and will not change since
>> the off-tree linux tree supports limiting the OPPs with a kernel parameter.
>> A recent u-boot change reports the boot-time DVFS around 100MHz and
>> the default performance cpufreq governor sets the maximum frequency.
>> Previous version of u-boot reported to be already at the max OPP and
>> left the OPP as is.
>> Nevertheless, other governors like ondemand could setup the max frequency
>> and make the system crash.
>>
>> This patch disables the DVFS clock and disables cpufreq.
>>
>> Fixes: 70db166a2baa ("ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes")
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> index 238fbea..5e63e3b 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> @@ -137,6 +137,10 @@
>>  	};
>>  };
>>  
>> +&scpi_dvfs {
>> +	status = "disabled";
>> +};
>> +
>>  &uart_AO {
>>  	status = "okay";
>>  	pinctrl-0 = <&uart_ao_a_pins>;
>>
> 

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

#1552777

[Multipart message — attachments visible in raw view] — view raw

Yes, I meant what you think I meant. :) thanks

W dniu 06.01.2017 o 12:54, Sudeep Holla pisze:
> Hi Michał,
> 
> On 05/01/17 19:04, Michał Zegan wrote:
>> Hello.
>>
>> The patch causes cpufreq module (scpi-cpufreq) not to detect cpufreq, so
>> it actually works, but...
>> Loading the module causes few errors because of not found frequencies or
>> something, then it is all okay. However after loading scpi-cpufreq you
>> cannot actually power the cpu off and on. You will power it off
>> successfully, but when trying to power it on, the cpufreq driver will
>> error out, 
> 
> Yes I had noticed this in past, this needs to be fixed. I had a patch
> and seems like it slipped through the cracks. I will fins and post it.
> 
>> and then after it happens, the cpu that was trying to go
>> online will be offline again, and that is a little... unfortunate. The
> 
> IIUC, you mean the cpufreq drive spits error on every hotplug event ?
> If so yes, otherwise I think I didn't understand you concern above.
> 
>> question is, and I cannot really test that: will the module actually
>> autoload after this change?
>>
> 
> It should work, I had tested this in past.
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web