Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753583AbbKXKSJ (ORCPT ); Tue, 24 Nov 2015 05:18:09 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:59639 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753005AbbKXKSF (ORCPT ); Tue, 24 Nov 2015 05:18:05 -0500 From: Arnd Bergmann To: Stephen Boyd Cc: linux-arm-kernel@lists.infradead.org, Nicolas Pitre , Peter Maydell , =?ISO-8859-1?Q?M=E5ns_Rullg=E5rd?= , Russell King - ARM Linux , "linux-arm-msm@vger.kernel.org" , lkml - Kernel Mailing List , Steven Rostedt , Christopher Covington , Daniel Lezcano , Thomas Petazzoni Subject: Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Date: Tue, 24 Nov 2015 11:17:23 +0100 Message-ID: <3811106.btnGdZynet@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151123231352.GH19156@codeaurora.org> References: <1448068997-26631-1-git-send-email-sboyd@codeaurora.org> <6359949.bhCrxaQvmL@wuerfel> <20151123231352.GH19156@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:VXtEwqymb50Mx5Y+AfytkAdLtrlY4pyHX2AkDqREneeexhlf2Yv Iueq47Go/lp2RbYkidPfMJV2gE1vt/SzpYdBs+nXX5vokWsaYE1fOLJH7JKsXVDZb0n7QcY X0lO+s/rQtAWgqKokl7Ls0I17KKxUVmPtxROHJlArchMA2w7v7giENSaP9qB95NF6atWUUR uibiP1Ay15M6mM8pu2nKA== X-UI-Out-Filterresults: notjunk:1;V01:K0:by/jhDhJwXE=:LJz/lTj6jCFYsnbUjz2LoD w1lcAm07ardfJX2ouegPYqWbHsFfS4ISz9sHzhk7GdGBxOoNFUgHufENXJl5nmlG9+O04i4FK Ugh3xQdnBuEz2tBRYWNewsA+hKQtJxPcPCCcKSdliQJ3dOdrHp2Ci0rMRsUgCiyTGk0BIZSUw yFbvKmKed6OQnI/7nmlzySrxKFwkmbRFR4HZFVKeIxBG1QaDOwXmN0J0VncZSPORqRDhLNM2G Y4zDPn/7hPkVcW32xKp8Sip20mfzVkk/BNfvHgsBU3vCfp/LU7X6gOSkjCj8Qun1Zf9+xuHCe ByYIr6Xf1ZAJtOFNg2YxoHQI2wkDeQgHL8HVqNS1ebdjOc61ZFWKn7r7T+COqdO9vu7GGdIOg //QSDWEvsH4VrszbSRdFV/2YZwW+IqtLJt8C42bPDxy7PikJmP94X5L7m35HdS7qAk42tapKO b9dtsY0oGTTaAWAPuUKsvgBHu6iOZnGGdr/HopoxLnF1cmDQGu1ZLJtyZ4IWFf0BvUCyGnYQr 3Xy+L9iq8yaSmBGGd2qftRPxoneXm8n3rZb2slOwVqHDusAx5f8N5Gpymt9rpzsHTORhTfZgm mk88Ez4uHsV06qaIt7CbqQliRAG3HsJsWOYvjWiupyoccglwHY1PkwfOWefw9MvYlA4qMTN3S Je7lBYk/eApxlqeURNhOOy3ZeUMgI9kN529Vd76Sch0aG7nU2pXMHnqRx4OnPD5ZIKCdgi1QO J6OhTYpd3Ea4DBbQ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4356 Lines: 112 On Monday 23 November 2015 15:13:52 Stephen Boyd wrote: > On 11/23, Arnd Bergmann wrote: > > On Monday 23 November 2015 13:32:06 Stephen Boyd wrote: > > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig > > index b251013eef0a..bad6343c34d5 100644 > > --- a/drivers/clocksource/Kconfig > > +++ b/drivers/clocksource/Kconfig > > @@ -324,8 +324,9 @@ config EM_TIMER_STI > > such as EMEV2 from former NEC Electronics. > > > > config CLKSRC_QCOM > > - bool "Qualcomm MSM timer" if COMPILE_TEST > > + bool "Qualcomm MSM timer" if ARCH_QCOM || COMPILE_TEST > > depends on ARM > > + default ARCH_QCOM > > select CLKSRC_OF > > help > > This enables the clocksource and the per CPU clockevent driver for the > > > > would make both of them equally configurable and not clutter up > > the Kconfig file when ARCH_QCOM is not selected. I've added > > Daniel Lezcano to Cc, he probably has an opinion on this too. > > Yeah I think that architected timers are an outlier. I recall > some words from John Stultz that platforms should select the > clocksources they use, but maybe things have changed. For this > kind of thing I wouldn't mind putting it in the defconfig though. > I'll put the patches on the list to get the discussion started. Ok, thanks! > > This works perfectly for Cortex-A5, -A8, -A9, -A12, -A15, -A17, Brahma-B15, > > PJ4B-MP, Scorpion and Krait-450, which all clearly fall into one of > > the two other categories. > > > > The two exceptions that don't quite fit are still "good enough": > > > > - PJ4/PJ4B (not PJ4B-MP) has a different custom opcode for udiv and sdiv > > in ARM mode. We don't support that with true multiplatform kernels > > because those opcodes work nowhere else, though with your proposed > > series we could easily do that for dynamic patching. > > Do you have the information on these custom opcodes? I can work > that into the patches assuming the MIDR is different. Thomas Petazzoni said this in a private mail: | According to the datasheet, the PJ4B has integer signed and unsigned | divide, similar to the sdiv and udiv ARM instructions. But the way to | access it is by doing a MRC instruction. | | MRC p6, 1, Rd , CRn , CRm, 4 | |for PJ4B is the same as: | | SDIV Rd , Rn, Rm | | on ARM cores. | |And: | | MRC p6, 1, Rd , CRn , CRm, 0 | |for PJ4B is the same as: | | UDIV Rd , Rn, Rm | |on ARM cores. | |This is documented in the "Extended instructions" section of the |PJ4B datasheet. I assume what he meant was that this is true for both PJ4 and PJ4B but not for PJ4B-MP, which has the normal udiv/sdiv instructions. IOW, anything with CPU implementer 0x56 part 0x581 should use those, while part 0x584 can use the sdiv/udiv that it reports correctly. > > - Krait (pre-450) won't run kernels with LPAE disabled, but if we only > > have one global ARCH_QCOM option that can be enabled for both > > ARCH_MULTI_V7VE and ARCH_MULTI_V7, we still win: a mach-qcom > > kernel with only ARCH_MULTI_V7VE will use IDIV by default, and > > give you the option to enable LPAE. If you pick LPAE, it will > > still work fine on Krait-450 but not the older ones, and that is > > a user error. If you enable ARCH_MULTI_V7 / CPU_V7, you get neither > > LPAE nor IDIV, and the kernel will be able to run on both Scorpion > > and Krait, as long as you have the right drivers too. > > > > So if I have built mach-qcom with ARCH_MULTI_V7VE won't I get a > kernel that uses idiv instructions that could be run on Scorpion, > where the instruction doesn't exist? Or is that a user error > again like picking LPAE? Right. If you want to run on Scorpion, you have to select ARCH_MULTI_V7. If both are set, we should build with -march=armv7-a and not use the idiv instructions. > It seems fine to me to go ahead with this approach. Should I take > care of cooking up the patches? I can package this all up into a > series that adds the new CPU type, updates the affected > platforms, and layers the runtime patching on top when plain V7 > is a selected CPU type. That would be nice, yes. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/