lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b37490ed1282f45542168701dea332bb@aosc.io>
Date:   Tue, 11 Apr 2017 21:28:55 +0800
From:   icenowy@...c.io
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     linux-pm@...r.kernel.org, linux-sunxi@...glegroups.com,
        linux-kernel@...r.kernel.org,
        Quentin Schulz <quentin.schulz@...e-electrons.com>,
        Chen-Yu Tsai <wens@...e.org>, linux-clk@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 4/5] ARM: sun8i: h3: add operating-points-v2 table for CPU

在 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@...c.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@...000000 {
>> +			opp-hz = /bits/ 64 <480000000>;
>> +			opp-microvolt = <980000 980000 1300000>;
>> +			clock-latency-ns = <244144>; /* 8 32k periods */
>> +		};
>> +
>> +		opp@...000000 {
>> +			opp-hz = /bits/ 64 <816000000>;
>> +			opp-microvolt = <1020000 1020000 1300000>;
>> +			clock-latency-ns = <244144>; /* 8 32k periods */
>> +		};
>> +
>> +		opp@...000000 {
>> +			opp-hz = /bits/ 64 <960000000>;
>> +			opp-microvolt = <1080000 1080000 1300000>;
>> +			clock-latency-ns = <244144>; /* 8 32k periods */
>> +		};
>> +
>> +		opp@...8000000 {
>> +			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.
(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?

> 
> (and therefore, without operating at the voltages listed here).
> 
> Maxime
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