[PATCH 4/5] ARM: sun8i: h3: add operating-points-v2 table for CPU

[icenowy at aosc.io]

在 2017-04-17 04:57，Maxime Ripard 写道：
> On Tue, Apr 11, 2017 at 09:28:55PM +0800, icenowy at 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 at 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 at 480000000 {
>> > > +			opp-hz = /bits/ 64 <480000000>;
>> > > +			opp-microvolt = <980000 980000 1300000>;
>> > > +			clock-latency-ns = <244144>; /* 8 32k periods */
>> > > +		};
>> > > +
>> > > +		opp at 648000000 {
>> > > +			opp-hz = /bits/ 64 <816000000>;
>> > > +			opp-microvolt = <1020000 1020000 1300000>;
>> > > +			clock-latency-ns = <244144>; /* 8 32k periods */
>> > > +		};
>> > > +
>> > > +		opp at 912000000 {
>> > > +			opp-hz = /bits/ 64 <960000000>;
>> > > +			opp-microvolt = <1080000 1080000 1300000>;
>> > > +			clock-latency-ns = <244144>; /* 8 32k periods */
>> > > +		};
>> > > +
>> > > +		opp at 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.

I checked the wiki, it says "The Orange Pi PC board uses the
SY8106A voltage regulator for providing the CPU core voltage
(VDD_CPUX). The default CPU voltage is 1.2V after power-on
(selected by the resistors on the PCB) and can be changed at
runtime by software via I2C interface. According to the table
above, this default voltage should be safe for using with the
CPU clock frequencies up to 1008MHz. The H3 datasheet specifies
1.5V as the absolute maximum for the VDD_CPUX voltage and
1.4V as the recommended maximum." in the "Xunlong Orange Pi PC"
page.

> 
>> (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?

No problem... But I think the H3 part of the patch is still not merged
yet...

> 
> Maxime