From patchwork Mon Nov 5 17:26:24 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: tip-bot for Dave Martin X-Patchwork-Id: 1699871 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork1.kernel.org (Postfix) with ESMTP id 17CF33FCDE for ; Mon, 5 Nov 2012 17:28:25 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TVQRX-0002X9-Qo; Mon, 05 Nov 2012 17:26:35 +0000 Received: from mail-bk0-f49.google.com ([209.85.214.49]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1TVQRT-0002Vr-OB for linux-arm-kernel@lists.infradead.org; Mon, 05 Nov 2012 17:26:32 +0000 Received: by mail-bk0-f49.google.com with SMTP id j4so2059062bkw.36 for ; Mon, 05 Nov 2012 09:26:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-gm-message-state; bh=fGh2Pzs/m2yqnH42DhrONVPJb+v4MCG94TpW/Lw2Aog=; b=CP5X2ODqLeIitEFT7p8FXJYIIP9gVPqEscGRxEvy6iEIJYcnMFAT+I4r0gjUkwFLB8 QXBmeLFaixczu5u6rvqDlhO4iUP/AxwpR6swpGADhKYtLwIdleruILr41fXN4OpwSXAm Kv5/21h0QS3F9pzzqhc2mojr18ZcsyKtrFOvI717V74fU2/9uFJ9iqdW526+TjoR0isw be2iouNiVg397z0tyz5Ka6epCC+RnzZDHlhtm95VVNHlV/3pNUOneY9zZi6vPaGOZv8A ZBqOh+lvH8QAnyCcslZr9tGsMGCXGdXDpliUQdlhXjXhg0wZTg9Fno0M0kfJ6GRKh31v p6Sg== Received: by 10.204.11.133 with SMTP id t5mr2569459bkt.14.1352136388953; Mon, 05 Nov 2012 09:26:28 -0800 (PST) Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63]) by mx.google.com with ESMTPS id v14sm10417543bkv.10.2012.11.05.09.26.26 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 09:26:27 -0800 (PST) Date: Mon, 5 Nov 2012 17:26:24 +0000 From: Dave Martin To: Nicolas Pitre Subject: Re: [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores Message-ID: <20121105172624.GE2005@linaro.org> References: <20121025093411.GA32662@sig21.net> <50893389.2090002@gmail.com> <20121025141645.GA16962@sig21.net> <50894BC2.5050706@gmail.com> <20121025150816.GA3874@sig21.net> <20121105104839.GA2005@linaro.org> <20121105111346.GF28327@n2100.arm.linux.org.uk> <20121105130255.GD2005@linaro.org> <20121105153917.GG28327@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQmH/IOzqhgpJ5wMBAdXWHz5ocEklGtb4B1vXgEOebztsa9QC4xMJ1ppZZmPsEIL8l2v9QnI X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20121105_122631_965162_AAE78388 X-CRM114-Status: GOOD ( 23.18 ) X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.214.49 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Johannes Stezenbach , Russell King - ARM Linux , Arnd Bergmann , Rob Herring , Olof Johansson , Shawn Guo , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Mon, Nov 05, 2012 at 11:13:51AM -0500, Nicolas Pitre wrote: > On Mon, 5 Nov 2012, Russell King - ARM Linux wrote: > > > On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote: > > > Why not allow unaligned accesses in the decompressor, though, both > > > for v6 and v7? > > > > EXACTLY. > > I have no objections to that. In fact, I made a remark to this effect > in my initial review of this patch. Whether or not gcc does take > advantage of this hardware ability in the end is orthogonal. For the sake of argument, here's how it might look. Currently, I make no attempt to restore the original state of the U bit. The A bit if forced later by the kernel during boot, after a short window during which we should only run low-level arch code and therefore where no unaligned accesses should happen. Does anyone think these issues are likely to be important? Cheers ---Dave From 160a5576b53264951ff8164775146b2d4feddecb Mon Sep 17 00:00:00 2001 From: Dave Martin Date: Mon, 5 Nov 2012 16:34:57 +0000 Subject: [PATCH] ARM: decompressor: Enable unaligned memory access for v6 and above Modern GCC can generate code which makes use of the CPU's native unaligned memory access capabilities. This is useful for the C decompressor implementations used for unpacking compressed kernels. This patch disables the alignment faults and enabled the v6 unaligned access on CPUs which support these features (i.e., v6 and later), allowing full unaligned access support for C code in the decompressor. The decompressor C code must not be built to assume that unaligned access works if support for v5 or older platforms is included in the kernel. Signed-off-by: Dave Martin Acked-by: Nicolas Pitre --- Note: I have only build-tested this so far. arch/arm/boot/compressed/head.S | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 90275f0..cfbb4c9 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -652,6 +652,15 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size mov pc, lr ENDPROC(__setup_mmu) +@ Enable unaligned access on v6, to allow better code generation +@ for the decompressor C code: +__armv6_mmu_cache_on: + mrc p15, 0, r0, c1, c0, 0 @ read SCTLR + bic r0, r0, #2 @ A (no unaligned access fault) + orr r0, r0, #1 << 22 @ U (v6 unaligned access model) + mcr p15, 0, r0, c1, c0, 0 @ write SCTLR + b __armv4_mmu_cache_on + __arm926ejs_mmu_cache_on: #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH mov r0, #4 @ put dcache in WT mode @@ -694,6 +703,7 @@ __armv7_mmu_cache_on: bic r0, r0, #1 << 28 @ clear SCTLR.TRE orr r0, r0, #0x5000 @ I-cache enable, RR cache replacement orr r0, r0, #0x003c @ write buffer + bic r0, r0, #2 @ A (no unaligned access fault) #ifdef CONFIG_MMU #ifdef CONFIG_CPU_ENDIAN_BE8 orr r0, r0, #1 << 25 @ big-endian page tables @@ -914,7 +924,7 @@ proc_types: .word 0x0007b000 @ ARMv6 .word 0x000ff000 - W(b) __armv4_mmu_cache_on + W(b) __armv6_mmu_cache_on W(b) __armv4_mmu_cache_off W(b) __armv6_mmu_cache_flush