Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
(for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
cooling maps to account for new OPPs.
Since new OPPs are not available on all Exynos5422/5800 boards modify
dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
Tested on Odroid-XU3 and XU3 Lite.
Cc: Doug Anderson <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Andreas Faerber <[email protected]>
Cc: Thomas Abraham <[email protected]>
Cc: Ben Gamari <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
4 files changed, 43 insertions(+), 7 deletions(-)
Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
===================================================================
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
@@ -118,7 +118,7 @@
/*
* When reaching cpu_alert3, reduce CPU
* by 2 steps. On Exynos5422/5800 that would
- * be: 1600 MHz and 1100 MHz.
+ * (usually) be: 1800 MHz and 1200 MHz.
*/
map3 {
trip = <&cpu_alert3>;
@@ -131,16 +131,16 @@
/*
* When reaching cpu_alert4, reduce CPU
- * further, down to 600 MHz (11 steps for big,
- * 7 steps for LITTLE).
+ * further, down to 600 MHz (13 steps for big,
+ * 8 steps for LITTLE).
*/
- map5 {
+ cooling_map5: map5 {
trip = <&cpu_alert4>;
- cooling-device = <&cpu0 3 7>;
+ cooling-device = <&cpu0 3 8>;
};
- map6 {
+ cooling_map6: map6 {
trip = <&cpu_alert4>;
- cooling-device = <&cpu4 3 11>;
+ cooling-device = <&cpu4 3 13>;
};
};
};
Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
===================================================================
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
@@ -21,6 +21,23 @@
compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
};
+&cluster_a15_opp_table {
+ /delete-node/opp@2000000000;
+ /delete-node/opp@1900000000;
+};
+
+&cluster_a7_opp_table {
+ /delete-node/opp@1400000000;
+};
+
+&cooling_map5 {
+ cooling-device = <&cpu0 3 7>;
+};
+
+&cooling_map6 {
+ cooling-device = <&cpu4 3 11>;
+};
+
&pwm {
/*
* PWM 0 -- fan
Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
===================================================================
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
@@ -146,6 +146,10 @@
vdd-supply = <&ldo9_reg>;
};
+&cluster_a7_opp_table {
+ /delete-property/opp@1400000000;
+};
+
&cpu0 {
cpu-supply = <&buck2_reg>;
};
Index: b/arch/arm/boot/dts/exynos5800.dtsi
===================================================================
--- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
@@ -24,6 +24,16 @@
};
&cluster_a15_opp_table {
+ opp@2000000000 {
+ opp-hz = /bits/ 64 <2000000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
+ opp@1900000000 {
+ opp-hz = /bits/ 64 <1900000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
opp@1700000000 {
opp-microvolt = <1250000>;
};
@@ -85,6 +95,11 @@
};
&cluster_a7_opp_table {
+ opp_a7_14: opp@1400000000 {
+ opp-hz = /bits/ 64 <1400000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
opp@1300000000 {
opp-microvolt = <1250000>;
};
Hello Bartlomiej,
On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> cooling maps to account for new OPPs.
>
> Since new OPPs are not available on all Exynos5422/5800 boards modify
> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>
> Tested on Odroid-XU3 and XU3 Lite.
>
> Cc: Doug Anderson <[email protected]>
> Cc: Javier Martinez Canillas <[email protected]>
> Cc: Andreas Faerber <[email protected]>
> Cc: Thomas Abraham <[email protected]>
> Cc: Ben Gamari <[email protected]>
> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> 4 files changed, 43 insertions(+), 7 deletions(-)
>
> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> @@ -118,7 +118,7 @@
> /*
> * When reaching cpu_alert3, reduce CPU
> * by 2 steps. On Exynos5422/5800 that would
> - * be: 1600 MHz and 1100 MHz.
> + * (usually) be: 1800 MHz and 1200 MHz.
> */
> map3 {
> trip = <&cpu_alert3>;
> @@ -131,16 +131,16 @@
>
> /*
> * When reaching cpu_alert4, reduce CPU
> - * further, down to 600 MHz (11 steps for big,
> - * 7 steps for LITTLE).
> + * further, down to 600 MHz (13 steps for big,
> + * 8 steps for LITTLE).
> */
> - map5 {
> + cooling_map5: map5 {
> trip = <&cpu_alert4>;
> - cooling-device = <&cpu0 3 7>;
> + cooling-device = <&cpu0 3 8>;
> };
> - map6 {
> + cooling_map6: map6 {
> trip = <&cpu_alert4>;
> - cooling-device = <&cpu4 3 11>;
> + cooling-device = <&cpu4 3 13>;
> };
> };
> };
> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> @@ -21,6 +21,23 @@
> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> };
>
> +&cluster_a15_opp_table {
> + /delete-node/opp@2000000000;
> + /delete-node/opp@1900000000;
> +};
> +
> +&cluster_a7_opp_table {
> + /delete-node/opp@1400000000;
> +};
> +
I think that a comment in the DTS why these operating points aren't available
in this board will make more clear why the nodes are being deleted.
> +&cooling_map5 {
> + cooling-device = <&cpu0 3 7>;
> +};
> +
> +&cooling_map6 {
> + cooling-device = <&cpu4 3 11>;
> +};
> +
> &pwm {
> /*
> * PWM 0 -- fan
> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> @@ -146,6 +146,10 @@
> vdd-supply = <&ldo9_reg>;
> };
>
> +&cluster_a7_opp_table {
> + /delete-property/opp@1400000000;
> +};
> +
> &cpu0 {
> cpu-supply = <&buck2_reg>;
> };
> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> @@ -24,6 +24,16 @@
> };
>
> &cluster_a15_opp_table {
> + opp@2000000000 {
> + opp-hz = /bits/ 64 <2000000000>;
> + opp-microvolt = <1250000>;
> + clock-latency-ns = <140000>;
> + };
> + opp@1900000000 {
> + opp-hz = /bits/ 64 <1900000000>;
> + opp-microvolt = <1250000>;
> + clock-latency-ns = <140000>;
> + };
> opp@1700000000 {
> opp-microvolt = <1250000>;
> };
> @@ -85,6 +95,11 @@
> };
>
AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
INT rail would need to be scaled up as well since there's a maximum voltage
difference between the ARM and INT rails before the system becomes unstable:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
https://lkml.org/lkml/2014/5/2/419
The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
the maximum voltage skew is between a limit. But that never made to mainline:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
https://lkml.org/lkml/2014/4/29/28
Did that change and there's infrastructure in mainline now to cope with that?
If that's the case, I think it would be good to mention in the commit message.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> Hello Bartlomiej,
Hi,
> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> > cooling maps to account for new OPPs.
> >
> > Since new OPPs are not available on all Exynos5422/5800 boards modify
> > dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> > Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >
> > Tested on Odroid-XU3 and XU3 Lite.
> >
> > Cc: Doug Anderson <[email protected]>
> > Cc: Javier Martinez Canillas <[email protected]>
> > Cc: Andreas Faerber <[email protected]>
> > Cc: Thomas Abraham <[email protected]>
> > Cc: Ben Gamari <[email protected]>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
> > ---
> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> > arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> > arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> > arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> > 4 files changed, 43 insertions(+), 7 deletions(-)
> >
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> > @@ -118,7 +118,7 @@
> > /*
> > * When reaching cpu_alert3, reduce CPU
> > * by 2 steps. On Exynos5422/5800 that would
> > - * be: 1600 MHz and 1100 MHz.
> > + * (usually) be: 1800 MHz and 1200 MHz.
> > */
> > map3 {
> > trip = <&cpu_alert3>;
> > @@ -131,16 +131,16 @@
> >
> > /*
> > * When reaching cpu_alert4, reduce CPU
> > - * further, down to 600 MHz (11 steps for big,
> > - * 7 steps for LITTLE).
> > + * further, down to 600 MHz (13 steps for big,
> > + * 8 steps for LITTLE).
> > */
> > - map5 {
> > + cooling_map5: map5 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu0 3 7>;
> > + cooling-device = <&cpu0 3 8>;
> > };
> > - map6 {
> > + cooling_map6: map6 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu4 3 11>;
> > + cooling-device = <&cpu4 3 13>;
> > };
> > };
> > };
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> > @@ -21,6 +21,23 @@
> > compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> > };
> >
> > +&cluster_a15_opp_table {
> > + /delete-node/opp@2000000000;
> > + /delete-node/opp@1900000000;
> > +};
> > +
> > +&cluster_a7_opp_table {
> > + /delete-node/opp@1400000000;
> > +};
> > +
>
> I think that a comment in the DTS why these operating points aren't available
> in this board will make more clear why the nodes are being deleted.
Ok, I will add these comments in the next patch revision.
> > +&cooling_map5 {
> > + cooling-device = <&cpu0 3 7>;
> > +};
> > +
> > +&cooling_map6 {
> > + cooling-device = <&cpu4 3 11>;
> > +};
> > +
> > &pwm {
> > /*
> > * PWM 0 -- fan
> > Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > @@ -146,6 +146,10 @@
> > vdd-supply = <&ldo9_reg>;
> > };
> >
> > +&cluster_a7_opp_table {
> > + /delete-property/opp@1400000000;
> > +};
> > +
> > &cpu0 {
> > cpu-supply = <&buck2_reg>;
> > };
> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > @@ -24,6 +24,16 @@
> > };
> >
> > &cluster_a15_opp_table {
> > + opp@2000000000 {
> > + opp-hz = /bits/ 64 <2000000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > + opp@1900000000 {
> > + opp-hz = /bits/ 64 <1900000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > opp@1700000000 {
> > opp-microvolt = <1250000>;
> > };
> > @@ -85,6 +95,11 @@
> > };
> >
>
> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> INT rail would need to be scaled up as well since there's a maximum voltage
> difference between the ARM and INT rails before the system becomes unstable:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> https://lkml.org/lkml/2014/5/2/419
>
> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> the maximum voltage skew is between a limit. But that never made to mainline:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> https://lkml.org/lkml/2014/4/29/28
>
> Did that change and there's infrastructure in mainline now to cope with that?
> If that's the case, I think it would be good to mention in the commit message.
I was not aware of this limitation and AFAIK mainline has currently
no code to handle it. I also cannot find any code to handle this in
Hardkernel's vendor kernel for Odroid-XU3 board.
Do you know whether this problem exists also on Exynos5422/5800
SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
regulator code also on Exynos5800 SoC based Peach Pi board but was
the problem actually present on this board?
[ I added Arjun to Cc:, maybe he can help in explaining this issue
(unfortunately Inderpal's email is no longer working). ]
Please also note that on Exynos5422/5800 SoCs the same ARM rail
voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
IOW if the problem exists it is already present in the mainline
kernel.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Hello Bartlomiej,
On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>
> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>
> Hi,
>
>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>> cooling maps to account for new OPPs.
>>>
>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>
>>> Tested on Odroid-XU3 and XU3 Lite.
>>>
>>> Cc: Doug Anderson <[email protected]>
>>> Cc: Javier Martinez Canillas <[email protected]>
>>> Cc: Andreas Faerber <[email protected]>
>>> Cc: Thomas Abraham <[email protected]>
>>> Cc: Ben Gamari <[email protected]>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>
>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>> @@ -118,7 +118,7 @@
>>> /*
>>> * When reaching cpu_alert3, reduce CPU
>>> * by 2 steps. On Exynos5422/5800 that would
>>> - * be: 1600 MHz and 1100 MHz.
>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>> */
>>> map3 {
>>> trip = <&cpu_alert3>;
>>> @@ -131,16 +131,16 @@
>>>
>>> /*
>>> * When reaching cpu_alert4, reduce CPU
>>> - * further, down to 600 MHz (11 steps for big,
>>> - * 7 steps for LITTLE).
>>> + * further, down to 600 MHz (13 steps for big,
>>> + * 8 steps for LITTLE).
>>> */
>>> - map5 {
>>> + cooling_map5: map5 {
>>> trip = <&cpu_alert4>;
>>> - cooling-device = <&cpu0 3 7>;
>>> + cooling-device = <&cpu0 3 8>;
>>> };
>>> - map6 {
>>> + cooling_map6: map6 {
>>> trip = <&cpu_alert4>;
>>> - cooling-device = <&cpu4 3 11>;
>>> + cooling-device = <&cpu4 3 13>;
>>> };
>>> };
>>> };
>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>> @@ -21,6 +21,23 @@
>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>> };
>>>
>>> +&cluster_a15_opp_table {
>>> + /delete-node/opp@2000000000;
>>> + /delete-node/opp@1900000000;
>>> +};
>>> +
>>> +&cluster_a7_opp_table {
>>> + /delete-node/opp@1400000000;
>>> +};
>>> +
>>
>> I think that a comment in the DTS why these operating points aren't available
>> in this board will make more clear why the nodes are being deleted.
>
> Ok, I will add these comments in the next patch revision.
>
>>> +&cooling_map5 {
>>> + cooling-device = <&cpu0 3 7>;
>>> +};
>>> +
>>> +&cooling_map6 {
>>> + cooling-device = <&cpu4 3 11>;
>>> +};
>>> +
>>> &pwm {
>>> /*
>>> * PWM 0 -- fan
>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>> @@ -146,6 +146,10 @@
>>> vdd-supply = <&ldo9_reg>;
>>> };
>>>
>>> +&cluster_a7_opp_table {
>>> + /delete-property/opp@1400000000;
>>> +};
>>> +
>>> &cpu0 {
>>> cpu-supply = <&buck2_reg>;
>>> };
>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> @@ -24,6 +24,16 @@
>>> };
>>>
>>> &cluster_a15_opp_table {
>>> + opp@2000000000 {
>>> + opp-hz = /bits/ 64 <2000000000>;
>>> + opp-microvolt = <1250000>;
>>> + clock-latency-ns = <140000>;
>>> + };
>>> + opp@1900000000 {
>>> + opp-hz = /bits/ 64 <1900000000>;
>>> + opp-microvolt = <1250000>;
>>> + clock-latency-ns = <140000>;
>>> + };
>>> opp@1700000000 {
>>> opp-microvolt = <1250000>;
>>> };
>>> @@ -85,6 +95,11 @@
>>> };
>>>
>>
>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>> INT rail would need to be scaled up as well since there's a maximum voltage
>> difference between the ARM and INT rails before the system becomes unstable:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>> https://lkml.org/lkml/2014/5/2/419
>>
>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>> the maximum voltage skew is between a limit. But that never made to mainline:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>> https://lkml.org/lkml/2014/4/29/28
>>
>> Did that change and there's infrastructure in mainline now to cope with that?
>> If that's the case, I think it would be good to mention in the commit message.
>
> I was not aware of this limitation and AFAIK mainline has currently
> no code to handle it. I also cannot find any code to handle this in
Yes, that's what I thought as well but maybe I was missing something.
> Hardkernel's vendor kernel for Odroid-XU3 board.
>
> Do you know whether this problem exists also on Exynos5422/5800
> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> regulator code also on Exynos5800 SoC based Peach Pi board but was
> the problem actually present on this board?
>
My understanding is that this problem is present in 5420/5422/5800
but I have no way to confirm this. I'm just guessing from the info
in the ChromiumOS vendor tree.
If you look at the commit that added the regulator-locker driver,
the test says to be done in a Peach Pi so it seems the problem is
not restricted to only Exynos5420:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> (unfortunately Inderpal's email is no longer working). ]
>
Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> IOW if the problem exists it is already present in the mainline
> kernel.
>
Ah, I only looked at your patch and I didn't compare the voltage levels
in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
I wonder if the voltage levels in your patch are correct then, since the
ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
/*
* Default ASV table
*/
static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
1362500, /* L0 2100 */
1312500, /* L1 2000 */
1275000, /* L2 1900 */
1225000, /* L3 1800 */
1200000, /* L4 1700 */
This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
Hi,
On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>
> Hello Bartlomiej,
>
> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >> Hello Bartlomiej,
> >
> > Hi,
> >
> >> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>> cooling maps to account for new OPPs.
> >>>
> >>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>
> >>> Tested on Odroid-XU3 and XU3 Lite.
> >>>
> >>> Cc: Doug Anderson <[email protected]>
> >>> Cc: Javier Martinez Canillas <[email protected]>
> >>> Cc: Andreas Faerber <[email protected]>
> >>> Cc: Thomas Abraham <[email protected]>
> >>> Cc: Ben Gamari <[email protected]>
> >>> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
> >>> ---
> >>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>
> >>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>> @@ -118,7 +118,7 @@
> >>> /*
> >>> * When reaching cpu_alert3, reduce CPU
> >>> * by 2 steps. On Exynos5422/5800 that would
> >>> - * be: 1600 MHz and 1100 MHz.
> >>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>> */
> >>> map3 {
> >>> trip = <&cpu_alert3>;
> >>> @@ -131,16 +131,16 @@
> >>>
> >>> /*
> >>> * When reaching cpu_alert4, reduce CPU
> >>> - * further, down to 600 MHz (11 steps for big,
> >>> - * 7 steps for LITTLE).
> >>> + * further, down to 600 MHz (13 steps for big,
> >>> + * 8 steps for LITTLE).
> >>> */
> >>> - map5 {
> >>> + cooling_map5: map5 {
> >>> trip = <&cpu_alert4>;
> >>> - cooling-device = <&cpu0 3 7>;
> >>> + cooling-device = <&cpu0 3 8>;
> >>> };
> >>> - map6 {
> >>> + cooling_map6: map6 {
> >>> trip = <&cpu_alert4>;
> >>> - cooling-device = <&cpu4 3 11>;
> >>> + cooling-device = <&cpu4 3 13>;
> >>> };
> >>> };
> >>> };
> >>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>> @@ -21,6 +21,23 @@
> >>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>> };
> >>>
> >>> +&cluster_a15_opp_table {
> >>> + /delete-node/opp@2000000000;
> >>> + /delete-node/opp@1900000000;
> >>> +};
> >>> +
> >>> +&cluster_a7_opp_table {
> >>> + /delete-node/opp@1400000000;
> >>> +};
> >>> +
> >>
> >> I think that a comment in the DTS why these operating points aren't available
> >> in this board will make more clear why the nodes are being deleted.
> >
> > Ok, I will add these comments in the next patch revision.
> >
> >>> +&cooling_map5 {
> >>> + cooling-device = <&cpu0 3 7>;
> >>> +};
> >>> +
> >>> +&cooling_map6 {
> >>> + cooling-device = <&cpu4 3 11>;
> >>> +};
> >>> +
> >>> &pwm {
> >>> /*
> >>> * PWM 0 -- fan
> >>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>> @@ -146,6 +146,10 @@
> >>> vdd-supply = <&ldo9_reg>;
> >>> };
> >>>
> >>> +&cluster_a7_opp_table {
> >>> + /delete-property/opp@1400000000;
> >>> +};
> >>> +
> >>> &cpu0 {
> >>> cpu-supply = <&buck2_reg>;
> >>> };
> >>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>> ===================================================================
> >>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>> @@ -24,6 +24,16 @@
> >>> };
> >>>
> >>> &cluster_a15_opp_table {
> >>> + opp@2000000000 {
> >>> + opp-hz = /bits/ 64 <2000000000>;
> >>> + opp-microvolt = <1250000>;
> >>> + clock-latency-ns = <140000>;
> >>> + };
> >>> + opp@1900000000 {
> >>> + opp-hz = /bits/ 64 <1900000000>;
> >>> + opp-microvolt = <1250000>;
> >>> + clock-latency-ns = <140000>;
> >>> + };
> >>> opp@1700000000 {
> >>> opp-microvolt = <1250000>;
> >>> };
> >>> @@ -85,6 +95,11 @@
> >>> };
> >>>
> >>
> >> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >> INT rail would need to be scaled up as well since there's a maximum voltage
> >> difference between the ARM and INT rails before the system becomes unstable:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >> https://lkml.org/lkml/2014/5/2/419
> >>
> >> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >> the maximum voltage skew is between a limit. But that never made to mainline:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >> https://lkml.org/lkml/2014/4/29/28
> >>
> >> Did that change and there's infrastructure in mainline now to cope with that?
> >> If that's the case, I think it would be good to mention in the commit message.
> >
> > I was not aware of this limitation and AFAIK mainline has currently
> > no code to handle it. I also cannot find any code to handle this in
>
> Yes, that's what I thought as well but maybe I was missing something.
>
> > Hardkernel's vendor kernel for Odroid-XU3 board.
> >
> > Do you know whether this problem exists also on Exynos5422/5800
> > SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> > regulator code also on Exynos5800 SoC based Peach Pi board but was
> > the problem actually present on this board?
> >
>
> My understanding is that this problem is present in 5420/5422/5800
> but I have no way to confirm this. I'm just guessing from the info
> in the ChromiumOS vendor tree.
>
> If you look at the commit that added the regulator-locker driver,
> the test says to be done in a Peach Pi so it seems the problem is
> not restricted to only Exynos5420:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>
> > [ I added Arjun to Cc:, maybe he can help in explaining this issue
> > (unfortunately Inderpal's email is no longer working). ]
> >
>
> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
Abhilash's email is also no longer valid.. :(
> > Please also note that on Exynos5422/5800 SoCs the same ARM rail
> > voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> > IOW if the problem exists it is already present in the mainline
> > kernel.
> >
>
> Ah, I only looked at your patch and I didn't compare the voltage levels
> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>
> I wonder if the voltage levels in your patch are correct then, since the
> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>
> /*
> * Default ASV table
> */
> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> 1362500, /* L0 2100 */
> 1312500, /* L1 2000 */
> 1275000, /* L2 1900 */
> 1225000, /* L3 1800 */
> 1200000, /* L4 1700 */
>
> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
I think that the above voltages are original ones for Exynos5420
(not for Exynos5422/5800).
The voltages in my patch were taken from Hardkernel's kernel for
Odroid-XU3:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1250000, /* L4 2000 */
1250000, /* L5 1900 */
1250000, /* L6 1800 */
...
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Hello Bartlomiej,
On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>>
>> Hello Bartlomiej,
>>
>> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>>>> Hello Bartlomiej,
>>>
>>> Hi,
>>>
>>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>>>> cooling maps to account for new OPPs.
>>>>>
>>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>>>
>>>>> Tested on Odroid-XU3 and XU3 Lite.
>>>>>
>>>>> Cc: Doug Anderson <[email protected]>
>>>>> Cc: Javier Martinez Canillas <[email protected]>
>>>>> Cc: Andreas Faerber <[email protected]>
>>>>> Cc: Thomas Abraham <[email protected]>
>>>>> Cc: Ben Gamari <[email protected]>
>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>>>
>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>>>> @@ -118,7 +118,7 @@
>>>>> /*
>>>>> * When reaching cpu_alert3, reduce CPU
>>>>> * by 2 steps. On Exynos5422/5800 that would
>>>>> - * be: 1600 MHz and 1100 MHz.
>>>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>>>> */
>>>>> map3 {
>>>>> trip = <&cpu_alert3>;
>>>>> @@ -131,16 +131,16 @@
>>>>>
>>>>> /*
>>>>> * When reaching cpu_alert4, reduce CPU
>>>>> - * further, down to 600 MHz (11 steps for big,
>>>>> - * 7 steps for LITTLE).
>>>>> + * further, down to 600 MHz (13 steps for big,
>>>>> + * 8 steps for LITTLE).
>>>>> */
>>>>> - map5 {
>>>>> + cooling_map5: map5 {
>>>>> trip = <&cpu_alert4>;
>>>>> - cooling-device = <&cpu0 3 7>;
>>>>> + cooling-device = <&cpu0 3 8>;
>>>>> };
>>>>> - map6 {
>>>>> + cooling_map6: map6 {
>>>>> trip = <&cpu_alert4>;
>>>>> - cooling-device = <&cpu4 3 11>;
>>>>> + cooling-device = <&cpu4 3 13>;
>>>>> };
>>>>> };
>>>>> };
>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>>>> @@ -21,6 +21,23 @@
>>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>>>> };
>>>>>
>>>>> +&cluster_a15_opp_table {
>>>>> + /delete-node/opp@2000000000;
>>>>> + /delete-node/opp@1900000000;
>>>>> +};
>>>>> +
>>>>> +&cluster_a7_opp_table {
>>>>> + /delete-node/opp@1400000000;
>>>>> +};
>>>>> +
>>>>
>>>> I think that a comment in the DTS why these operating points aren't available
>>>> in this board will make more clear why the nodes are being deleted.
>>>
>>> Ok, I will add these comments in the next patch revision.
>>>
>>>>> +&cooling_map5 {
>>>>> + cooling-device = <&cpu0 3 7>;
>>>>> +};
>>>>> +
>>>>> +&cooling_map6 {
>>>>> + cooling-device = <&cpu4 3 11>;
>>>>> +};
>>>>> +
>>>>> &pwm {
>>>>> /*
>>>>> * PWM 0 -- fan
>>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>> @@ -146,6 +146,10 @@
>>>>> vdd-supply = <&ldo9_reg>;
>>>>> };
>>>>>
>>>>> +&cluster_a7_opp_table {
>>>>> + /delete-property/opp@1400000000;
>>>>> +};
>>>>> +
>>>>> &cpu0 {
>>>>> cpu-supply = <&buck2_reg>;
>>>>> };
>>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>>>> ===================================================================
>>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>> @@ -24,6 +24,16 @@
>>>>> };
>>>>>
>>>>> &cluster_a15_opp_table {
>>>>> + opp@2000000000 {
>>>>> + opp-hz = /bits/ 64 <2000000000>;
>>>>> + opp-microvolt = <1250000>;
>>>>> + clock-latency-ns = <140000>;
>>>>> + };
>>>>> + opp@1900000000 {
>>>>> + opp-hz = /bits/ 64 <1900000000>;
>>>>> + opp-microvolt = <1250000>;
>>>>> + clock-latency-ns = <140000>;
>>>>> + };
>>>>> opp@1700000000 {
>>>>> opp-microvolt = <1250000>;
>>>>> };
>>>>> @@ -85,6 +95,11 @@
>>>>> };
>>>>>
>>>>
>>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>>>> INT rail would need to be scaled up as well since there's a maximum voltage
>>>> difference between the ARM and INT rails before the system becomes unstable:
>>>>
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>>>> https://lkml.org/lkml/2014/5/2/419
>>>>
>>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>>>> the maximum voltage skew is between a limit. But that never made to mainline:
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>>>> https://lkml.org/lkml/2014/4/29/28
>>>>
>>>> Did that change and there's infrastructure in mainline now to cope with that?
>>>> If that's the case, I think it would be good to mention in the commit message.
>>>
>>> I was not aware of this limitation and AFAIK mainline has currently
>>> no code to handle it. I also cannot find any code to handle this in
>>
>> Yes, that's what I thought as well but maybe I was missing something.
>>
>>> Hardkernel's vendor kernel for Odroid-XU3 board.
>>>
>>> Do you know whether this problem exists also on Exynos5422/5800
>>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
>>> regulator code also on Exynos5800 SoC based Peach Pi board but was
>>> the problem actually present on this board?
>>>
>>
>> My understanding is that this problem is present in 5420/5422/5800
>> but I have no way to confirm this. I'm just guessing from the info
>> in the ChromiumOS vendor tree.
>>
>> If you look at the commit that added the regulator-locker driver,
>> the test says to be done in a Peach Pi so it seems the problem is
>> not restricted to only Exynos5420:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>>
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>> (unfortunately Inderpal's email is no longer working). ]
>>>
>>
>> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
>
> Abhilash's email is also no longer valid.. :(
>
Yes, I noticed that as well :(
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>>
>>
>> Ah, I only looked at your patch and I didn't compare the voltage levels
>> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>>
>> I wonder if the voltage levels in your patch are correct then, since the
>> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>>
>> /*
>> * Default ASV table
>> */
>> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
>> 1362500, /* L0 2100 */
>> 1312500, /* L1 2000 */
>> 1275000, /* L2 1900 */
>> 1225000, /* L3 1800 */
>> 1200000, /* L4 1700 */
>>
>> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
>
> I think that the above voltages are original ones for Exynos5420
> (not for Exynos5422/5800).
>
In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
> The voltages in my patch were taken from Hardkernel's kernel for
> Odroid-XU3:
>
> /*
> * ASV group voltage table
> */
> static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> ...
> 1250000, /* L4 2000 */
> 1250000, /* L5 1900 */
> 1250000, /* L6 1800 */
> ...
>
> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
>
In general I prefer to use the ChromiumOS tree as a reference instead of the
HardKernel one, since the former is in a much better shape IMHO.
I think is worth to check in a kernel tree in http://opensource.samsung.com/
for a product that's Exynos5422/5800 based.
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
Hi,
On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
> >>
> >> Hello Bartlomiej,
> >>
> >> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>
> >>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >>>> Hello Bartlomiej,
> >>>
> >>> Hi,
> >>>
> >>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>>>> cooling maps to account for new OPPs.
> >>>>>
> >>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>>>
> >>>>> Tested on Odroid-XU3 and XU3 Lite.
> >>>>>
> >>>>> Cc: Doug Anderson <[email protected]>
> >>>>> Cc: Javier Martinez Canillas <[email protected]>
> >>>>> Cc: Andreas Faerber <[email protected]>
> >>>>> Cc: Thomas Abraham <[email protected]>
> >>>>> Cc: Ben Gamari <[email protected]>
> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
> >>>>> ---
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>>>
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -118,7 +118,7 @@
> >>>>> /*
> >>>>> * When reaching cpu_alert3, reduce CPU
> >>>>> * by 2 steps. On Exynos5422/5800 that would
> >>>>> - * be: 1600 MHz and 1100 MHz.
> >>>>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>>>> */
> >>>>> map3 {
> >>>>> trip = <&cpu_alert3>;
> >>>>> @@ -131,16 +131,16 @@
> >>>>>
> >>>>> /*
> >>>>> * When reaching cpu_alert4, reduce CPU
> >>>>> - * further, down to 600 MHz (11 steps for big,
> >>>>> - * 7 steps for LITTLE).
> >>>>> + * further, down to 600 MHz (13 steps for big,
> >>>>> + * 8 steps for LITTLE).
> >>>>> */
> >>>>> - map5 {
> >>>>> + cooling_map5: map5 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu0 3 7>;
> >>>>> + cooling-device = <&cpu0 3 8>;
> >>>>> };
> >>>>> - map6 {
> >>>>> + cooling_map6: map6 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu4 3 11>;
> >>>>> + cooling-device = <&cpu4 3 13>;
> >>>>> };
> >>>>> };
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -21,6 +21,23 @@
> >>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>>>> };
> >>>>>
> >>>>> +&cluster_a15_opp_table {
> >>>>> + /delete-node/opp@2000000000;
> >>>>> + /delete-node/opp@1900000000;
> >>>>> +};
> >>>>> +
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-node/opp@1400000000;
> >>>>> +};
> >>>>> +
> >>>>
> >>>> I think that a comment in the DTS why these operating points aren't available
> >>>> in this board will make more clear why the nodes are being deleted.
> >>>
> >>> Ok, I will add these comments in the next patch revision.
> >>>
> >>>>> +&cooling_map5 {
> >>>>> + cooling-device = <&cpu0 3 7>;
> >>>>> +};
> >>>>> +
> >>>>> +&cooling_map6 {
> >>>>> + cooling-device = <&cpu4 3 11>;
> >>>>> +};
> >>>>> +
> >>>>> &pwm {
> >>>>> /*
> >>>>> * PWM 0 -- fan
> >>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -146,6 +146,10 @@
> >>>>> vdd-supply = <&ldo9_reg>;
> >>>>> };
> >>>>>
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-property/opp@1400000000;
> >>>>> +};
> >>>>> +
> >>>>> &cpu0 {
> >>>>> cpu-supply = <&buck2_reg>;
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -24,6 +24,16 @@
> >>>>> };
> >>>>>
> >>>>> &cluster_a15_opp_table {
> >>>>> + opp@2000000000 {
> >>>>> + opp-hz = /bits/ 64 <2000000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> + opp@1900000000 {
> >>>>> + opp-hz = /bits/ 64 <1900000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> opp@1700000000 {
> >>>>> opp-microvolt = <1250000>;
> >>>>> };
> >>>>> @@ -85,6 +95,11 @@
> >>>>> };
> >>>>>
> >>>>
> >>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >>>> INT rail would need to be scaled up as well since there's a maximum voltage
> >>>> difference between the ARM and INT rails before the system becomes unstable:
> >>>>
> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >>>> https://lkml.org/lkml/2014/5/2/419
> >>>>
> >>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >>>> the maximum voltage skew is between a limit. But that never made to mainline:
> >>>>
> >>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >>>> https://lkml.org/lkml/2014/4/29/28
> >>>>
> >>>> Did that change and there's infrastructure in mainline now to cope with that?
> >>>> If that's the case, I think it would be good to mention in the commit message.
> >>>
> >>> I was not aware of this limitation and AFAIK mainline has currently
> >>> no code to handle it. I also cannot find any code to handle this in
> >>
> >> Yes, that's what I thought as well but maybe I was missing something.
> >>
> >>> Hardkernel's vendor kernel for Odroid-XU3 board.
> >>>
> >>> Do you know whether this problem exists also on Exynos5422/5800
> >>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> >>> regulator code also on Exynos5800 SoC based Peach Pi board but was
> >>> the problem actually present on this board?
> >>>
> >>
> >> My understanding is that this problem is present in 5420/5422/5800
> >> but I have no way to confirm this. I'm just guessing from the info
> >> in the ChromiumOS vendor tree.
> >>
> >> If you look at the commit that added the regulator-locker driver,
> >> the test says to be done in a Peach Pi so it seems the problem is
> >> not restricted to only Exynos5420:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> >>
> >>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> >>> (unfortunately Inderpal's email is no longer working). ]
> >>>
> >>
> >> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> >
> > Abhilash's email is also no longer valid.. :(
> >
>
> Yes, I noticed that as well :(
>
> >>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> >>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> >>> IOW if the problem exists it is already present in the mainline
> >>> kernel.
> >>>
> >>
> >> Ah, I only looked at your patch and I didn't compare the voltage levels
> >> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
> >>
> >> I wonder if the voltage levels in your patch are correct then, since the
> >> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
> >>
> >> /*
> >> * Default ASV table
> >> */
> >> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> >> 1362500, /* L0 2100 */
> >> 1312500, /* L1 2000 */
> >> 1275000, /* L2 1900 */
> >> 1225000, /* L3 1800 */
> >> 1200000, /* L4 1700 */
> >>
> >> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> >
> > I think that the above voltages are original ones for Exynos5420
> > (not for Exynos5422/5800).
> >
>
> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
This seems suboptimal (or maybe even incorrect as Exynos5422/5800
SoCs also use different clock divider values for clocks related to
CPU clock than Exynos5420 SoC).
Anyway, I can drop Peach Pi support from my patch for now if you want.
> > The voltages in my patch were taken from Hardkernel's kernel for
> > Odroid-XU3:
> >
> > /*
> > * ASV group voltage table
> > */
> > static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> > ...
> > 1250000, /* L4 2000 */
> > 1250000, /* L5 1900 */
> > 1250000, /* L6 1800 */
> > ...
> >
> > https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
> >
>
> In general I prefer to use the ChromiumOS tree as a reference instead of the
> HardKernel one, since the former is in a much better shape IMHO.
I generally agree, OTOH Hardkernel's tree is based on Samsung's
vendor trees and additionally it contains all low-level hardware
details for Odroid-XU3 board (not present in ChromiumOS tree).
> I think is worth to check in a kernel tree in http://opensource.samsung.com/
> for a product that's Exynos5422/5800 based.
I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
S5 which is Exynos5422 based) and it uses 50mV lower voltages for
1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
identical to the ones used by HardKernel's tree,
drivers/cpufreq/exynos5422-eagle-cpufreq.c:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1200000, /* L4 2000 */
1200000, /* L5 1900 */
1200000, /* L6 1800 */
1200000, /* L7 1700 */
1200000, /* L8 1600 */
1100000, /* L9 1500 */
1100000, /* L10 1400 */
1100000, /* L11 1300 */
1000000, /* L12 1200 */
1000000, /* L13 1100 */
1000000, /* L14 1000 */
1000000, /* L15 900 */
900000, /* L16 800 */
900000, /* L17 700 */
900000, /* L18 600 */
900000, /* L19 500 */
900000, /* L20 400 */
900000, /* L22 300 */
900000, /* L22 200 */
};
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Hello Bartlomiej,
On 12/14/2016 01:10 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>>
>> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> Hi,
>>>
>>> On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>>>>
>>>> Hello Bartlomiej,
>>>>
>>>> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>
>>>>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>>>>>> Hello Bartlomiej,
>>>>>
>>>>> Hi,
>>>>>
>>>>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>>>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>>>>>> cooling maps to account for new OPPs.
>>>>>>>
>>>>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>>>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>>>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>>>>>
>>>>>>> Tested on Odroid-XU3 and XU3 Lite.
>>>>>>>
>>>>>>> Cc: Doug Anderson <[email protected]>
>>>>>>> Cc: Javier Martinez Canillas <[email protected]>
>>>>>>> Cc: Andreas Faerber <[email protected]>
>>>>>>> Cc: Thomas Abraham <[email protected]>
>>>>>>> Cc: Ben Gamari <[email protected]>
>>>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>>>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>>>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>>>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>>>>>
>>>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>>>>>> @@ -118,7 +118,7 @@
>>>>>>> /*
>>>>>>> * When reaching cpu_alert3, reduce CPU
>>>>>>> * by 2 steps. On Exynos5422/5800 that would
>>>>>>> - * be: 1600 MHz and 1100 MHz.
>>>>>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>>>>>> */
>>>>>>> map3 {
>>>>>>> trip = <&cpu_alert3>;
>>>>>>> @@ -131,16 +131,16 @@
>>>>>>>
>>>>>>> /*
>>>>>>> * When reaching cpu_alert4, reduce CPU
>>>>>>> - * further, down to 600 MHz (11 steps for big,
>>>>>>> - * 7 steps for LITTLE).
>>>>>>> + * further, down to 600 MHz (13 steps for big,
>>>>>>> + * 8 steps for LITTLE).
>>>>>>> */
>>>>>>> - map5 {
>>>>>>> + cooling_map5: map5 {
>>>>>>> trip = <&cpu_alert4>;
>>>>>>> - cooling-device = <&cpu0 3 7>;
>>>>>>> + cooling-device = <&cpu0 3 8>;
>>>>>>> };
>>>>>>> - map6 {
>>>>>>> + cooling_map6: map6 {
>>>>>>> trip = <&cpu_alert4>;
>>>>>>> - cooling-device = <&cpu4 3 11>;
>>>>>>> + cooling-device = <&cpu4 3 13>;
>>>>>>> };
>>>>>>> };
>>>>>>> };
>>>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>>>>>> @@ -21,6 +21,23 @@
>>>>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>>>>>> };
>>>>>>>
>>>>>>> +&cluster_a15_opp_table {
>>>>>>> + /delete-node/opp@2000000000;
>>>>>>> + /delete-node/opp@1900000000;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cluster_a7_opp_table {
>>>>>>> + /delete-node/opp@1400000000;
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> I think that a comment in the DTS why these operating points aren't available
>>>>>> in this board will make more clear why the nodes are being deleted.
>>>>>
>>>>> Ok, I will add these comments in the next patch revision.
>>>>>
>>>>>>> +&cooling_map5 {
>>>>>>> + cooling-device = <&cpu0 3 7>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cooling_map6 {
>>>>>>> + cooling-device = <&cpu4 3 11>;
>>>>>>> +};
>>>>>>> +
>>>>>>> &pwm {
>>>>>>> /*
>>>>>>> * PWM 0 -- fan
>>>>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> @@ -146,6 +146,10 @@
>>>>>>> vdd-supply = <&ldo9_reg>;
>>>>>>> };
>>>>>>>
>>>>>>> +&cluster_a7_opp_table {
>>>>>>> + /delete-property/opp@1400000000;
>>>>>>> +};
>>>>>>> +
>>>>>>> &cpu0 {
>>>>>>> cpu-supply = <&buck2_reg>;
>>>>>>> };
>>>>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> @@ -24,6 +24,16 @@
>>>>>>> };
>>>>>>>
>>>>>>> &cluster_a15_opp_table {
>>>>>>> + opp@2000000000 {
>>>>>>> + opp-hz = /bits/ 64 <2000000000>;
>>>>>>> + opp-microvolt = <1250000>;
>>>>>>> + clock-latency-ns = <140000>;
>>>>>>> + };
>>>>>>> + opp@1900000000 {
>>>>>>> + opp-hz = /bits/ 64 <1900000000>;
>>>>>>> + opp-microvolt = <1250000>;
>>>>>>> + clock-latency-ns = <140000>;
>>>>>>> + };
>>>>>>> opp@1700000000 {
>>>>>>> opp-microvolt = <1250000>;
>>>>>>> };
>>>>>>> @@ -85,6 +95,11 @@
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>>>>>> INT rail would need to be scaled up as well since there's a maximum voltage
>>>>>> difference between the ARM and INT rails before the system becomes unstable:
>>>>>>
>>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>>>>>> https://lkml.org/lkml/2014/5/2/419
>>>>>>
>>>>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>>>>>> the maximum voltage skew is between a limit. But that never made to mainline:
>>>>>>
>>>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>>>>>> https://lkml.org/lkml/2014/4/29/28
>>>>>>
>>>>>> Did that change and there's infrastructure in mainline now to cope with that?
>>>>>> If that's the case, I think it would be good to mention in the commit message.
>>>>>
>>>>> I was not aware of this limitation and AFAIK mainline has currently
>>>>> no code to handle it. I also cannot find any code to handle this in
>>>>
>>>> Yes, that's what I thought as well but maybe I was missing something.
>>>>
>>>>> Hardkernel's vendor kernel for Odroid-XU3 board.
>>>>>
>>>>> Do you know whether this problem exists also on Exynos5422/5800
>>>>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
>>>>> regulator code also on Exynos5800 SoC based Peach Pi board but was
>>>>> the problem actually present on this board?
>>>>>
>>>>
>>>> My understanding is that this problem is present in 5420/5422/5800
>>>> but I have no way to confirm this. I'm just guessing from the info
>>>> in the ChromiumOS vendor tree.
>>>>
>>>> If you look at the commit that added the regulator-locker driver,
>>>> the test says to be done in a Peach Pi so it seems the problem is
>>>> not restricted to only Exynos5420:
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>>>>
>>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>>> (unfortunately Inderpal's email is no longer working). ]
>>>>>
>>>>
>>>> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
>>>
>>> Abhilash's email is also no longer valid.. :(
>>>
>>
>> Yes, I noticed that as well :(
>>
>>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>>> IOW if the problem exists it is already present in the mainline
>>>>> kernel.
>>>>>
>>>>
>>>> Ah, I only looked at your patch and I didn't compare the voltage levels
>>>> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>>>>
>>>> I wonder if the voltage levels in your patch are correct then, since the
>>>> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>>>>
>>>> /*
>>>> * Default ASV table
>>>> */
>>>> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
>>>> 1362500, /* L0 2100 */
>>>> 1312500, /* L1 2000 */
>>>> 1275000, /* L2 1900 */
>>>> 1225000, /* L3 1800 */
>>>> 1200000, /* L4 1700 */
>>>>
>>>> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
>>>
>>> I think that the above voltages are original ones for Exynos5420
>>> (not for Exynos5422/5800).
>>>
>>
>> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
>> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
>
> This seems suboptimal (or maybe even incorrect as Exynos5422/5800
> SoCs also use different clock divider values for clocks related to
> CPU clock than Exynos5420 SoC).
>
Yes, I know. There's lot of if (soc_is_exynos5420()) and if (soc_is_exynos5422())
checks in the driver though so I guess those differences are taken into account.
I haven't reviewed that driver in detail though so maybe something is missing.
> Anyway, I can drop Peach Pi support from my patch for now if you want.
>
I'm not against adding all the missing operating points btw, I'm just trying to
make sure that's safe to do so in mainline.
>>> The voltages in my patch were taken from Hardkernel's kernel for
>>> Odroid-XU3:
>>>
>>> /*
>>> * ASV group voltage table
>>> */
>>> static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
>>> ...
>>> 1250000, /* L4 2000 */
>>> 1250000, /* L5 1900 */
>>> 1250000, /* L6 1800 */
>>> ...
>>>
>>> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
>>>
>>
>> In general I prefer to use the ChromiumOS tree as a reference instead of the
>> HardKernel one, since the former is in a much better shape IMHO.
>
> I generally agree, OTOH Hardkernel's tree is based on Samsung's
> vendor trees and additionally it contains all low-level hardware
> details for Odroid-XU3 board (not present in ChromiumOS tree).
>
Fair enough.
>> I think is worth to check in a kernel tree in http://opensource.samsung.com/
>> for a product that's Exynos5422/5800 based.
>
> I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
> S5 which is Exynos5422 based) and it uses 50mV lower voltages for
> 1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
> identical to the ones used by HardKernel's tree,
>
Interesting, thanks a lot for checking. So if the voltage levels for 1.9 GHz
and 2.0 GHz are the same than 1.8 GHz, then I agree with you that either is
safe to add these OPPs in mainline or the problem is already present there.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
On Tue, Dec 13, 2016 at 04:18:05PM -0300, Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> > cooling maps to account for new OPPs.
> >
> > Since new OPPs are not available on all Exynos5422/5800 boards modify
> > dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> > Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >
> > Tested on Odroid-XU3 and XU3 Lite.
> >
> > Cc: Doug Anderson <[email protected]>
> > Cc: Javier Martinez Canillas <[email protected]>
> > Cc: Andreas Faerber <[email protected]>
> > Cc: Thomas Abraham <[email protected]>
> > Cc: Ben Gamari <[email protected]>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
> > ---
> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> > arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> > arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> > arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> > 4 files changed, 43 insertions(+), 7 deletions(-)
> >
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> > @@ -118,7 +118,7 @@
> > /*
> > * When reaching cpu_alert3, reduce CPU
> > * by 2 steps. On Exynos5422/5800 that would
> > - * be: 1600 MHz and 1100 MHz.
> > + * (usually) be: 1800 MHz and 1200 MHz.
> > */
> > map3 {
> > trip = <&cpu_alert3>;
> > @@ -131,16 +131,16 @@
> >
> > /*
> > * When reaching cpu_alert4, reduce CPU
> > - * further, down to 600 MHz (11 steps for big,
> > - * 7 steps for LITTLE).
> > + * further, down to 600 MHz (13 steps for big,
> > + * 8 steps for LITTLE).
> > */
> > - map5 {
> > + cooling_map5: map5 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu0 3 7>;
> > + cooling-device = <&cpu0 3 8>;
> > };
> > - map6 {
> > + cooling_map6: map6 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu4 3 11>;
> > + cooling-device = <&cpu4 3 13>;
> > };
> > };
> > };
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> > @@ -21,6 +21,23 @@
> > compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> > };
> >
> > +&cluster_a15_opp_table {
> > + /delete-node/opp@2000000000;
> > + /delete-node/opp@1900000000;
> > +};
> > +
> > +&cluster_a7_opp_table {
> > + /delete-node/opp@1400000000;
> > +};
> > +
>
> I think that a comment in the DTS why these operating points aren't available
> in this board will make more clear why the nodes are being deleted.
>
> > +&cooling_map5 {
> > + cooling-device = <&cpu0 3 7>;
> > +};
> > +
> > +&cooling_map6 {
> > + cooling-device = <&cpu4 3 11>;
> > +};
> > +
> > &pwm {
> > /*
> > * PWM 0 -- fan
> > Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > @@ -146,6 +146,10 @@
> > vdd-supply = <&ldo9_reg>;
> > };
> >
> > +&cluster_a7_opp_table {
> > + /delete-property/opp@1400000000;
> > +};
> > +
> > &cpu0 {
> > cpu-supply = <&buck2_reg>;
> > };
> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > @@ -24,6 +24,16 @@
> > };
> >
> > &cluster_a15_opp_table {
> > + opp@2000000000 {
> > + opp-hz = /bits/ 64 <2000000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > + opp@1900000000 {
> > + opp-hz = /bits/ 64 <1900000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > opp@1700000000 {
> > opp-microvolt = <1250000>;
> > };
> > @@ -85,6 +95,11 @@
> > };
> >
>
> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> INT rail would need to be scaled up as well since there's a maximum voltage
> difference between the ARM and INT rails before the system becomes unstable:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> https://lkml.org/lkml/2014/5/2/419
The choice of skipping > 1.8 GHz could be also made because of missing
ASV which is important to detect the BIN2 of Exynos5422. The BIN2 is
capped to 1.8/1.3.
Anyway this shouldn't be limiting us now because we have all data
statically coded in DTS - in mainline boards, only Odroid XU3-lite
uses BIN2.
Beside comments from Javier, I would be happy to see high frequencies
Tested-by on Peach Pi/Pit. AFAIR, we did not have these in SRPOL. :)
Best regards,
Krzysztof
Hi,
On Wed, Dec 14, 2016 at 5:28 AM, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
>
> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>
> Hi,
>
>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>> > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>> > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>> > cooling maps to account for new OPPs.
>> >
>> > Since new OPPs are not available on all Exynos5422/5800 boards modify
>> > dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>> > Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>> >
>> > Tested on Odroid-XU3 and XU3 Lite.
>> >
>> > Cc: Doug Anderson <[email protected]>
>> > Cc: Javier Martinez Canillas <[email protected]>
>> > Cc: Andreas Faerber <[email protected]>
>> > Cc: Thomas Abraham <[email protected]>
>> > Cc: Ben Gamari <[email protected]>
>> > Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
>> > ---
>> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>> > arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>> > arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>> > arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>> > 4 files changed, 43 insertions(+), 7 deletions(-)
>> >
>> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> > ===================================================================
>> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>> > @@ -118,7 +118,7 @@
>> > /*
>> > * When reaching cpu_alert3, reduce CPU
>> > * by 2 steps. On Exynos5422/5800 that would
>> > - * be: 1600 MHz and 1100 MHz.
>> > + * (usually) be: 1800 MHz and 1200 MHz.
>> > */
>> > map3 {
>> > trip = <&cpu_alert3>;
>> > @@ -131,16 +131,16 @@
>> >
>> > /*
>> > * When reaching cpu_alert4, reduce CPU
>> > - * further, down to 600 MHz (11 steps for big,
>> > - * 7 steps for LITTLE).
>> > + * further, down to 600 MHz (13 steps for big,
>> > + * 8 steps for LITTLE).
>> > */
>> > - map5 {
>> > + cooling_map5: map5 {
>> > trip = <&cpu_alert4>;
>> > - cooling-device = <&cpu0 3 7>;
>> > + cooling-device = <&cpu0 3 8>;
>> > };
>> > - map6 {
>> > + cooling_map6: map6 {
>> > trip = <&cpu_alert4>;
>> > - cooling-device = <&cpu4 3 11>;
>> > + cooling-device = <&cpu4 3 13>;
>> > };
>> > };
>> > };
>> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>> > ===================================================================
>> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>> > @@ -21,6 +21,23 @@
>> > compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>> > };
>> >
>> > +&cluster_a15_opp_table {
>> > + /delete-node/opp@2000000000;
>> > + /delete-node/opp@1900000000;
>> > +};
>> > +
>> > +&cluster_a7_opp_table {
>> > + /delete-node/opp@1400000000;
>> > +};
>> > +
>>
>> I think that a comment in the DTS why these operating points aren't available
>> in this board will make more clear why the nodes are being deleted.
>
> Ok, I will add these comments in the next patch revision.
>
>> > +&cooling_map5 {
>> > + cooling-device = <&cpu0 3 7>;
>> > +};
>> > +
>> > +&cooling_map6 {
>> > + cooling-device = <&cpu4 3 11>;
>> > +};
>> > +
>> > &pwm {
>> > /*
>> > * PWM 0 -- fan
>> > Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> > ===================================================================
>> > --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>> > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>> > @@ -146,6 +146,10 @@
>> > vdd-supply = <&ldo9_reg>;
>> > };
>> >
>> > +&cluster_a7_opp_table {
>> > + /delete-property/opp@1400000000;
>> > +};
>> > +
>> > &cpu0 {
>> > cpu-supply = <&buck2_reg>;
>> > };
>> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
>> > ===================================================================
>> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>> > @@ -24,6 +24,16 @@
>> > };
>> >
>> > &cluster_a15_opp_table {
>> > + opp@2000000000 {
>> > + opp-hz = /bits/ 64 <2000000000>;
>> > + opp-microvolt = <1250000>;
>> > + clock-latency-ns = <140000>;
>> > + };
>> > + opp@1900000000 {
>> > + opp-hz = /bits/ 64 <1900000000>;
>> > + opp-microvolt = <1250000>;
>> > + clock-latency-ns = <140000>;
>> > + };
>> > opp@1700000000 {
>> > opp-microvolt = <1250000>;
>> > };
>> > @@ -85,6 +95,11 @@
>> > };
>> >
>>
>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>> INT rail would need to be scaled up as well since there's a maximum voltage
>> difference between the ARM and INT rails before the system becomes unstable:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>> https://lkml.org/lkml/2014/5/2/419
>>
>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>> the maximum voltage skew is between a limit. But that never made to mainline:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>> https://lkml.org/lkml/2014/4/29/28
>>
>> Did that change and there's infrastructure in mainline now to cope with that?
>> If that's the case, I think it would be good to mention in the commit message.
>
> I was not aware of this limitation and AFAIK mainline has currently
> no code to handle it. I also cannot find any code to handle this in
> Hardkernel's vendor kernel for Odroid-XU3 board.
>
> Do you know whether this problem exists also on Exynos5422/5800
> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> regulator code also on Exynos5800 SoC based Peach Pi board but was
> the problem actually present on this board?
This was a long time ago and my memory is quite fuzzy. ...and I think
others have answered some of this already...
...but from my memory:
* This problem was said to exist on all Exynos 5420/5422/5800 SoCs.
* Samsung's original proposal included using the QoS subsystem to
enforce these constraints. I don't know where the Hardkernel source
is offhand, but you could check if that solution was used there? I
see one comment that links to these CLs:
https://chromium-review.googlesource.com/#/c/187420/
https://chromium-review.googlesource.com/#/c/187231/2
https://chromium-review.googlesource.com/#/c/184439/7
https://chromium-review.googlesource.com/#/c/184460/10
https://chromium-review.googlesource.com/#/c/186804/4
https://chromium-review.googlesource.com/#/c/186805/4
https://chromium-review.googlesource.com/#/c/186806/3
https://chromium-review.googlesource.com/#/c/186353/6
* Before using the voltage locker, we used an interrim solution of
bumping the INT frequency up to 500 MHz. See
<https://chromium-review.googlesource.com/#/c/187992/> and
<https://chromium-review.googlesource.com/#/c/187888/>. Perhaps this
is something that's happening upstream?
> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> (unfortunately Inderpal's email is no longer working). ]
>
> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> IOW if the problem exists it is already present in the mainline
> kernel.
Interesting. In the ChromeOS tree I see significantly higher voltages
needed... Note that one might naively look at
<https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
1362500, /* L0 2100 */
1312500, /* L1 2000 */
..but, amazingly enough those voltages aren't used at all. Surprise!
I believe that the above numbers are actually not used and the ASV
numbers are used instead. See
<https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
{ 2100000,
1350000, 1350000, 1350000, 1350000, 1350000,
1337500, 1325000, 1312500, 1300000, 1287500,
1275000, 1262500, 1250000, 1237500 },
I believe that interpretation there is: some bins of the CPU can run
at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
running on a CPU from a nice bin?
---
Anyway, I'm not setup at the moment to do a whole lot on exynos boards
(I'd have to go and dig some out and set them up again), so not sure
I'll be terribly useful in this discussion. ...but I can try to dig
up history, anyway.
-Doug
On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
> > [ I added Arjun to Cc:, maybe he can help in explaining this issue
> > (unfortunately Inderpal's email is no longer working). ]
> >
> > Please also note that on Exynos5422/5800 SoCs the same ARM rail
> > voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> > IOW if the problem exists it is already present in the mainline
> > kernel.
>
> Interesting. In the ChromeOS tree I see significantly higher voltages
> needed... Note that one might naively look at
> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>
> 1362500, /* L0 2100 */
> 1312500, /* L1 2000 */
>
> ..but, amazingly enough those voltages aren't used at all. Surprise!
>
> I believe that the above numbers are actually not used and the ASV
> numbers are used instead. See
> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>
> { 2100000,
> 1350000, 1350000, 1350000, 1350000, 1350000,
> 1337500, 1325000, 1312500, 1300000, 1287500,
> 1275000, 1262500, 1250000, 1237500 },
>
> I believe that interpretation there is: some bins of the CPU can run
> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
That is definitely the case. One could just look at vendors ASV table
(for 1.9 GHz):
{ 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
1200000, 1187500, 1175000, 1162500, 1150000,
1137500, 1125000, 1112500, 1112500},
The theoretical difference is up to 1.875V! From my experiments I saw
BIN1 chips which should be the same... but some working on 1.2V, some on
1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
does not mean that there aren't such...
> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
> running on a CPU from a nice bin?
Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
along with name of tested board. Because the "Tested on XU3" is not
sufficient.
Best regards,
Krzysztof
Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>> (unfortunately Inderpal's email is no longer working). ]
>>>
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>
>> Interesting. In the ChromeOS tree I see significantly higher voltages
>> needed... Note that one might naively look at
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>
>> 1362500, /* L0 2100 */
>> 1312500, /* L1 2000 */
>>
>> ..but, amazingly enough those voltages aren't used at all. Surprise!
>>
>> I believe that the above numbers are actually not used and the ASV
>> numbers are used instead. See
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>
>> { 2100000,
>> 1350000, 1350000, 1350000, 1350000, 1350000,
>> 1337500, 1325000, 1312500, 1300000, 1287500,
>> 1275000, 1262500, 1250000, 1237500 },
>>
>> I believe that interpretation there is: some bins of the CPU can run
>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>
> That is definitely the case. One could just look at vendors ASV table
> (for 1.9 GHz):
> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
> 1200000, 1187500, 1175000, 1162500, 1150000,
> 1137500, 1125000, 1112500, 1112500},
>
> The theoretical difference is up to 1.875V! From my experiments I saw
> BIN1 chips which should be the same... but some working on 1.2V, some on
> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
> does not mean that there aren't such...
>
>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>> running on a CPU from a nice bin?
I've been running the proposed frequency/voltage combinations without any
stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
The chips are poorly cooled, especially the XU4 and quickly step down.
>
> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
> along with name of tested board. Because the "Tested on XU3" is not
> sufficient.
If you point me to how to read these values out, I will publish them.
>
> Best regards,
> Krzysztof
--
Markus Reichl
Hello Markus,
On 12/16/2016 06:08 AM, Markus Reichl wrote:
> Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
>> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>> (unfortunately Inderpal's email is no longer working). ]
>>>>
>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>> IOW if the problem exists it is already present in the mainline
>>>> kernel.
>>>
>>> Interesting. In the ChromeOS tree I see significantly higher voltages
>>> needed... Note that one might naively look at
>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>>
>>> 1362500, /* L0 2100 */
>>> 1312500, /* L1 2000 */
>>>
>>> ..but, amazingly enough those voltages aren't used at all. Surprise!
>>>
>>> I believe that the above numbers are actually not used and the ASV
>>> numbers are used instead. See
>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>>
>>> { 2100000,
>>> 1350000, 1350000, 1350000, 1350000, 1350000,
>>> 1337500, 1325000, 1312500, 1300000, 1287500,
>>> 1275000, 1262500, 1250000, 1237500 },
>>>
>>> I believe that interpretation there is: some bins of the CPU can run
>>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>>
>> That is definitely the case. One could just look at vendors ASV table
>> (for 1.9 GHz):
>> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
>> 1200000, 1187500, 1175000, 1162500, 1150000,
>> 1137500, 1125000, 1112500, 1112500},
>>
>> The theoretical difference is up to 1.875V! From my experiments I saw
>> BIN1 chips which should be the same... but some working on 1.2V, some on
>> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
>> does not mean that there aren't such...
>>
>>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>>> running on a CPU from a nice bin?
>
> I've been running the proposed frequency/voltage combinations without any
> stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
> nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
> The chips are poorly cooled, especially the XU4 and quickly step down.
>
>>
>> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
>> along with name of tested board. Because the "Tested on XU3" is not
>> sufficient.
>
> If you point me to how to read these values out, I will publish them.
>
You can use the exynos-chipid driver posted by Pankaj. Apply patches 1 and
2 from this series (http://www.spinics.net/lists/arm-kernel/msg548384.html)
and then this diff to get the values of the registers that Krzysztof asked:
diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
index cf0128b18ee2..49fa76ec6d49 100644
--- a/drivers/soc/samsung/exynos-chipid.c
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -22,6 +22,9 @@
#define EXYNOS_MAINREV_MASK (0xF << 0)
#define EXYNOS_REV_MASK (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
+#define EXYNOS_PKG_ID 0x04
+#define EXYNOS_AUX_INFO 0x1C
+
static const struct exynos_soc_id {
const char *name;
unsigned int id;
@@ -71,6 +74,8 @@ int __init exynos_chipid_early_init(void)
const struct of_device_id *match;
u32 product_id;
u32 revision;
+ u32 pkg_id;
+ u32 aux_info;
np = of_find_matching_node_and_match(NULL,
of_exynos_chipid_ids, &match);
@@ -84,6 +89,8 @@ int __init exynos_chipid_early_init(void)
product_id = readl_relaxed(exynos_chipid_base);
revision = product_id & EXYNOS_REV_MASK;
+ pkg_id = readl_relaxed(exynos_chipid_base + EXYNOS_PKG_ID);
+ aux_info = readl_relaxed(exynos_chipid_base + EXYNOS_AUX_INFO);
iounmap(exynos_chipid_base);
soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
@@ -100,8 +107,8 @@ int __init exynos_chipid_early_init(void)
soc_dev_attr->soc_id = product_id_to_soc_id(product_id);
- pr_info("Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
- product_id_to_soc_id(product_id), revision);
+ pr_info("Exynos: CPU[%s] CPU_REV[0x%x] PKG_ID[0x%x] AUX_INFO[0x%x] \n",
+ product_id_to_soc_id(product_id), revision, pkg_id, aux_info);
soc_dev = soc_device_register(soc_dev_attr);
if (IS_ERR(soc_dev)) {
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
Hi Markus,
On 16 December 2016 at 14:38, Markus Reichl <[email protected]> wrote:
> Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
>> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>> (unfortunately Inderpal's email is no longer working). ]
>>>>
>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>> IOW if the problem exists it is already present in the mainline
>>>> kernel.
>>>
>>> Interesting. In the ChromeOS tree I see significantly higher voltages
>>> needed... Note that one might naively look at
>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>>
>>> 1362500, /* L0 2100 */
>>> 1312500, /* L1 2000 */
>>>
>>> ..but, amazingly enough those voltages aren't used at all. Surprise!
>>>
>>> I believe that the above numbers are actually not used and the ASV
>>> numbers are used instead. See
>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>>
>>> { 2100000,
>>> 1350000, 1350000, 1350000, 1350000, 1350000,
>>> 1337500, 1325000, 1312500, 1300000, 1287500,
>>> 1275000, 1262500, 1250000, 1237500 },
>>>
>>> I believe that interpretation there is: some bins of the CPU can run
>>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>>
>> That is definitely the case. One could just look at vendors ASV table
>> (for 1.9 GHz):
>> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
>> 1200000, 1187500, 1175000, 1162500, 1150000,
>> 1137500, 1125000, 1112500, 1112500},
>>
>> The theoretical difference is up to 1.875V! From my experiments I saw
>> BIN1 chips which should be the same... but some working on 1.2V, some on
>> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
>> does not mean that there aren't such...
>>
>>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>>> running on a CPU from a nice bin?
>
> I've been running the proposed frequency/voltage combinations without any
> stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
> nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
> The chips are poorly cooled, especially the XU4 and quickly step down.
[snip]
As per my knowlegde Odroid XU3/4 can throttle at much high temperature.
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/drivers/thermal/exynos_thermal.c#L1629
The device tree binding for thermal-zone is kept bit low alert
temperature values
in-order to avoid reaches critical temperature and board shutdown
when compiling the source code. We need t fix this thermal-zone
Their could be some race in thermal or the step wise governor for
exynos is not working correctly.
Better option is to print the cpufreq for cpu0 and cpu4 and respective temp
and plot a graph along timeline. It will give us clear idea on how much
time is spend on high frequency on stress testing.
#!/bin/bash
t=0
while true :
do
a=`cat /sys/devices/virtual/thermal/thermal_zone0/temp`
b=`cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq`
c=`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq`
d=`cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq`
e=`cat /sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_cur_freq`
(( t += 5 ))
echo $t,$a,$b,$d,$e
sleep 1
done
Best Regards
-Anand Moon
Hi Javier,
Am 16.12.2016 um 17:22 schrieb Javier Martinez Canillas:
> Hello Markus,
>
> On 12/16/2016 06:08 AM, Markus Reichl wrote:
>> Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
>>> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>>> (unfortunately Inderpal's email is no longer working). ]
>>>>>
>>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>>> IOW if the problem exists it is already present in the mainline
>>>>> kernel.
>>>>
>>>> Interesting. In the ChromeOS tree I see significantly higher voltages
>>>> needed... Note that one might naively look at
>>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>>>
>>>> 1362500, /* L0 2100 */
>>>> 1312500, /* L1 2000 */
>>>>
>>>> ..but, amazingly enough those voltages aren't used at all. Surprise!
>>>>
>>>> I believe that the above numbers are actually not used and the ASV
>>>> numbers are used instead. See
>>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>>>
>>>> { 2100000,
>>>> 1350000, 1350000, 1350000, 1350000, 1350000,
>>>> 1337500, 1325000, 1312500, 1300000, 1287500,
>>>> 1275000, 1262500, 1250000, 1237500 },
>>>>
>>>> I believe that interpretation there is: some bins of the CPU can run
>>>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>>>
>>> That is definitely the case. One could just look at vendors ASV table
>>> (for 1.9 GHz):
>>> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
>>> 1200000, 1187500, 1175000, 1162500, 1150000,
>>> 1137500, 1125000, 1112500, 1112500},
>>>
>>> The theoretical difference is up to 1.875V! From my experiments I saw
>>> BIN1 chips which should be the same... but some working on 1.2V, some on
>>> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
>>> does not mean that there aren't such...
>>>
>>>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>>>> running on a CPU from a nice bin?
>>
>> I've been running the proposed frequency/voltage combinations without any
>> stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
>> nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
>> The chips are poorly cooled, especially the XU4 and quickly step down.
>>
>>>
>>> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
>>> along with name of tested board. Because the "Tested on XU3" is not
>>> sufficient.
>>
>> If you point me to how to read these values out, I will publish them.
>>
>
> You can use the exynos-chipid driver posted by Pankaj. Apply patches 1 and
> 2 from this series (http://www.spinics.net/lists/arm-kernel/msg548384.html)
> and then this diff to get the values of the registers that Krzysztof asked:
>
Thanks for the code.
XU4: [ 0.080039] Exynos: CPU[EXYNOS5800] CPU_REV[0x1] PKG_ID[0x1c04832a] AUX_INFO[0x43]
XU3: [ 0.080034] Exynos: CPU[EXYNOS5800] CPU_REV[0x1] PKG_ID[0x1604832a] AUX_INFO[0x43]
XU3-lite:[ 0.080033] Exynos: CPU[EXYNOS5800] CPU_REV[0x1] PKG_ID[0x5a12832a] AUX_INFO[0x13000054]
Servus,
--
Markus Reichl
> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> index cf0128b18ee2..49fa76ec6d49 100644
> --- a/drivers/soc/samsung/exynos-chipid.c
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -22,6 +22,9 @@
> #define EXYNOS_MAINREV_MASK (0xF << 0)
> #define EXYNOS_REV_MASK (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
>
> +#define EXYNOS_PKG_ID 0x04
> +#define EXYNOS_AUX_INFO 0x1C
> +
> static const struct exynos_soc_id {
> const char *name;
> unsigned int id;
> @@ -71,6 +74,8 @@ int __init exynos_chipid_early_init(void)
> const struct of_device_id *match;
> u32 product_id;
> u32 revision;
> + u32 pkg_id;
> + u32 aux_info;
>
> np = of_find_matching_node_and_match(NULL,
> of_exynos_chipid_ids, &match);
> @@ -84,6 +89,8 @@ int __init exynos_chipid_early_init(void)
>
> product_id = readl_relaxed(exynos_chipid_base);
> revision = product_id & EXYNOS_REV_MASK;
> + pkg_id = readl_relaxed(exynos_chipid_base + EXYNOS_PKG_ID);
> + aux_info = readl_relaxed(exynos_chipid_base + EXYNOS_AUX_INFO);
> iounmap(exynos_chipid_base);
>
> soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> @@ -100,8 +107,8 @@ int __init exynos_chipid_early_init(void)
> soc_dev_attr->soc_id = product_id_to_soc_id(product_id);
>
>
> - pr_info("Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
> - product_id_to_soc_id(product_id), revision);
> + pr_info("Exynos: CPU[%s] CPU_REV[0x%x] PKG_ID[0x%x] AUX_INFO[0x%x] \n",
> + product_id_to_soc_id(product_id), revision, pkg_id, aux_info);
>
> soc_dev = soc_device_register(soc_dev_attr);
> if (IS_ERR(soc_dev)) {
>
> Best regards,
>
Hi,
On 12/16/2016 01:07 PM, Krzysztof Kozlowski wrote:
> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>> (unfortunately Inderpal's email is no longer working). ]
>>>
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>
>> Interesting. In the ChromeOS tree I see significantly higher voltages
>> needed... Note that one might naively look at
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>
>> 1362500, /* L0 2100 */
>> 1312500, /* L1 2000 */
>>
>> ..but, amazingly enough those voltages aren't used at all. Surprise!
>>
>> I believe that the above numbers are actually not used and the ASV
>> numbers are used instead. See
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>
>> { 2100000,
>> 1350000, 1350000, 1350000, 1350000, 1350000,
>> 1337500, 1325000, 1312500, 1300000, 1287500,
>> 1275000, 1262500, 1250000, 1237500 },
>>
>> I believe that interpretation there is: some bins of the CPU can run
>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>
> That is definitely the case. One could just look at vendors ASV table
> (for 1.9 GHz):
> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
> 1200000, 1187500, 1175000, 1162500, 1150000,
> 1137500, 1125000, 1112500, 1112500},
>
> The theoretical difference is up to 1.875V! From my experiments I saw
> BIN1 chips which should be the same... but some working on 1.2V, some on
> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
> does not mean that there aren't such...
>
>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>> running on a CPU from a nice bin?
>
> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
> along with name of tested board. Because the "Tested on XU3" is not
> sufficient.
>
I agree, we should be dumping PKG_ID and other chip info to know on
which BIN sample this patch is tested on...
As far as Peach-{pit/pi} boards are concerns, this is what I can remember:
1> 5420 (PIT) -> max recommended target frequency is 1800 MHz for A15
2> 5800 (PI)-> max recommended target frequency can go upto 2000 MHz,
with INT rail locking.
INT rail locking schemes never made to mainline, so to be safer side
instead of bumping the clock and voltages better to keep it at safer
range for pit and pi, probably thats why it was kept at 1800MHz.
I am not sure if the same limitation applies to Odroid-XU3 samples.
> Best regards,
> Krzysztof
>
>
>