From patchwork Fri Dec 16 16:22:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Javier Martinez Canillas X-Patchwork-Id: 9478073 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9E806601C2 for ; Fri, 16 Dec 2016 16:23:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 905502840B for ; Fri, 16 Dec 2016 16:23:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 848A6287CD; Fri, 16 Dec 2016 16:23:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3A3422861F for ; Fri, 16 Dec 2016 16:23:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932844AbcLPQWn (ORCPT ); Fri, 16 Dec 2016 11:22:43 -0500 Received: from ec2-52-27-115-49.us-west-2.compute.amazonaws.com ([52.27.115.49]:43477 "EHLO osg.samsung.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1762034AbcLPQWc (ORCPT ); Fri, 16 Dec 2016 11:22:32 -0500 Received: from localhost (localhost [127.0.0.1]) by osg.samsung.com (Postfix) with ESMTP id 66175A1310; Fri, 16 Dec 2016 16:22:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at osg.samsung.com Received: from osg.samsung.com ([127.0.0.1]) by localhost (s-opensource.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1NzIyZzXTIa; Fri, 16 Dec 2016 16:22:43 +0000 (UTC) Received: from [192.168.0.83] (unknown [181.121.136.80]) by osg.samsung.com (Postfix) with ESMTPSA id 00012A0E75; Fri, 16 Dec 2016 16:22:36 +0000 (UTC) Subject: Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800 To: Markus Reichl , 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: Javier Martinez Canillas Message-ID: Date: Fri, 16 Dec 2016 13:22:20 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1b6e8d3a-ec7a-db5d-dd0e-ef9d1480f80a@fivetechno.de> Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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: Best regards, 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)) {