From patchwork Tue Apr 16 17:22:59 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Deacon X-Patchwork-Id: 2450131 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by patchwork2.kernel.org (Postfix) with ESMTP id EE0DEDF230 for ; Tue, 16 Apr 2013 17:23:27 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1US9bI-0005wU-78; Tue, 16 Apr 2013 17:23:24 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1US9bF-0003PV-Ba; Tue, 16 Apr 2013 17:23:21 +0000 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1US9bA-0003Od-Lr for linux-arm-kernel@lists.infradead.org; Tue, 16 Apr 2013 17:23:18 +0000 Received: from mudshark.cambridge.arm.com (mudshark.cambridge.arm.com [10.1.79.58]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id r3GHNBki018928; Tue, 16 Apr 2013 18:23:11 +0100 (BST) Date: Tue, 16 Apr 2013 18:22:59 +0100 From: Will Deacon To: Vladimir Danushevsky Subject: Re: [PATCH] Report double word access atomicity on LPAE enabled targets through AUXV Message-ID: <20130416172258.GE3770@mudshark.cambridge.arm.com> References: <20130408142406.GL17995@n2100.arm.linux.org.uk> <20130408155749.GS17476@mudshark.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130416_132317_007070_405EEDAF X-CRM114-Status: GOOD ( 21.62 ) X-Spam-Score: -7.6 (-------) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-7.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.96.50 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Fri, Apr 12, 2013 at 09:58:43PM +0100, Vladimir Danushevsky wrote: > On Apr 8, 2013, at 11:57 AM, Will Deacon wrote: > > Actually, it's not just the presence of those instructions -- it's their > > behaviour wrt atomicity. They are only guaranteed to be atomic if the CPU in > > question supports LPAE. We could call it "lpae" but it might be set even > > when the kernel is using the short-descriptor format. > > I also think that ATOMICD would describe the intended behavior better. I started having second thoughts about the name, on the offchance that some other feature introduced with LPAE is found to be useful to userspace. Then userspace would end up checking ATOMICD in order to determine something different, which is counter-intuitive. Maybe there is no other `killer feature' for userspace with LPAE, but at least we'd be reporting what the hardware says, rather than the small bit which we're interested in. Patch below... Will --->8 commit c6eaaa758c7956b18aa0cfabe9500ef73514b319 Author: Will Deacon Date: Mon Apr 8 17:13:12 2013 +0100 ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions CPUs implementing LPAE have atomic ldrd/strd instructions, meaning that userspace software can avoid having to use the exclusive variants of these instructions if they wish. This patch advertises the atomicity of these instructions via the hwcaps, so userspace can detect this CPU feature. Signed-off-by: Will Deacon diff --git a/arch/arm/include/uapi/asm/hwcap.h b/arch/arm/include/uapi/asm/hwcap.h index 3688fd1..6d34d08 100644 --- a/arch/arm/include/uapi/asm/hwcap.h +++ b/arch/arm/include/uapi/asm/hwcap.h @@ -25,6 +25,6 @@ #define HWCAP_IDIVT (1 << 18) #define HWCAP_VFPD32 (1 << 19) /* set if VFP has 32 regs (not 16) */ #define HWCAP_IDIV (HWCAP_IDIVA | HWCAP_IDIVT) - +#define HWCAP_LPAE (1 << 20) #endif /* _UAPI__ASMARM_HWCAP_H */ diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index eaa7900..57a53c5 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -356,7 +356,7 @@ void __init early_print(const char *str, ...) static void __init cpuid_init_hwcaps(void) { - unsigned int divide_instrs; + unsigned int divide_instrs, vmsa; if (cpu_architecture() < CPU_ARCH_ARMv7) return; @@ -369,6 +369,11 @@ static void __init cpuid_init_hwcaps(void) case 1: elf_hwcap |= HWCAP_IDIVT; } + + /* LPAE implies atomic ldrd/strd instructions */ + vmsa = (read_cpuid_ext(CPUID_EXT_MMFR0) & 0xf) >> 0; + if (vmsa >= 5) + elf_hwcap |= HWCAP_LPAE; } static void __init feat_v6_fixup(void) @@ -875,6 +880,7 @@ static const char *hwcap_str[] = { "vfpv4", "idiva", "idivt", + "atomicd", NULL };