Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

Hello Michal,

On 30.6.2016 13:13, Michal Suchanek wrote:
> Hello,
> 
> On 25 June 2016 at 05:45,   wrote:
>> From: Ondrej Jirman 
>>
>> Use Xulong Orange Pi One GPIO based regulator for
>> passive cooling and thermal management.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>> +
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index b1bd6b0..a38d871 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -109,6 +109,45 @@
>> };
>>  };
>>
>> + {
>> +   operating-points = <
>> +   /* kHzuV */
>> +   1296000 130
>> +   120 130
> 
> First problem is that the board boots at 1008000 which is not listed
> and the kernel complains.
> 
> Second problem is that the board locks up during boot with this enabled.
> 
> Do you have some suggestion for alternate configuration to test?

I've identified the problem as incorrectly set up gpio-regulator. During
boot, when it was probed, it would be initiualized with 1.1V for a
moment. This caused random non-specific lockups/crashes afterwards.

Fixed patches are in my branch on github, if you want to try again.

  https://github.com/megous/linux/commits/orange-pi-4.7

regards,
  o.

> Thanks
> 
> Michal
> 



signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

Hello Michal,

On 30.6.2016 13:13, Michal Suchanek wrote:
> Hello,
> 
> On 25 June 2016 at 05:45,   wrote:
>> From: Ondrej Jirman 
>>
>> Use Xulong Orange Pi One GPIO based regulator for
>> passive cooling and thermal management.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>> +
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index b1bd6b0..a38d871 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -109,6 +109,45 @@
>> };
>>  };
>>
>> + {
>> +   operating-points = <
>> +   /* kHzuV */
>> +   1296000 130
>> +   120 130
> 
> First problem is that the board boots at 1008000 which is not listed
> and the kernel complains.
> 
> Second problem is that the board locks up during boot with this enabled.
> 
> Do you have some suggestion for alternate configuration to test?

I've identified the problem as incorrectly set up gpio-regulator. During
boot, when it was probed, it would be initiualized with 1.1V for a
moment. This caused random non-specific lockups/crashes afterwards.

Fixed patches are in my branch on github, if you want to try again.

  https://github.com/megous/linux/commits/orange-pi-4.7

regards,
  o.

> Thanks
> 
> Michal
> 



signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

On 30 June 2016 at 17:50, Michal Suchanek  wrote:
> On 30 June 2016 at 17:16, Michal Suchanek  wrote:
>> On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
>>> Hello,
>>)k, so I tried>
>>> On 30.6.2016 13:13, Michal Suchanek wrote:
 Hello,

 On 25 June 2016 at 05:45,   wrote:
> From: Ondrej Jirman 
>
> Use Xulong Orange Pi One GPIO based regulator for
> passive cooling and thermal management.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
> +
>  1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index b1bd6b0..a38d871 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -109,6 +109,45 @@
> };
>  };
>
> + {
> +   operating-points = <
> +   /* kHzuV */
> +   1296000 130
> +   120 130

 First problem is that the board boots at 1008000 which is not listed
 and the kernel complains.

 Second problem is that the board locks up during boot with this enabled.

 Do you have some suggestion for alternate configuration to test?
>>>
>>> Just to verify, did you test with the entire series applied? (especially
>>> the PLL1 clk application changes)
>>
>> Yes, I applied the whole series.
>>
>>>
>>> You may try dropping the highest operating point, it's probably overly
>>> optimistic for Orange Pi One.
>>>
>>> Is the power supply/cable you're using hard enough?
>>
>> I use a 7 port hub to power the board. It worked with some other small
>> devboards.
>>
>> The cable is some random Chinese USB to power jack adaptor with an
>> extra adaptor to fit the Pi socket. It looks ok but I did not test
>> this particular combination thoroughly.
>>
>>>
>>> Where during the boot process does it lock up?
>>
>> Usually sometime around enabling cpufreq  before getty starts.
>> Different runs and settings give slightly different results. In
>> particular adding the 1008000 point seems to make it go further.
>>
>> Removing all traces of the regulator, cpufreq and thermal I can boot
>> pretty much 100% to login prompt.
>>
>> I don't think the difference between 1GHz and 1.3GHz frequency on the
>> core would put much additional stress on the supply but I can try with
>> 35W PSU and some alternative cabling to be sure.
>>
>> I did some more tests and it seems 1008000@1.1V is fine but switching
>> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
>> there is need for some delay somewhere for the regulator to get
>> stable?
>>
>
> Hm, the AW table shows 1008000@1.3V as supported state and it indeed
> works. So the voltage switching works or does nothing. Can I measure
> the regulator output somewhere? Clocking the chip higher does not
> work.
>
> I will try with another PSU later.
>

Ok, so I tried. The result is the same.

A Chinese USB power meter shows voltage 5.1V which drops to like 4.95V
when the board is running. The power draw is around 170mA and
about 200mA when switch to 1.3V is attempted.
The voltage drop is not nice and is probably due to excessive cabling used
to distribute power to multiple boards.
The USB hub starts at 5.2V and drops to something like 5.1V.

When the top frequency is 1008000@1.3V and governor is performance
the board keeps running 1008000@1.1V as set up by u-boot.

Changing the top point to 1008000@1.1V the board locks up as soon as
governor is changed to conservative. So any attempt at frequency scaling
crashes even without touching the regulator.

Thanks

Michal

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

On 30 June 2016 at 17:50, Michal Suchanek  wrote:
> On 30 June 2016 at 17:16, Michal Suchanek  wrote:
>> On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
>>> Hello,
>>)k, so I tried>
>>> On 30.6.2016 13:13, Michal Suchanek wrote:
 Hello,

 On 25 June 2016 at 05:45,   wrote:
> From: Ondrej Jirman 
>
> Use Xulong Orange Pi One GPIO based regulator for
> passive cooling and thermal management.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
> +
>  1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index b1bd6b0..a38d871 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -109,6 +109,45 @@
> };
>  };
>
> + {
> +   operating-points = <
> +   /* kHzuV */
> +   1296000 130
> +   120 130

 First problem is that the board boots at 1008000 which is not listed
 and the kernel complains.

 Second problem is that the board locks up during boot with this enabled.

 Do you have some suggestion for alternate configuration to test?
>>>
>>> Just to verify, did you test with the entire series applied? (especially
>>> the PLL1 clk application changes)
>>
>> Yes, I applied the whole series.
>>
>>>
>>> You may try dropping the highest operating point, it's probably overly
>>> optimistic for Orange Pi One.
>>>
>>> Is the power supply/cable you're using hard enough?
>>
>> I use a 7 port hub to power the board. It worked with some other small
>> devboards.
>>
>> The cable is some random Chinese USB to power jack adaptor with an
>> extra adaptor to fit the Pi socket. It looks ok but I did not test
>> this particular combination thoroughly.
>>
>>>
>>> Where during the boot process does it lock up?
>>
>> Usually sometime around enabling cpufreq  before getty starts.
>> Different runs and settings give slightly different results. In
>> particular adding the 1008000 point seems to make it go further.
>>
>> Removing all traces of the regulator, cpufreq and thermal I can boot
>> pretty much 100% to login prompt.
>>
>> I don't think the difference between 1GHz and 1.3GHz frequency on the
>> core would put much additional stress on the supply but I can try with
>> 35W PSU and some alternative cabling to be sure.
>>
>> I did some more tests and it seems 1008000@1.1V is fine but switching
>> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
>> there is need for some delay somewhere for the regulator to get
>> stable?
>>
>
> Hm, the AW table shows 1008000@1.3V as supported state and it indeed
> works. So the voltage switching works or does nothing. Can I measure
> the regulator output somewhere? Clocking the chip higher does not
> work.
>
> I will try with another PSU later.
>

Ok, so I tried. The result is the same.

A Chinese USB power meter shows voltage 5.1V which drops to like 4.95V
when the board is running. The power draw is around 170mA and
about 200mA when switch to 1.3V is attempted.
The voltage drop is not nice and is probably due to excessive cabling used
to distribute power to multiple boards.
The USB hub starts at 5.2V and drops to something like 5.1V.

When the top frequency is 1008000@1.3V and governor is performance
the board keeps running 1008000@1.1V as set up by u-boot.

Changing the top point to 1008000@1.1V the board locks up as soon as
governor is changed to conservative. So any attempt at frequency scaling
crashes even without touching the regulator.

Thanks

Michal

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

On 30.6.2016 16:23, Siarhei Siamashka wrote:
> On Thu, 30 Jun 2016 13:13:48 +0200
> Michal Suchanek  wrote:
> 
>> Hello,
>>
>> On 25 June 2016 at 05:45,   wrote:
>>> From: Ondrej Jirman 
>>>
>>> Use Xulong Orange Pi One GPIO based regulator for
>>> passive cooling and thermal management.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>>> +
>>>  1 file changed, 39 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> index b1bd6b0..a38d871 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> @@ -109,6 +109,45 @@
>>> };
>>>  };
>>>
>>> + {
>>> +   operating-points = <
>>> +   /* kHzuV */
>>> +   1296000 130
>>> +   120 130  
>>
>> First problem is that the board boots at 1008000 which is not listed
>> and the kernel complains.
>>
>> Second problem is that the board locks up during boot with this enabled.
>>
>> Do you have some suggestion for alternate configuration to test?
> 
> Maybe try the Allwinner's original DVFS table instead of these
> undervolted values and see if it helps?
> 
> https://linux-sunxi.org/index.php?title=Xunlong_Orange_Pi_PC=17753#CPU_clock_speed_limit

Thanks, I'll use these. I'm not sure what will happen if regulator is
not capable of providing the exact voltages specified in the operating
points, though. Will it do the sane thing? :)

