[PATCH 0/2] ARM: dts: sunxi: Fix cpufreq instabilities

[PATCH 0/2] ARM: dts: sunxi: Fix cpufreq instabilities

[Chen-Yu Tsai]

Hi Maxime,

Here are 2 dts fixes for sunxi cpufreq support, aimed at 4.0.

The first patch limits the Olimex A10-Lime to 960MHz, as a few people
reported on IRC that it was unstable at 1008MHz.

The second patch removes the overclocking settings from sun5i/sun7i
dts, so all the boards will be stable, regardless of whether regulators
were added or not.

I would like to revisit this after the new OPP bindings are merged
and support added to cpufreq-dt.


Regards
ChenYu


Chen-Yu Tsai (2):
  ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting
  ARM: dts: sunxi: Remove overclocked/overvoltaged OPP

 arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 14 ++++++++++++++
 arch/arm/boot/dts/sun5i-a13.dtsi               |  3 +--
 arch/arm/boot/dts/sun7i-a20.dtsi               |  3 +--
 3 files changed, 16 insertions(+), 4 deletions(-)

-- 
2.1.4

[PATCH 1/2] ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting

[Chen-Yu Tsai]

The Olimex A10-Lime is known to be unstable when running at 1008MHz.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
index 31dc2f1c3870..16ecb8938e19 100644
--- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
@@ -74,6 +74,20 @@
 	status = "okay";
 };
 
+&cpu0 {
+	/* The A10-Lime is known to be unstable when running at 1008 MHz */
+	operating-points = <
+		/* kHz    uV */
+		960000  1400000
+		912000  1400000
+		864000  1300000
+		720000  1200000
+		528000  1100000
+		312000  1000000
+		144000  900000
+		>;
+};
+
 &ehci0 {
 	status = "okay";
 };
-- 
2.1.4

[PATCH 2/2] ARM: dts: sunxi: Remove overclocked/overvoltaged OPP

[Chen-Yu Tsai]

Without proper regulator support for individual boards, it is dangerous
to have overclocked/overvoltaged OPPs in the list. Cpufreq will increase
the frequency without the accompanying voltage increase, resulting in
an unstable system.

Remove them for now. We can revisit them with the new version of OPP
bindings, which support boost settings and frequency ranges, among
other things.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun5i-a13.dtsi | 3 +--
 arch/arm/boot/dts/sun7i-a20.dtsi | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 5d9ce84486bb..39264f7c7ae6 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -140,7 +140,6 @@
 	clock-latency = <244144>; /* 8 32k periods */
 	operating-points = <
 		/* kHz    uV */
-		1104000	1500000
 		1008000 1400000
 		912000  1350000
 		864000  1300000
@@ -150,7 +149,7 @@
 		>;
 	#cooling-cells = <2>;
 	cooling-min-level = <0>;
-	cooling-max-level = <6>;
+	cooling-max-level = <5>;
 };
 
 &ehci0 {
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 3a8530b79f1c..fdd181792b4b 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -105,7 +105,6 @@
 			clock-latency = <244144>; /* 8 32k periods */
 			operating-points = <
 				/* kHz    uV */
-				1008000 1450000
 				960000  1400000
 				912000  1400000
 				864000  1300000
@@ -116,7 +115,7 @@
 				>;
 			#cooling-cells = <2>;
 			cooling-min-level = <0>;
-			cooling-max-level = <7>;
+			cooling-max-level = <6>;
 		};
 
 		cpu at 1 {
-- 
2.1.4

[PATCH 1/2] ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting

[Siarhei Siamashka]

On Thu, 19 Mar 2015 10:39:32 +0800
Chen-Yu Tsai <wens@csie.org> wrote:

> The Olimex A10-Lime is known to be unstable when running at 1008MHz.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> index 31dc2f1c3870..16ecb8938e19 100644
> --- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> @@ -74,6 +74,20 @@
>  	status = "okay";
>  };
>  
> +&cpu0 {
> +	/* The A10-Lime is known to be unstable when running at 1008 MHz */
> +	operating-points = <
> +		/* kHz    uV */
> +		960000  1400000
> +		912000  1400000
> +		864000  1300000
> +		720000  1200000
> +		528000  1100000
> +		312000  1000000
> +		144000  900000
> +		>;
> +};
> +
>  &ehci0 {
>  	status = "okay";
>  };

