lkml.org 
[lkml]   [2017]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/5] ARM: sun8i: h3: add operating-points-v2 table for CPU
On Tue, Apr 11, 2017 at 09:28:55PM +0800, icenowy@aosc.io wrote:
> 在 2017-04-11 17:13,Maxime Ripard 写道:
> > On Sun, Apr 09, 2017 at 02:50:24AM +0800, Icenowy Zheng wrote:
> > > The CPU on Allwinner H3 can do dynamic frequency scaling.
> > >
> > > Add a DVFS table based on the one tweaked by Armbian developers, which
> > > are proven to work stably on BSP kernels.
> > >
> > > Frequencies higher than 1008MHz are temporarily dropped in the
> > > table, as
> > > they may lead to over voltage on boards without proper regulator
> > > settings or over temperature on boards with proper regulator settings.
> > > They will be added back once regulator settings are ready and thermal
> > > sensor driver is merged.
> > >
> > > In order to satisfy all different regulators (SY8106A which is 50mV
> > > per
> > > level, SY8113B which have two states: 1.1V and 1.3V, and some board
> > > with
> > > non-tweakable regulators), all the OPPs are defined with a range
> > > which has
> > > the target value as the minimum allowed value, and 1.3V (the highest
> > > VDD-CPUX voltage suggested by the datasheet) as the maximum allowed
> > > value.
> > > It's proven to work well with a board with SY8113B.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > ---
> > > arch/arm/boot/dts/sun8i-h3.dtsi | 38
> > > +++++++++++++++++++++++++++++++++++++-
> > > 1 file changed, 37 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
> > > b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > index b36f9f423c39..a0cee17fe44b 100644
> > > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > @@ -43,32 +43,68 @@
> > > #include "sunxi-h3-h5.dtsi"
> > >
> > > / {
> > > + cpu0_opp_table: opp_table0 {
> > > + compatible = "operating-points-v2";
> > > + opp-shared;
> > > +
> > > + opp@480000000 {
> > > + opp-hz = /bits/ 64 <480000000>;
> > > + opp-microvolt = <980000 980000 1300000>;
> > > + clock-latency-ns = <244144>; /* 8 32k periods */
> > > + };
> > > +
> > > + opp@648000000 {
> > > + opp-hz = /bits/ 64 <816000000>;
> > > + opp-microvolt = <1020000 1020000 1300000>;
> > > + clock-latency-ns = <244144>; /* 8 32k periods */
> > > + };
> > > +
> > > + opp@912000000 {
> > > + opp-hz = /bits/ 64 <960000000>;
> > > + opp-microvolt = <1080000 1080000 1300000>;
> > > + clock-latency-ns = <244144>; /* 8 32k periods */
> > > + };
> > > +
> > > + opp@1008000000 {
> > > + opp-hz = /bits/ 64 <1008000000>;
> > > + opp-microvolt = <1140000 1140000 1300000>;
> > > + clock-latency-ns = <244144>; /* 8 32k periods */
> > > + };
> > > + };
> > > +
> >
> > From your serie, I guess you never actually tested those OPPs on any
> > board without SY8113B, right?
>
> Yes. But I will test them on an Orange Pi PC (newly got) soon.

The orange pi pc also uses the SY8113B.

> (After all PLL_CPUX-related things are well fixed)
>
> P.S. how to implement such a thing:
>
> - Before tweaking CPUX clock, first switch it to osc24M
> (implemented yet)
> - Before tweaking PLL_CPUX clock (triggered by tweaking CPUX
> clock), first gate it
> - After tweaking PLL_CPUX clock, ungate it and wait it to be stable
> - After tweaking PLL_CPUX clock, change CPUX mux back to PLL_CPUX
> (implemented yet)
>
> I think notifiers on PLL_CPUX can be used to implement the second
> and third part?

Do you still have any issues with the code we merged?

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2017-04-16 22:58    [W:0.394 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site