Also LV6+ in the table is bellow specified minimum voltage in the
datasheet. But then Orange Pi works at much lower voltages for me.

Conversly LV1 is the absolute maximum. Recommended maximum is 1.4V So I
would not use that.

It might be nice to have something like that dram clock test, but for
cpux freq/voltage, and collect some statistics.

regards,
  Ondrej

> While undervolting is tempting because it helps to decrease the SoC
> temperature and avoid throttling, different units may have different
> tolerances and one needs to be very careful when picking defaults
> that are intended to work correctly on all boards. Some safety
> headroom exists there for a reason.
> 
> If I remember correctly, some people pushed for undervolting experiments
> at least twice in the past (on the Banana Pi and C.H.I.P.). In both
> cases this did not end up well and had to be fixed later to solve
> reliability problems.
> 
> In order to allow individual per-unit tuning, a concept of "speed
> grading" may be probably introduced later. So that the board is tested
> for reliability and then the speed grade rating is stored somewhere on
> the non-removable storage (EEPROM, SPI flash, eFUSE, ...). Some SoC
> manufacturers, such as Samsung, are already doing this with their chips.
> 



signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

On 30.6.2016 16:23, Siarhei Siamashka wrote:
> On Thu, 30 Jun 2016 13:13:48 +0200
> Michal Suchanek  wrote:
> 
>> Hello,
>>
>> On 25 June 2016 at 05:45,   wrote:
>>> From: Ondrej Jirman 
>>>
>>> Use Xulong Orange Pi One GPIO based regulator for
>>> passive cooling and thermal management.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>>> +
>>>  1 file changed, 39 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> index b1bd6b0..a38d871 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> @@ -109,6 +109,45 @@
>>> };
>>>  };
>>>
>>> + {
>>> +   operating-points = <
>>> +   /* kHzuV */
>>> +   1296000 130
>>> +   120 130  
>>
>> First problem is that the board boots at 1008000 which is not listed
>> and the kernel complains.
>>
>> Second problem is that the board locks up during boot with this enabled.
>>
>> Do you have some suggestion for alternate configuration to test?
> 
> Maybe try the Allwinner's original DVFS table instead of these
> undervolted values and see if it helps?
> 
> https://linux-sunxi.org/index.php?title=Xunlong_Orange_Pi_PC=17753#CPU_clock_speed_limit

Thanks, I'll use these. I'm not sure what will happen if regulator is
not capable of providing the exact voltages specified in the operating
points, though. Will it do the sane thing? :)

Also LV6+ in the table is bellow specified minimum voltage in the
datasheet. But then Orange Pi works at much lower voltages for me.

Conversly LV1 is the absolute maximum. Recommended maximum is 1.4V So I
would not use that.

It might be nice to have something like that dram clock test, but for
cpux freq/voltage, and collect some statistics.

regards,
  Ondrej

> While undervolting is tempting because it helps to decrease the SoC
> temperature and avoid throttling, different units may have different
> tolerances and one needs to be very careful when picking defaults
> that are intended to work correctly on all boards. Some safety
> headroom exists there for a reason.
> 
> If I remember correctly, some people pushed for undervolting experiments
> at least twice in the past (on the Banana Pi and C.H.I.P.). In both
> cases this did not end up well and had to be fixed later to solve
> reliability problems.
> 
> In order to allow individual per-unit tuning, a concept of "speed
> grading" may be probably introduced later. So that the board is tested
> for reliability and then the speed grade rating is stored somewhere on
> the non-removable storage (EEPROM, SPI flash, eFUSE, ...). Some SoC
> manufacturers, such as Samsung, are already doing this with their chips.
> 



signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
> Hello,
>
> On 30.6.2016 13:13, Michal Suchanek wrote:
>> Hello,
>>
>> On 25 June 2016 at 05:45,   wrote:
>>> From: Ondrej Jirman 
>>>
>>> Use Xulong Orange Pi One GPIO based regulator for
>>> passive cooling and thermal management.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>>> +
>>>  1 file changed, 39 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> index b1bd6b0..a38d871 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> @@ -109,6 +109,45 @@
>>> };
>>>  };
>>>
>>> + {
>>> +   operating-points = <
>>> +   /* kHzuV */
>>> +   1296000 130
>>> +   120 130
>>
>> First problem is that the board boots at 1008000 which is not listed
>> and the kernel complains.
>>
>> Second problem is that the board locks up during boot with this enabled.
>>
>> Do you have some suggestion for alternate configuration to test?
>
> Just to verify, did you test with the entire series applied? (especially
> the PLL1 clk application changes)

Yes, I applied the whole series.

>
> You may try dropping the highest operating point, it's probably overly
> optimistic for Orange Pi One.
>
> Is the power supply/cable you're using hard enough?

I use a 7 port hub to power the board. It worked with some other small
devboards.

The cable is some random Chinese USB to power jack adaptor with an
extra adaptor to fit the Pi socket. It looks ok but I did not test
this particular combination thoroughly.

>
> Where during the boot process does it lock up?

Usually sometime around enabling cpufreq  before getty starts.
Different runs and settings give slightly different results. In
particular adding the 1008000 point seems to make it go further.

Removing all traces of the regulator, cpufreq and thermal I can boot
pretty much 100% to login prompt.

I don't think the difference between 1GHz and 1.3GHz frequency on the
core would put much additional stress on the supply but I can try with
35W PSU and some alternative cabling to be sure.

I did some more tests and it seems 1008000@1.1V is fine but switching
to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
there is need for some delay somewhere for the regulator to get
stable?

Thanks

Michal

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
> Hello,
>
> On 30.6.2016 13:13, Michal Suchanek wrote:
>> Hello,
>>
>> On 25 June 2016 at 05:45,   wrote:
>>> From: Ondrej Jirman 
>>>
>>> Use Xulong Orange Pi One GPIO based regulator for
>>> passive cooling and thermal management.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>>> +
>>>  1 file changed, 39 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> index b1bd6b0..a38d871 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> @@ -109,6 +109,45 @@
>>> };
>>>  };
>>>
>>> + {
>>> +   operating-points = <
>>> +   /* kHzuV */
>>> +   1296000 130
>>> +   120 130
>>
>> First problem is that the board boots at 1008000 which is not listed
>> and the kernel complains.
>>
>> Second problem is that the board locks up during boot with this enabled.
>>
>> Do you have some suggestion for alternate configuration to test?
>
> Just to verify, did you test with the entire series applied? (especially
> the PLL1 clk application changes)

Yes, I applied the whole series.

>
> You may try dropping the highest operating point, it's probably overly
> optimistic for Orange Pi One.
>
> Is the power supply/cable you're using hard enough?

I use a 7 port hub to power the board. It worked with some other small
devboards.

The cable is some random Chinese USB to power jack adaptor with an
extra adaptor to fit the Pi socket. It looks ok but I did not test
this particular combination thoroughly.

>
> Where during the boot process does it lock up?

Usually sometime around enabling cpufreq  before getty starts.
Different runs and settings give slightly different results. In
particular adding the 1008000 point seems to make it go further.

Removing all traces of the regulator, cpufreq and thermal I can boot
pretty much 100% to login prompt.

I don't think the difference between 1GHz and 1.3GHz frequency on the
core would put much additional stress on the supply but I can try with
35W PSU and some alternative cabling to be sure.

I did some more tests and it seems 1008000@1.1V is fine but switching
to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
there is need for some delay somewhere for the regulator to get
stable?

Thanks

Michal

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

On 30.6.2016 17:50, Michal Suchanek wrote:
> On 30 June 2016 at 17:16, Michal Suchanek  wrote:
>> On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
>>> Hello,
>>>
>>> On 30.6.2016 13:13, Michal Suchanek wrote:
 Hello,

 On 25 June 2016 at 05:45,   wrote:
> From: Ondrej Jirman 
>
> Use Xulong Orange Pi One GPIO based regulator for
> passive cooling and thermal management.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
> +
>  1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index b1bd6b0..a38d871 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -109,6 +109,45 @@
> };
>  };
>
> + {
> +   operating-points = <
> +   /* kHzuV */
> +   1296000 130
> +   120 130

 First problem is that the board boots at 1008000 which is not listed
 and the kernel complains.

 Second problem is that the board locks up during boot with this enabled.

 Do you have some suggestion for alternate configuration to test?
>>>
>>> Just to verify, did you test with the entire series applied? (especially
>>> the PLL1 clk application changes)
>>
>> Yes, I applied the whole series.
>>
>>>
>>> You may try dropping the highest operating point, it's probably overly
>>> optimistic for Orange Pi One.
>>>
>>> Is the power supply/cable you're using hard enough?
>>
>> I use a 7 port hub to power the board. It worked with some other small
>> devboards.
>>
>> The cable is some random Chinese USB to power jack adaptor with an
>> extra adaptor to fit the Pi socket. It looks ok but I did not test
>> this particular combination thoroughly.
>>
>>>
>>> Where during the boot process does it lock up?
>>
>> Usually sometime around enabling cpufreq  before getty starts.
>> Different runs and settings give slightly different results. In
>> particular adding the 1008000 point seems to make it go further.
>>
>> Removing all traces of the regulator, cpufreq and thermal I can boot
>> pretty much 100% to login prompt.
>>
>> I don't think the difference between 1GHz and 1.3GHz frequency on the
>> core would put much additional stress on the supply but I can try with
>> 35W PSU and some alternative cabling to be sure.
>>
>> I did some more tests and it seems 1008000@1.1V is fine but switching
>> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
>> there is need for some delay somewhere for the regulator to get
>> stable?
>>
> 
> Hm, the AW table shows 1008000@1.3V as supported state and it indeed
> works. So the voltage switching works or does nothing. Can I measure
> the regulator output somewhere? Clocking the chip higher does not
> work.

Regulator output is TP1 on the bottom of the board, next ot the CSI
connector.

regards,
  Ondrej

> I will try with another PSU later.
> 
> Thanks
> 
> Michal
> 



signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

On 30.6.2016 17:50, Michal Suchanek wrote:
> On 30 June 2016 at 17:16, Michal Suchanek  wrote:
>> On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
>>> Hello,
>>>
>>> On 30.6.2016 13:13, Michal Suchanek wrote:
 Hello,

 On 25 June 2016 at 05:45,   wrote:
> From: Ondrej Jirman 
>
> Use Xulong Orange Pi One GPIO based regulator for
> passive cooling and thermal management.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
> +
>  1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index b1bd6b0..a38d871 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -109,6 +109,45 @@
> };
>  };
>
> + {
> +   operating-points = <
> +   /* kHzuV */
> +   1296000 130
> +   120 130

 First problem is that the board boots at 1008000 which is not listed
 and the kernel complains.

 Second problem is that the board locks up during boot with this enabled.

 Do you have some suggestion for alternate configuration to test?
>>>
>>> Just to verify, did you test with the entire series applied? (especially
>>> the PLL1 clk application changes)
>>
>> Yes, I applied the whole series.
>>
>>>
>>> You may try dropping the highest operating point, it's probably overly
>>> optimistic for Orange Pi One.
>>>
>>> Is the power supply/cable you're using hard enough?
>>
>> I use a 7 port hub to power the board. It worked with some other small
>> devboards.
>>
>> The cable is some random Chinese USB to power jack adaptor with an
>> extra adaptor to fit the Pi socket. It looks ok but I did not test
>> this particular combination thoroughly.
>>
>>>
>>> Where during the boot process does it lock up?
>>
>> Usually sometime around enabling cpufreq  before getty starts.
>> Different runs and settings give slightly different results. In
>> particular adding the 1008000 point seems to make it go further.
>>
>> Removing all traces of the regulator, cpufreq and thermal I can boot
>> pretty much 100% to login prompt.
>>
>> I don't think the difference between 1GHz and 1.3GHz frequency on the
>> core would put much additional stress on the supply but I can try with
>> 35W PSU and some alternative cabling to be sure.
>>
>> I did some more tests and it seems 1008000@1.1V is fine but switching
>> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
>> there is need for some delay somewhere for the regulator to get
>> stable?
>>
> 
> Hm, the AW table shows 1008000@1.3V as supported state and it indeed
> works. So the voltage switching works or does nothing. Can I measure
> the regulator output somewhere? Clocking the chip higher does not
> work.

Regulator output is TP1 on the bottom of the board, next ot the CSI
connector.

regards,
  Ondrej

> I will try with another PSU later.
> 
> Thanks
> 
> Michal
> 



signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

On 30 June 2016 at 17:16, Michal Suchanek  wrote:
> On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
>> Hello,
>>
>> On 30.6.2016 13:13, Michal Suchanek wrote:
>>> Hello,
>>>
>>> On 25 June 2016 at 05:45,   wrote:
 From: Ondrej Jirman 

 Use Xulong Orange Pi One GPIO based regulator for
 passive cooling and thermal management.

 Signed-off-by: Ondrej Jirman 
 ---
  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
 +
  1 file changed, 39 insertions(+)

 diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
 b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 index b1bd6b0..a38d871 100644
 --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 @@ -109,6 +109,45 @@
 };
  };

 + {
 +   operating-points = <
 +   /* kHzuV */
 +   1296000 130
 +   120 130
>>>
>>> First problem is that the board boots at 1008000 which is not listed
>>> and the kernel complains.
>>>
>>> Second problem is that the board locks up during boot with this enabled.
>>>
>>> Do you have some suggestion for alternate configuration to test?
>>
>> Just to verify, did you test with the entire series applied? (especially
>> the PLL1 clk application changes)
>
> Yes, I applied the whole series.
>
>>
>> You may try dropping the highest operating point, it's probably overly
>> optimistic for Orange Pi One.
>>
>> Is the power supply/cable you're using hard enough?
>
> I use a 7 port hub to power the board. It worked with some other small
> devboards.
>
> The cable is some random Chinese USB to power jack adaptor with an
> extra adaptor to fit the Pi socket. It looks ok but I did not test
> this particular combination thoroughly.
>
>>
>> Where during the boot process does it lock up?
>
> Usually sometime around enabling cpufreq  before getty starts.
> Different runs and settings give slightly different results. In
> particular adding the 1008000 point seems to make it go further.
>
> Removing all traces of the regulator, cpufreq and thermal I can boot
> pretty much 100% to login prompt.
>
> I don't think the difference between 1GHz and 1.3GHz frequency on the
> core would put much additional stress on the supply but I can try with
> 35W PSU and some alternative cabling to be sure.
>
> I did some more tests and it seems 1008000@1.1V is fine but switching
> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
> there is need for some delay somewhere for the regulator to get
> stable?
>

Hm, the AW table shows 1008000@1.3V as supported state and it indeed
works. So the voltage switching works or does nothing. Can I measure
the regulator output somewhere? Clocking the chip higher does not
work.

I will try with another PSU later.

Thanks

Michal

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

On 30 June 2016 at 17:16, Michal Suchanek  wrote:
> On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
>> Hello,
>>
>> On 30.6.2016 13:13, Michal Suchanek wrote:
>>> Hello,
>>>
>>> On 25 June 2016 at 05:45,   wrote:
 From: Ondrej Jirman 

 Use Xulong Orange Pi One GPIO based regulator for
 passive cooling and thermal management.

 Signed-off-by: Ondrej Jirman 
 ---
  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
 +
  1 file changed, 39 insertions(+)

 diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
 b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 index b1bd6b0..a38d871 100644
 --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 @@ -109,6 +109,45 @@
 };
  };

 + {
 +   operating-points = <
 +   /* kHzuV */
 +   1296000 130
 +   120 130
>>>
>>> First problem is that the board boots at 1008000 which is not listed
>>> and the kernel complains.
>>>
>>> Second problem is that the board locks up during boot with this enabled.
>>>
>>> Do you have some suggestion for alternate configuration to test?
>>
>> Just to verify, did you test with the entire series applied? (especially
>> the PLL1 clk application changes)
>
> Yes, I applied the whole series.
>
>>
>> You may try dropping the highest operating point, it's probably overly
>> optimistic for Orange Pi One.
>>
>> Is the power supply/cable you're using hard enough?
>
> I use a 7 port hub to power the board. It worked with some other small
> devboards.
>
> The cable is some random Chinese USB to power jack adaptor with an
> extra adaptor to fit the Pi socket. It looks ok but I did not test
> this particular combination thoroughly.
>
>>
>> Where during the boot process does it lock up?
>
> Usually sometime around enabling cpufreq  before getty starts.
> Different runs and settings give slightly different results. In
> particular adding the 1008000 point seems to make it go further.
>
> Removing all traces of the regulator, cpufreq and thermal I can boot
> pretty much 100% to login prompt.
>
> I don't think the difference between 1GHz and 1.3GHz frequency on the
> core would put much additional stress on the supply but I can try with
> 35W PSU and some alternative cabling to be sure.
>
> I did some more tests and it seems 1008000@1.1V is fine but switching
> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
> there is need for some delay somewhere for the regulator to get
> stable?
>

Hm, the AW table shows 1008000@1.3V as supported state and it indeed
works. So the voltage switching works or does nothing. Can I measure
the regulator output somewhere? Clocking the chip higher does not
work.

I will try with another PSU later.

Thanks

Michal

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

On 30.6.2016 17:16, Michal Suchanek wrote:
> On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
>> Hello,
>>
>> On 30.6.2016 13:13, Michal Suchanek wrote:
>>> Hello,
>>>
>>> On 25 June 2016 at 05:45,   wrote:
 From: Ondrej Jirman 

 Use Xulong Orange Pi One GPIO based regulator for
 passive cooling and thermal management.

 Signed-off-by: Ondrej Jirman 
 ---
  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
 +
  1 file changed, 39 insertions(+)

 diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
 b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 index b1bd6b0..a38d871 100644
 --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 @@ -109,6 +109,45 @@
 };
  };

 + {
 +   operating-points = <
 +   /* kHzuV */
 +   1296000 130
 +   120 130
>>>
>>> First problem is that the board boots at 1008000 which is not listed
>>> and the kernel complains.
>>>
>>> Second problem is that the board locks up during boot with this enabled.
>>>
>>> Do you have some suggestion for alternate configuration to test?
>>
>> Just to verify, did you test with the entire series applied? (especially
>> the PLL1 clk application changes)
> 
> Yes, I applied the whole series.
> 
>>
>> You may try dropping the highest operating point, it's probably overly
>> optimistic for Orange Pi One.
>>
>> Is the power supply/cable you're using hard enough?
> 
> I use a 7 port hub to power the board. It worked with some other small
> devboards.
> 
> The cable is some random Chinese USB to power jack adaptor with an
> extra adaptor to fit the Pi socket. It looks ok but I did not test
> this particular combination thoroughly.
> 
>>
>> Where during the boot process does it lock up?
> 
> Usually sometime around enabling cpufreq  before getty starts.
> Different runs and settings give slightly different results. In
> particular adding the 1008000 point seems to make it go further.
> 
> Removing all traces of the regulator, cpufreq and thermal I can boot
> pretty much 100% to login prompt.
> 
> I don't think the difference between 1GHz and 1.3GHz frequency on the
> core would put much additional stress on the supply but I can try with
> 35W PSU and some alternative cabling to be sure.
> 
> I did some more tests and it seems 1008000@1.1V is fine but switching
> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
> there is need for some delay somewhere for the regulator to get
> stable?

Please try adding:

  regulator-ramp-delay = <10>

to the gpio regulator.

which will allow 100ms per 1V change, which should b enough for
determining, if this is the cause.

regards,
  Ondrej

> Thanks
> 
> Michal
> 



signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

On 30.6.2016 17:16, Michal Suchanek wrote:
> On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
>> Hello,
>>
>> On 30.6.2016 13:13, Michal Suchanek wrote:
>>> Hello,
>>>
>>> On 25 June 2016 at 05:45,   wrote:
 From: Ondrej Jirman 

 Use Xulong Orange Pi One GPIO based regulator for
 passive cooling and thermal management.

 Signed-off-by: Ondrej Jirman 
 ---
  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
 +
  1 file changed, 39 insertions(+)

 diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
 b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 index b1bd6b0..a38d871 100644
 --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
 @@ -109,6 +109,45 @@
 };
  };

 + {
 +   operating-points = <
 +   /* kHzuV */
 +   1296000 130
 +   120 130
>>>
>>> First problem is that the board boots at 1008000 which is not listed
>>> and the kernel complains.
>>>
>>> Second problem is that the board locks up during boot with this enabled.
>>>
>>> Do you have some suggestion for alternate configuration to test?
>>
>> Just to verify, did you test with the entire series applied? (especially
>> the PLL1 clk application changes)
> 
> Yes, I applied the whole series.
> 
>>
>> You may try dropping the highest operating point, it's probably overly
>> optimistic for Orange Pi One.
>>
>> Is the power supply/cable you're using hard enough?
> 
> I use a 7 port hub to power the board. It worked with some other small
> devboards.
> 
> The cable is some random Chinese USB to power jack adaptor with an
> extra adaptor to fit the Pi socket. It looks ok but I did not test
> this particular combination thoroughly.
> 
>>
>> Where during the boot process does it lock up?
> 
> Usually sometime around enabling cpufreq  before getty starts.
> Different runs and settings give slightly different results. In
> particular adding the 1008000 point seems to make it go further.
> 
> Removing all traces of the regulator, cpufreq and thermal I can boot
> pretty much 100% to login prompt.
> 
> I don't think the difference between 1GHz and 1.3GHz frequency on the
> core would put much additional stress on the supply but I can try with
> 35W PSU and some alternative cabling to be sure.
> 
> I did some more tests and it seems 1008000@1.1V is fine but switching
> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
> there is need for some delay somewhere for the regulator to get
> stable?

Please try adding:

  regulator-ramp-delay = <10>

to the gpio regulator.

which will allow 100ms per 1V change, which should b enough for
determining, if this is the cause.

regards,
  Ondrej

> Thanks
> 
> Michal
> 



signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Siarhei Siamashka]

