From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752281AbcGALHw (ORCPT ); Fri, 1 Jul 2016 07:07:52 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:35701 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752004AbcGALHu convert rfc822-to-8bit (ORCPT ); Fri, 1 Jul 2016 07:07:50 -0400 MIME-Version: 1.0 In-Reply-To: References: <20160625034511.7966-1-megous@megous.com> <20160625034511.7966-15-megous@megous.com> <834b8045-d99f-74a3-0353-aa84b897351d@megous.com> From: Michal Suchanek Date: Fri, 1 Jul 2016 12:54:54 +0200 Message-ID: Subject: Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One To: megous@megous.com Cc: dev , "linux-arm-kernel@lists.infradead.org" , Rob Herring , Mark Rutland , Russell King , Maxime Ripard , Chen-Yu Tsai , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 @@ >>>>> }; >>>>> }; >>>>> >>>>> +&cpu0 { >>>>> + operating-points = < >>>>> + /* kHz uV */ >>>>> + 1296000 1300000 >>>>> + 1200000 1300000 >>>> >>>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Suchanek Subject: Re: [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One Date: Fri, 1 Jul 2016 12:54:54 +0200 Message-ID: References: <20160625034511.7966-1-megous@megous.com> <20160625034511.7966-15-megous@megous.com> <834b8045-d99f-74a3-0353-aa84b897351d@megous.com> Reply-To: hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org Cc: dev , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Rob Herring , Mark Rutland , Russell King , Maxime Ripard , Chen-Yu Tsai , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list List-Id: devicetree@vger.kernel.org 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=C5=99ej 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/b= oot/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 @@ >>>>> }; >>>>> }; >>>>> >>>>> +&cpu0 { >>>>> + operating-points =3D < >>>>> + /* kHz uV */ >>>>> + 1296000 1300000 >>>>> + 1200000 1300000 >>>> >>>> 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 enable= d. >>>> >>>> Do you have some suggestion for alternate configuration to test? >>> >>> Just to verify, did you test with the entire series applied? (especiall= y >>> 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 --=20 You received this message because you are subscribed to the Google Groups "= linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. From mboxrd@z Thu Jan 1 00:00:00 1970 From: hramrach@gmail.com (Michal Suchanek) Date: Fri, 1 Jul 2016 12:54:54 +0200 Subject: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One In-Reply-To: References: <20160625034511.7966-1-megous@megous.com> <20160625034511.7966-15-megous@megous.com> <834b8045-d99f-74a3-0353-aa84b897351d@megous.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 @@ >>>>> }; >>>>> }; >>>>> >>>>> +&cpu0 { >>>>> + operating-points = < >>>>> + /* kHz uV */ >>>>> + 1296000 1300000 >>>>> + 1200000 1300000 >>>> >>>> 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 at 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 at 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 at 1.3V and governor is performance the board keeps running 1008000 at 1.1V as set up by u-boot. Changing the top point to 1008000 at 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