From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754891AbcLSJO5 (ORCPT ); Mon, 19 Dec 2016 04:14:57 -0500 Received: from wp126.webpack.hosteurope.de ([80.237.132.133]:55004 "EHLO wp126.webpack.hosteurope.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753293AbcLSJO1 (ORCPT ); Mon, 19 Dec 2016 04:14:27 -0500 Subject: Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800 To: Javier Martinez Canillas , Krzysztof Kozlowski , Doug Anderson References: <5220084.l31t5oJbsy@amdc3058> <26ffeee4-ff43-b3d3-3267-5fcbc50e2974@osg.samsung.com> <2340115.HEG9AYUCMD@amdc3058> <20161216073720.GA3489@kozik-lap> <1b6e8d3a-ec7a-db5d-dd0e-ef9d1480f80a@fivetechno.de> Cc: Bartlomiej Zolnierkiewicz , Arjun K V , Kukjin Kim , Rob Herring , Mark Rutland , Russell King , Andreas Faerber , Thomas Abraham , Ben Gamari , linux-samsung-soc , "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Alim From: Markus Reichl Organization: five technologies GmbH Message-ID: <027dfa2d-487a-e360-6e4a-4fc44f6622fa@fivetechno.de> Date: Mon, 19 Dec 2016 10:14:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;m.reichl@fivetechno.de;1482138867;038a122f; X-HE-SMSGID: 1cIu1L-0006RL-Ib Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>> . >>>> >>>> 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 >>>> >>>> >>>> { 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, >