On Thu, 30 Jun 2016 13:13:48 +0200
Michal Suchanek  wrote:

> Hello,
> 
> On 25 June 2016 at 05:45,   wrote:
> > From: Ondrej Jirman 
> >
> > Use Xulong Orange Pi One GPIO based regulator for
> > passive cooling and thermal management.
> >
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
> > +
> >  1 file changed, 39 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> > b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> > index b1bd6b0..a38d871 100644
> > --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> > +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> > @@ -109,6 +109,45 @@
> > };
> >  };
> >
> > + {
> > +   operating-points = <
> > +   /* kHzuV */
> > +   1296000 130
> > +   120 130  
> 
> First problem is that the board boots at 1008000 which is not listed
> and the kernel complains.
> 
> Second problem is that the board locks up during boot with this enabled.
> 
> Do you have some suggestion for alternate configuration to test?

Maybe try the Allwinner's original DVFS table instead of these
undervolted values and see if it helps?

https://linux-sunxi.org/index.php?title=Xunlong_Orange_Pi_PC=17753#CPU_clock_speed_limit

While undervolting is tempting because it helps to decrease the SoC
temperature and avoid throttling, different units may have different
tolerances and one needs to be very careful when picking defaults
that are intended to work correctly on all boards. Some safety
headroom exists there for a reason.

If I remember correctly, some people pushed for undervolting experiments
at least twice in the past (on the Banana Pi and C.H.I.P.). In both
cases this did not end up well and had to be fixed later to solve
reliability problems.

In order to allow individual per-unit tuning, a concept of "speed
grading" may be probably introduced later. So that the board is tested
for reliability and then the speed grade rating is stored somewhere on
the non-removable storage (EEPROM, SPI flash, eFUSE, ...). Some SoC
manufacturers, such as Samsung, are already doing this with their chips.

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Siarhei Siamashka]