Thanks for the patch. At least it should make my A10-OLinuXino-LIME
working without obvious failures out of the box (the U-Boot is still
another story though and there is a gap during boot up when the board
is running with unreliable settings, but the probability of a failure
is rather low).

I should also mention that using 960MHz @1.4V does not fail, but it does
not have any safety headroom either (the cyan 'sun4i_poorlime' line
on the plot):

    http://people.freedesktop.org/~siamashka/files/20140512/sunxi-cpufreq-plot.png

On the other hand, my board is on the worst part of the spectrum (many
other a10-lime boards do not fail even at 1008MHz), so maybe having
extra safety headroom is less necessary.

An interesting question is whether the same problem may be reproducible
on the Allwinner A10 devices other than A10-OLinuXino-LIME. My original
problem report

    https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg04343.html
    
mentioned the A10-OLinuXino-LIME rev.A and introduced some sort of
a bias by itself. At least I have seen people saying something like
"my a10-lime revision is not rev.A, so it's none of my concern and
I'm not going to bother running any tests". So far we have accumulated
reports from 4 or 5 people having this reliability problem on their
A10-OLinuXino-LIME (various revisions, not just rev.A), but not
much from the other boards owners.

Anyway, this particular patch is
Tested-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> 
Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

-- 
Best regards,
Siarhei Siamashka

[PATCH 2/2] ARM: dts: sunxi: Remove overclocked/overvoltaged OPP

[Siarhei Siamashka]

On Thu, 19 Mar 2015 10:39:33 +0800
Chen-Yu Tsai <wens@csie.org> wrote:

> Without proper regulator support for individual boards, it is dangerous
> to have overclocked/overvoltaged OPPs in the list. Cpufreq will increase
> the frequency without the accompanying voltage increase, resulting in
> an unstable system.
> 
> Remove them for now. We can revisit them with the new version of OPP
> bindings, which support boost settings and frequency ranges, among
> other things.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  arch/arm/boot/dts/sun5i-a13.dtsi | 3 +--
>  arch/arm/boot/dts/sun7i-a20.dtsi | 3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)

What about the sun4i-a10.dtsi file? Was it forgotten or skipped
deliberately?

-- 
Best regards,
Siarhei Siamashka

[PATCH 2/2] ARM: dts: sunxi: Remove overclocked/overvoltaged OPP

[Chen-Yu Tsai]

On Thu, Mar 19, 2015 at 2:59 PM, Siarhei Siamashka
<siarhei.siamashka@gmail.com> wrote:
> On Thu, 19 Mar 2015 10:39:33 +0800
> Chen-Yu Tsai <wens@csie.org> wrote:
>
>> Without proper regulator support for individual boards, it is dangerous
>> to have overclocked/overvoltaged OPPs in the list. Cpufreq will increase
>> the frequency without the accompanying voltage increase, resulting in
>> an unstable system.
>>
>> Remove them for now. We can revisit them with the new version of OPP
>> bindings, which support boost settings and frequency ranges, among
>> other things.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>>  arch/arm/boot/dts/sun5i-a13.dtsi | 3 +--
>>  arch/arm/boot/dts/sun7i-a20.dtsi | 3 +--
>>  2 files changed, 2 insertions(+), 4 deletions(-)
>
> What about the sun4i-a10.dtsi file? Was it forgotten or skipped
> deliberately?

sun4i-a10.dtsi does not have any overclocked/overvoltaged settings.
The highest setting is 1008MHz @ 1.4V.

