Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754496AbbKWV5v (ORCPT ); Mon, 23 Nov 2015 16:57:51 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:61726 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752121AbbKWV5s (ORCPT ); Mon, 23 Nov 2015 16:57:48 -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 Subject: Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Date: Mon, 23 Nov 2015 22:57:07 +0100 Message-ID: <6359949.bhCrxaQvmL@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151123213206.GG19156@codeaurora.org> References: <1448068997-26631-1-git-send-email-sboyd@codeaurora.org> <133921941.Qfq59EaTOs@wuerfel> <20151123213206.GG19156@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:sVE9aJAm0kDFGcWPssqLwsii+knSirj6ujy/5gQq+wfcXRrBfxW 0JUZffl0Rl+7pbKzvjKaD4xm/XTXv0HLLP6+sBxUQfAv0Lq6oXgU+LVzWxPzECpCfY/NXLT uGFw8I9hAoQLuCLoP61O6315bpZ9SWYPR15wby/HvDt/ZFwli8d2QKQv4N2se7Hspxb0SBa H9/LzYVWuNQ5ofTqJW8Ug== X-UI-Out-Filterresults: notjunk:1;V01:K0:9J63ySPaLiM=:Xix8pUu7PFtvW7itJJIAdF PjE18K/hDfT3Rfqm20ZHcHFQCqKrJCjb///KbS5n3NCdZuj59yzTWkFlT7c3TbkF7kBPp8EPx 0WsjA81n8NnfsCDcHfnFGaDkJcclUSZVRebBGaOYYx7NiB4DV1dDeGFq7N0yk+cAaM+6wLT1D ZpBagwlI3TEF3/UqieF2u4P5oOI6GkQhJkV+ldiOdSXQtgAd9Tp4voLvEiEpKfwxzjM09v8Bj StmwIjKFuEafhIHoD3zsCXa5+eva0yk5Ak2C+n5X9iiklh6vjoIIMnzrwFgG2XWGmzdzvOSoY X4a4DVBqrm6oLS8LMgLpo00OXP063uaYX6pO4muyw5J5QeIBXRIchroghUJ61TMXvMSAzc6TD Fiq0a5FGRgolvm2M5qlHA3emOyt//rdkkMAZC62BSFxwssCiwknQXCrdS1nsKCYtLb7zlrLPI dJOdHCE7+rggTcq3lEGIEaGuavwS3bSbWCWhKEmv0X9S8RSohRVbvwqVAtHxDOmEYXwBWLdn1 arI5oyMufruIKrSEkqe+W01MwoQ5jBYRdmRR5rY4axbWTCccL7JFllyIv9GWH8EHjzHJNHqlT LbZM+Bhx1nDYu3tmIgpE4Up0tKOosLVpqLrnXUMbiplSVVn7uCz8ATK6dQR11iCS9ky0Is6vO M+RYJs6QqE0mdsDGGYPlkXDHaGcM28mmkhdqnfRytj3DtdndWxRIUXgdZbIJMD835TqGW2HOY h+yHKSaYE2FKuZyu Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5619 Lines: 133 On Monday 23 November 2015 13:32:06 Stephen Boyd wrote: > On 11/23, Arnd Bergmann wrote: > > On Monday 23 November 2015 12:38:47 Stephen Boyd wrote: > > > On 11/23, Arnd Bergmann wrote: > > > > On Monday 23 November 2015 09:14:39 Christopher Covington wrote: > > > > > On 11/23/2015 03:15 AM, Arnd Bergmann wrote: > > > > > LPAE is only supported in the Krait 450. > > > > > > > > > > http://www.anandtech.com/show/7537/qualcomms-snapdragon-805-25ghz-128bit-memory-interface-d3d11class-graphics-more > > > > > > > > > > I'm pretty sure idiv support came earlier, but I don't have the > > > > > specifics on hand. > > > > > > > > I have seen that article, but didn't trust it as a canonical > > > > source of information here. > > > > > > > > If you can confirm that it's right, that would mean that we > > > > don't support LPAE on mach-qcom, as the only SoC with Krait 450 > > > > seems to be APQ8084, and mainline Linux doesn't run on that. > > > > > > arch/arm/boot/dts/qcom-apq8084.dtsi exists in the mainline > > > kernel. We support more than what's in the Kconfig language > > > under mach-qcom. > > > > Ok, cool. I'm sometimes confused by the model numbers, could you > > do a separate patch to update the Kconfig help text? > > What did you have in mind? I'm also confused by the model numbers > so I don't know how helpful I will be. > > It would be nice to drop the ARCH_MSM* configs entirely. If we > could select the right timers from kconfig without using selects > then we could drop them. Or we could just select both types of > timers when building qcom platforms. Ok, dropping the specific Kconfig entries is actually an awesome idea, as it completely solves the other problem as well, more on that below. In that case, don't worry about listing all the models, once we stop listing a subset of them, the confusion is already reduced by the fact that one has to look at the .dts files so see which models we support, and I assume there will be additional ones coming in for at least a few more years (before you stop caring about 32-bit MSM and compatibles). Regarding the timers: HAVE_ARM_ARCH_TIMER is already user-selectable, so maybe something like 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. > > > > The ones we do support are MSM8x60 (Scorpion), MSM8960 > > > > (Krait-without-number),and MSM7874 (Krait 400). Do those all > > > > support IDIV but not LPAE? > > > > > > > > > > Krait supports IDIV for all versions. Scorpion doesn't support > > > IDIV or lpae. Here's the output of /proc/cpuinfo on that device. > > > > > > # cat /proc/cpuinfo > > > processor : 0 > > > model name : ARMv7 Processor rev 2 (v7l) > > > BogoMIPS : 13.50 > > > Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 > > > CPU implementer : 0x51 > > > CPU architecture: 7 > > > CPU variant : 0x0 > > > CPU part : 0x02d > > > CPU revision : 2 > > > > Ok, that leaves just one missing puzzle piece: can you confirm that > > no supported Krait variant other than Krait 450 / apq8084 has LPAE? > > > > Right, apq8084 is the only SoC with a Krait CPU that supports > LPAE. Ok, thanks for the confirmation. Summarizing what we've found, I think we can get away with just introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE. Most CPUs fall clearly into one category or the other, and then we can allow LPAE to be selected for V7VE-only build but not for plain V7, and we can unconditionally build the kernel with arch-$(CONFIG_CPU_32v7VE) = -D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7ve,-march=armv7-a -mcpu=cortex-a15) 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. - 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. 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/