On Thu, 30 Jun 2016 13:13:48 +0200
Michal Suchanek  wrote:

> Hello,
> 
> On 25 June 2016 at 05:45,   wrote:
> > From: Ondrej Jirman 
> >
> > Use Xulong Orange Pi One GPIO based regulator for
> > passive cooling and thermal management.
> >
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
> > +
> >  1 file changed, 39 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> > b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> > index b1bd6b0..a38d871 100644
> > --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> > +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> > @@ -109,6 +109,45 @@
> > };
> >  };
> >
> > + {
> > +   operating-points = <
> > +   /* kHzuV */
> > +   1296000 130
> > +   120 130  
> 
> First problem is that the board boots at 1008000 which is not listed
> and the kernel complains.
> 
> Second problem is that the board locks up during boot with this enabled.
> 
> Do you have some suggestion for alternate configuration to test?

Maybe try the Allwinner's original DVFS table instead of these
undervolted values and see if it helps?

https://linux-sunxi.org/index.php?title=Xunlong_Orange_Pi_PC=17753#CPU_clock_speed_limit

While undervolting is tempting because it helps to decrease the SoC
temperature and avoid throttling, different units may have different
tolerances and one needs to be very careful when picking defaults
that are intended to work correctly on all boards. Some safety
headroom exists there for a reason.

If I remember correctly, some people pushed for undervolting experiments
at least twice in the past (on the Banana Pi and C.H.I.P.). In both
cases this did not end up well and had to be fixed later to solve
reliability problems.

In order to allow individual per-unit tuning, a concept of "speed
grading" may be probably introduced later. So that the board is tested
for reliability and then the speed grade rating is stored somewhere on
the non-removable storage (EEPROM, SPI flash, eFUSE, ...). Some SoC
manufacturers, such as Samsung, are already doing this with their chips.

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

Hello,

On 30.6.2016 13:13, Michal Suchanek wrote:
> Hello,
> 
> On 25 June 2016 at 05:45,   wrote:
>> From: Ondrej Jirman 
>>
>> Use Xulong Orange Pi One GPIO based regulator for
>> passive cooling and thermal management.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>> +
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index b1bd6b0..a38d871 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -109,6 +109,45 @@
>> };
>>  };
>>
>> + {
>> +   operating-points = <
>> +   /* kHzuV */
>> +   1296000 130
>> +   120 130
> 
> First problem is that the board boots at 1008000 which is not listed
> and the kernel complains.
> 
> Second problem is that the board locks up during boot with this enabled.
> 
> Do you have some suggestion for alternate configuration to test?

Just to verify, did you test with the entire series applied? (especially
the PLL1 clk application changes)

You may try dropping the highest operating point, it's probably overly
optimistic for Orange Pi One.

Is the power supply/cable you're using hard enough?

Where during the boot process does it lock up?

regards,
  Ondrej

> Thanks
> 
> Michal
> 



signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

Hello,

On 30.6.2016 13:13, Michal Suchanek wrote:
> Hello,
> 
> On 25 June 2016 at 05:45,   wrote:
>> From: Ondrej Jirman 
>>
>> Use Xulong Orange Pi One GPIO based regulator for
>> passive cooling and thermal management.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>> +
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index b1bd6b0..a38d871 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -109,6 +109,45 @@
>> };
>>  };
>>
>> + {
>> +   operating-points = <
>> +   /* kHzuV */
>> +   1296000 130
>> +   120 130
> 
> First problem is that the board boots at 1008000 which is not listed
> and the kernel complains.
> 
> Second problem is that the board locks up during boot with this enabled.
> 
> Do you have some suggestion for alternate configuration to test?

Just to verify, did you test with the entire series applied? (especially
the PLL1 clk application changes)

You may try dropping the highest operating point, it's probably overly
optimistic for Orange Pi One.

Is the power supply/cable you're using hard enough?

Where during the boot process does it lock up?

regards,
  Ondrej

> Thanks
> 
> Michal
> 



signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

Hello,

On 25 June 2016 at 05:45,   wrote:
> From: Ondrej Jirman 
>
> Use Xulong Orange Pi One GPIO based regulator for
> passive cooling and thermal management.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
> +
>  1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index b1bd6b0..a38d871 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -109,6 +109,45 @@
> };
>  };
>
> + {
> +   operating-points = <
> +   /* kHzuV */
> +   1296000 130
> +   120 130

First problem is that the board boots at 1008000 which is not listed
and the kernel complains.

Second problem is that the board locks up during boot with this enabled.

Do you have some suggestion for alternate configuration to test?

Thanks

Michal

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

Hello,

On 25 June 2016 at 05:45,   wrote:
> From: Ondrej Jirman 
>
> Use Xulong Orange Pi One GPIO based regulator for
> passive cooling and thermal management.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
> +
>  1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index b1bd6b0..a38d871 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -109,6 +109,45 @@
> };
>  };
>
> + {
> +   operating-points = <
> +   /* kHzuV */
> +   1296000 130
> +   120 130

First problem is that the board boots at 1008000 which is not listed
and the kernel complains.

Second problem is that the board locks up during boot with this enabled.

Do you have some suggestion for alternate configuration to test?

Thanks

Michal