ChenYu

[PATCH 2/2] ARM: dts: sunxi: Remove overclocked/overvoltaged OPP

[Chen-Yu Tsai]

On Thu, Mar 19, 2015 at 3:11 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Thu, Mar 19, 2015 at 2:59 PM, Siarhei Siamashka
> <siarhei.siamashka@gmail.com> wrote:
>> On Thu, 19 Mar 2015 10:39:33 +0800
>> Chen-Yu Tsai <wens@csie.org> wrote:
>>
>>> Without proper regulator support for individual boards, it is dangerous
>>> to have overclocked/overvoltaged OPPs in the list. Cpufreq will increase
>>> the frequency without the accompanying voltage increase, resulting in
>>> an unstable system.
>>>
>>> Remove them for now. We can revisit them with the new version of OPP
>>> bindings, which support boost settings and frequency ranges, among
>>> other things.
>>>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>>  arch/arm/boot/dts/sun5i-a13.dtsi | 3 +--
>>>  arch/arm/boot/dts/sun7i-a20.dtsi | 3 +--
>>>  2 files changed, 2 insertions(+), 4 deletions(-)
>>
>> What about the sun4i-a10.dtsi file? Was it forgotten or skipped
>> deliberately?
>
> sun4i-a10.dtsi does not have any overclocked/overvoltaged settings.
> The highest setting is 1008MHz @ 1.4V.

Oops. Sorry. I missed it. Will send v2.

ChenYu

[PATCH 1/2] ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting

[Chen-Yu Tsai]

On Thu, Mar 19, 2015 at 2:57 PM, Siarhei Siamashka
<siarhei.siamashka@gmail.com> wrote:
> On Thu, 19 Mar 2015 10:39:32 +0800
> Chen-Yu Tsai <wens@csie.org> wrote:
>
>> The Olimex A10-Lime is known to be unstable when running at 1008MHz.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>>  arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
>> index 31dc2f1c3870..16ecb8938e19 100644
>> --- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
>> +++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
>> @@ -74,6 +74,20 @@
>>       status = "okay";
>>  };
>>
>> +&cpu0 {
>> +     /* The A10-Lime is known to be unstable when running at 1008 MHz */
>> +     operating-points = <
>> +             /* kHz    uV */
>> +             960000  1400000
>> +             912000  1400000
>> +             864000  1300000
>> +             720000  1200000
>> +             528000  1100000
>> +             312000  1000000
>> +             144000  900000
>> +             >;
>> +};
>> +
>>  &ehci0 {
>>       status = "okay";
>>  };
>
> Thanks for the patch. At least it should make my A10-OLinuXino-LIME
> working without obvious failures out of the box (the U-Boot is still
> another story though and there is a gap during boot up when the board
> is running with unreliable settings, but the probability of a failure
> is rather low).
>
> I should also mention that using 960MHz @1.4V does not fail, but it does
> not have any safety headroom either (the cyan 'sun4i_poorlime' line
> on the plot):
>
>     http://people.freedesktop.org/~siamashka/files/20140512/sunxi-cpufreq-plot.png
>
> On the other hand, my board is on the worst part of the spectrum (many
> other a10-lime boards do not fail even at 1008MHz), so maybe having
> extra safety headroom is less necessary.
>
> An interesting question is whether the same problem may be reproducible
> on the Allwinner A10 devices other than A10-OLinuXino-LIME. My original
> problem report
>
>     https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg04343.html
>
> mentioned the A10-OLinuXino-LIME rev.A and introduced some sort of
> a bias by itself. At least I have seen people saying something like
> "my a10-lime revision is not rev.A, so it's none of my concern and
> I'm not going to bother running any tests". So far we have accumulated
> reports from 4 or 5 people having this reliability problem on their
> A10-OLinuXino-LIME (various revisions, not just rev.A), but not
> much from the other boards owners.
>
> Anyway, this particular patch is
> Tested-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
> Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Good to hear it works. Did you test all the settings? I copied the
wrong settings, from sun5i-a13.dtsi instead of sun4i-a10.dtsi.

