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

Groups > linux.kernel > #1740642 > unrolled thread

Re: [PATCH 0/3] Simple DVFS support for Allwinner A64 SoC

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/3] Simple DVFS support for Allwinner A64 SoC icenowy@aosc.io - 2017-09-27 14:00 +0200
    Re: [PATCH 0/3] Simple DVFS support for Allwinner A64 SoC Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-09-28 12:30 +0200

#1740642 — Re: [PATCH 0/3] Simple DVFS support for Allwinner A64 SoC

在 2017-09-25 18:27，Maxime Ripard 写道：
> On Mon, Sep 25, 2017 at 10:12:09AM +0000, Icenowy Zheng wrote:
>> 于 2017年9月25日 GMT+08:00 下午6:10:27, Maxime Ripard 
>> <maxime.ripard@free-electrons.com> 写到:
>> >Hi,
>> >
>> >On Sat, Sep 23, 2017 at 12:15:28AM +0000, Icenowy Zheng wrote:
>> >> This patchset imports simple DVFS support for Allwinner A64 SoC.
>> >>
>> >> As the thermal sensor driver is not yet implemented and some boards
>> >> have still no AXP PMIC support, now only two OPPs are present --
>> >> 648MHz@1.04V and 816MHz@1.1V to prevent overheat or undervoltage.
>> >>
>> >> PATCH 1 is a fix to the CCU driver of A64, and the remaining patches
>> >> set up the device tree bits of the DVFS on Pine64.
>> >
>> >How has this been tested?
>> >
>> >What tasks did you run, with what governor, etc...
>> 
>> I only tested manual frequency switching between 648MHz and
>> 816MHz, and tested the PLL stuck issue by change the OPPs to
>> some random value.
> 
> Ideally, we should test that it's actually reliable. Poorly chosen
> OPPs might lead to corrupt data that you might not get before a while.
> 
> Please test using:
> https://linux-sunxi.org/Hardware_Reliability_Tests#Reliability_of_cpufreq_voltage.2Ffrequency_settings
> 
> And post the report.

```
root@p64 [ cpuburn-arm@master ] # ./cpuburn-a53 &
[1] 2543
root@p64 [ cpuburn-arm@master ] # ./cpufreq-ljt-stress-test
Creating './whitenoise-1920x1080.jpg' ... done
CPU stress test, which is doing JPEG decoding by libjpeg-turbo
at different cpufreq operating points.

Testing CPU 0
   816 MHz ............................................................ 
OK
   648 MHz ............................................................ 
OK

Testing CPU 1
   816 MHz ............................................................ 
OK
   648 MHz ............................................................ 
OK

Testing CPU 2
   816 MHz ............................................................ 
OK
   648 MHz ............................................................ 
OK

Testing CPU 3
   816 MHz ............................................................ 
OK
   648 MHz ............................................................ 
OK

Overall result : PASSED
```

> 
> Maxime

[toc] | [next] | [standalone]

#1741400

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

Hi,

On Wed, Sep 27, 2017 at 11:51:30AM +0000, icenowy@aosc.io wrote:
> 在 2017-09-25 18:27，Maxime Ripard 写道：
> > On Mon, Sep 25, 2017 at 10:12:09AM +0000, Icenowy Zheng wrote:
> > > 于 2017年9月25日 GMT+08:00 下午6:10:27, Maxime Ripard
> > > <maxime.ripard@free-electrons.com> 写到:
> > > >Hi,
> > > >
> > > >On Sat, Sep 23, 2017 at 12:15:28AM +0000, Icenowy Zheng wrote:
> > > >> This patchset imports simple DVFS support for Allwinner A64 SoC.
> > > >>
> > > >> As the thermal sensor driver is not yet implemented and some boards
> > > >> have still no AXP PMIC support, now only two OPPs are present --
> > > >> 648MHz@1.04V and 816MHz@1.1V to prevent overheat or undervoltage.
> > > >>
> > > >> PATCH 1 is a fix to the CCU driver of A64, and the remaining patches
> > > >> set up the device tree bits of the DVFS on Pine64.
> > > >
> > > >How has this been tested?
> > > >
> > > >What tasks did you run, with what governor, etc...
> > > 
> > > I only tested manual frequency switching between 648MHz and
> > > 816MHz, and tested the PLL stuck issue by change the OPPs to
> > > some random value.
> > 
> > Ideally, we should test that it's actually reliable. Poorly chosen
> > OPPs might lead to corrupt data that you might not get before a while.
> > 
> > Please test using:
> > https://linux-sunxi.org/Hardware_Reliability_Tests#Reliability_of_cpufreq_voltage.2Ffrequency_settings
> > 
> > And post the report.
> 
> ```
> root@p64 [ cpuburn-arm@master ] # ./cpuburn-a53 &
> [1] 2543
> root@p64 [ cpuburn-arm@master ] # ./cpufreq-ljt-stress-test
> Creating './whitenoise-1920x1080.jpg' ... done
> CPU stress test, which is doing JPEG decoding by libjpeg-turbo
> at different cpufreq operating points.
> 
> Testing CPU 0
>   816 MHz ............................................................ OK
>   648 MHz ............................................................ OK
> 
> Testing CPU 1
>   816 MHz ............................................................ OK
>   648 MHz ............................................................ OK
> 
> Testing CPU 2
>   816 MHz ............................................................ OK
>   648 MHz ............................................................ OK
> 
> Testing CPU 3
>   816 MHz ............................................................ OK
>   648 MHz ............................................................ OK
> 
> Overall result : PASSED
> ```

Great, thanks!

Can you put that in your cover letter for the next version?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web