From patchwork Thu Jul 25 00:27:21 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 2833121 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id E9D28C0319 for ; Thu, 25 Jul 2013 00:27:57 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D490F201FE for ; Thu, 25 Jul 2013 00:27:56 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 97654201F3 for ; Thu, 25 Jul 2013 00:27:55 +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 1V29PM-0004ax-9s; Thu, 25 Jul 2013 00:27:52 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1V29PJ-00035X-Uj; Thu, 25 Jul 2013 00:27:49 +0000 Received: from mail-qe0-f41.google.com ([209.85.128.41]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1V29PH-00034q-61 for linux-arm-kernel@lists.infradead.org; Thu, 25 Jul 2013 00:27:48 +0000 Received: by mail-qe0-f41.google.com with SMTP id b4so20207qen.0 for ; Wed, 24 Jul 2013 17:27:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type:x-gm-message-state; bh=LXG6yFKaxvCnE6LDj0mJecrAeCIU8ywm4npkI3gvKXo=; b=gd/76Jemuw2bG2cap/7FIeJI/1QqBiy76Na1z4/ATmth1gclPIsjaSVqrbxCXJNbH2 bwf9pF8JHYjWceuisABfRV7Foxvi7dl3EL4CfP1Bwm/QNrOG5fCRXFfzXe/eQlDXkTv6 ikob7chx6qdocXif9OkwxIitInH5jXrenZ2HDGb0O6o6VonaqvW6gYs/GvBB5mcR8oEg jM5hDPZSKItJRm8A1S7ueOzpRXTbHyRXcdGIjuEgHGXYCqzGaf8VMO6ru6+rnRQj66ga Yqz841i3d8jOB+jMmbFkdWIoAePbh5BlceGMZhhnH/duE2YsVHkCksapU5wkZ5Mnn/Wd hPww== X-Received: by 10.49.104.72 with SMTP id gc8mr46748265qeb.35.1374712043758; Wed, 24 Jul 2013 17:27:23 -0700 (PDT) Received: from xanadu.home (modemcable044.209-83-70.mc.videotron.ca. [70.83.209.44]) by mx.google.com with ESMTPSA id c4sm12167208qad.0.2013.07.24.17.27.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Jul 2013 17:27:23 -0700 (PDT) Date: Wed, 24 Jul 2013 20:27:21 -0400 (EDT) From: Nicolas Pitre To: Lorenzo Pieralisi Subject: Re: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences In-Reply-To: <20130723163319.GA781@e102568-lin.cambridge.arm.com> Message-ID: References: <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org> <20130718150408.GB2655@localhost.localdomain> <20130718180323.GC2655@localhost.localdomain> <20130719102844.GA3746@localhost.localdomain> <20130719105907.GB27389@e102568-lin.cambridge.arm.com> <20130723104352.GA3023@localhost.localdomain> <20130723163319.GA781@e102568-lin.cambridge.arm.com> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 X-Gm-Message-State: ALoCoQmcvzXC++QN09ShBurQaeG4VUnjr7uMYIrcmoR5AFNRe56VkaFtRexZnsUO6DZAHHvfVjYp X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130724_202747_296080_A204AD57 X-CRM114-Status: GOOD ( 32.45 ) X-Spam-Score: -2.6 (--) Cc: Jon Medhurst , Russell King - ARM Linux , Pawel Moll , "patches@linaro.org" , Sudeep KarkadaNagesha , Achin Gupta , Olof Johansson , Dave P Martin , "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 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, 23 Jul 2013, Lorenzo Pieralisi wrote: > On Tue, Jul 23, 2013 at 01:28:16PM +0100, Nicolas Pitre wrote: > > [...] > > > > > + * - The CPU is obviously no longer coherent with the other CPUs. > > > > + * > > > > + * Further considerations: > > > > + * > > > > + * - This relies on the presence and behavior of the AUXCR.SMP bit as > > > > + * documented in the ARMv7 TRM. Vendor implementations that deviate from > > > > > > Sorry to be pedantic here, but there is no "ARMv7 TRM". The SMP bit is > > > not part of ARMv7 at all. > > > > Well, I just copied Lorenzo's words here, trusting he knew more about it > > than I do. > > > > > Also, it seems that A9 isn't precisely the > > > same: two ACTLR bits need to be twiddled. R-class CPUs are generally > > > not the same either. > > If you mean the ACTLR.FW bit in A9, A5, and R7, then, IIRC, we do not need to > clear it, clearing the SMP bit is enough. > > See, Dave has a point, there is no explicit "unified v7 TRM disable > clean and exit coherency procedure" even though the designers end goal is to > have one and that's the one you wrote. The code you posted is perfectly ok on > all v7 implementations in the kernel I am aware of, I stand to be corrected > but to the best of my knowledge that's the case. OK, I'm removing allusion to an ARMv7 TRM from the comment. > > > This is why I preferred to treat the whole sequence as specific to a > > > particular CPU implementation. The similarity between A7 and A15 > > > might be viewed as a happy coincidence (it also makes life easier in > > > big.LITTLE land). > > > > Fair enough. > > I disagree on the happy coincidence but the point is taken. I am not > sure about what we should do, but I reiterate my point, the sequence as > it stands is OK on all NS v7 implementations I am aware of. We can add > macros to differentiate processors when we need them, but again that's > just my opinion, as correct as it can be. I tend to prefer that as well. "In theory, practice and theory are equivalent, but in practice they're not" So if in _practice_ all the ARMv7 implementations we care about are OK with the above, then I don't see why we couldn't call it v7_*. Here's the portion of the patch that I just changed. All the rest stayed the same. What do you think? Nicolas --- a/arch/arm/include/asm/cacheflush.h +++ b/arch/arm/include/asm/cacheflush.h @@ -436,4 +436,38 @@ static inline void __sync_cache_range_r(volatile void *p, size_t size) #define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr)) #define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr)) +/* + * Disabling cache access for one CPU in an ARMv7 SMP system is tricky. + * To do so we must: + * + * - Clear the SCTLR.C bit to prevent further cache allocations + * - Flush the desired level of cache + * - Clear the ACTLR "SMP" bit to disable local coherency + * + * ... and so without any intervening memory access in between those steps, + * not even to the stack. + * + * WARNING -- After this has been called: + * + * - No ldrex/strex (and similar) instructions must be used. + * - The CPU is obviously no longer coherent with the other CPUs. + * - This is unlikely to work as expected if Linux is running non-secure. + */ +#define v7_exit_coherency_flush(level) \ + asm volatile( \ + "mrc p15, 0, r0, c1, c0, 0 @ get SCTLR \n\t" \ + "bic r0, r0, #"__stringify(CR_C)" \n\t" \ + "mcr p15, 0, r0, c1, c0, 0 @ set SCTLR \n\t" \ + "isb \n\t" \ + "bl v7_flush_dcache_"__stringify(level)" \n\t" \ + "clrex \n\t" \ + "mrc p15, 0, r0, c1, c0, 1 @ get ACTLR \n\t" \ + "bic r0, r0, #(1 << 6) @ disable local coherency \n\t" \ + "mcr p15, 0, r0, c1, c0, 1 @ set ACTLR \n\t" \ + "isb \n\t" \ + "dsb " \ + /* The clobber list is dictated by the call to v7_flush_dcache_* */ \ + : : : "r0","r1","r2","r3","r4","r5","r6","r7", \ + "r9","r10","r11","lr","memory" ) + #endif