I'll send a fixed version later.


ChenYu

[PATCH 1/2] ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting

[Siarhei Siamashka]

On Thu, 19 Mar 2015 16:17:30 +0800
Chen-Yu Tsai <wens@csie.org> wrote:

> On Thu, Mar 19, 2015 at 2:57 PM, Siarhei Siamashka
> <siarhei.siamashka@gmail.com> wrote:
> > On Thu, 19 Mar 2015 10:39:32 +0800
> > Chen-Yu Tsai <wens@csie.org> wrote:
> >
> >> The Olimex A10-Lime is known to be unstable when running at 1008MHz.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> ---
> >>  arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 14 ++++++++++++++
> >>  1 file changed, 14 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> >> index 31dc2f1c3870..16ecb8938e19 100644
> >> --- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> >> +++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> >> @@ -74,6 +74,20 @@
> >>       status = "okay";
> >>  };
> >>
> >> +&cpu0 {
> >> +     /* The A10-Lime is known to be unstable when running at 1008 MHz */
> >> +     operating-points = <
> >> +             /* kHz    uV */
> >> +             960000  1400000
> >> +             912000  1400000
> >> +             864000  1300000
> >> +             720000  1200000
> >> +             528000  1100000
> >> +             312000  1000000
> >> +             144000  900000
> >> +             >;
> >> +};
> >> +
> >>  &ehci0 {
> >>       status = "okay";
> >>  };
> >
> > Thanks for the patch. At least it should make my A10-OLinuXino-LIME
> > working without obvious failures out of the box (the U-Boot is still
> > another story though and there is a gap during boot up when the board
> > is running with unreliable settings, but the probability of a failure
> > is rather low).
> >
> > I should also mention that using 960MHz @1.4V does not fail, but it does
> > not have any safety headroom either (the cyan 'sun4i_poorlime' line
> > on the plot):
> >
> >     http://people.freedesktop.org/~siamashka/files/20140512/sunxi-cpufreq-plot.png
> >
> > On the other hand, my board is on the worst part of the spectrum (many
> > other a10-lime boards do not fail even at 1008MHz), so maybe having
> > extra safety headroom is less necessary.
> >
> > An interesting question is whether the same problem may be reproducible
> > on the Allwinner A10 devices other than A10-OLinuXino-LIME. My original
> > problem report
> >
> >     https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg04343.html
> >
> > mentioned the A10-OLinuXino-LIME rev.A and introduced some sort of
> > a bias by itself. At least I have seen people saying something like
> > "my a10-lime revision is not rev.A, so it's none of my concern and
> > I'm not going to bother running any tests". So far we have accumulated
> > reports from 4 or 5 people having this reliability problem on their
> > A10-OLinuXino-LIME (various revisions, not just rev.A), but not
> > much from the other boards owners.
> >
> > Anyway, this particular patch is
> > Tested-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
> > Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
> 
> Good to hear it works. Did you test all the settings?

You have nailed it. I was about to send the results of the full
round of tests after running them a bit longer and revoke the
initial Tested-by.

Turns out that the 312MHz and 144MHz operating points fail to work
reliable and tend to deadlock:

Testing CPU 0
  960 MHz ............................................................ OK
  912 MHz ............................................................ OK
  864 MHz ............................................................ OK
  720 MHz ............................................................ OK
  528 MHz ............................................................ OK
  312 MHz ............................................................ OK
  144 MHz Write failed: Broken pipe

Testing CPU 0
  960 MHz ............................................................ OK
  912 MHz ............................................................ OK
  864 MHz ............................................................ OK
  720 MHz ............................................................ OK
  528 MHz ............................................................ OK
  312 MHz .................Write failed: Broken pipe


> I copied the wrong settings, from sun5i-a13.dtsi instead of sun4i-a10.dtsi.

