linux-kernel - Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Dec 2016 10:08:07 +0100
From:   Markus Reichl <m.reichl@...etechno.de>
To:     Krzysztof Kozlowski <krzk@...nel.org>,
        Doug Anderson <dianders@...omium.org>
Cc:     Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Arjun K V <arjun.kv@...sung.com>,
        Kukjin Kim <kgene@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Russell King <linux@...linux.org.uk>,
        Andreas Faerber <afaerber@...e.de>,
        Thomas Abraham <thomas.ab@...sung.com>,
        Ben Gamari <ben@...rt-cactus.org>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Alim <alim.akhtar@...sung.com>
Subject: Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

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