I guess, this explains the problems at lower operating points.

> I'll send a fixed version later.

Thanks.

-- 
Best regards,
Siarhei Siamashka

[linux-sunxi] Re: [PATCH 1/2] ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting

[Iain Paton]

On 19/03/15 06:57, Siarhei Siamashka wrote:

> I should also mention that using 960MHz @1.4V does not fail, but it does
> not have any safety headroom either (the cyan 'sun4i_poorlime' line
> on the plot):
> 
>     http://people.freedesktop.org/~siamashka/files/20140512/sunxi-cpufreq-plot.png
> 
> On the other hand, my board is on the worst part of the spectrum (many
> other a10-lime boards do not fail even at 1008MHz), so maybe having
> extra safety headroom is less necessary.
> 
> An interesting question is whether the same problem may be reproducible
> on the Allwinner A10 devices other than A10-OLinuXino-LIME. My original
> problem report
> 
>     https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg04343.html
>     
> mentioned the A10-OLinuXino-LIME rev.A and introduced some sort of
> a bias by itself. At least I have seen people saying something like
> "my a10-lime revision is not rev.A, so it's none of my concern and
> I'm not going to bother running any tests". So far we have accumulated
> reports from 4 or 5 people having this reliability problem on their
> A10-OLinuXino-LIME (various revisions, not just rev.A), but not
> much from the other boards owners.

I'm somewhat sad to see 1008MHz go. I have 2x revA A10-Lime boards that 
are stable at 1008MHz with Maximes sunxi/for-next, a full regulator 
description in the dts and a very recent u-boot. They are not stable at 
1056 or above however.


Can I ask what the basis is for the 960MHz setting?  I don't see any 
instances of it in any of the a10 fex files, meaning it's likely not 
very well tested.

If there's interest, I'll send the patch adding regulators to the dts for 
the a10-lime.

Rgds,
Iain

[linux-sunxi] Re: [PATCH 1/2] ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting

[Chen-Yu Tsai]

Hi,

On Thu, Mar 26, 2015 at 9:58 AM, Iain Paton <ipaton0@gmail.com> wrote:
> On 19/03/15 06:57, Siarhei Siamashka wrote:
>
>> I should also mention that using 960MHz @1.4V does not fail, but it does
>> not have any safety headroom either (the cyan 'sun4i_poorlime' line
>> on the plot):
>>
>>     http://people.freedesktop.org/~siamashka/files/20140512/sunxi-cpufreq-plot.png
>>
>> On the other hand, my board is on the worst part of the spectrum (many
>> other a10-lime boards do not fail even at 1008MHz), so maybe having
>> extra safety headroom is less necessary.
>>
>> An interesting question is whether the same problem may be reproducible
>> on the Allwinner A10 devices other than A10-OLinuXino-LIME. My original
>> problem report
>>
>>     https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg04343.html
>>
>> mentioned the A10-OLinuXino-LIME rev.A and introduced some sort of
>> a bias by itself. At least I have seen people saying something like
>> "my a10-lime revision is not rev.A, so it's none of my concern and
>> I'm not going to bother running any tests". So far we have accumulated
>> reports from 4 or 5 people having this reliability problem on their
>> A10-OLinuXino-LIME (various revisions, not just rev.A), but not
>> much from the other boards owners.
>
> I'm somewhat sad to see 1008MHz go. I have 2x revA A10-Lime boards that
> are stable at 1008MHz with Maximes sunxi/for-next, a full regulator
> description in the dts and a very recent u-boot. They are not stable at
> 1056 or above however.
>
>
> Can I ask what the basis is for the 960MHz setting?  I don't see any
> instances of it in any of the a10 fex files, meaning it's likely not
> very well tested.

It was copied from the wrong file. Please see v2 of the series.

> If there's interest, I'll send the patch adding regulators to the dts for
> the a10-lime.

Please do.

ChenYu