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: 18554 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-yh0-f69.google.com (mail-yh0-f69.google.com [209.85.213.69]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 29D4C25E5F for ; Thu, 25 Jul 2013 00:27:26 +0000 (UTC) Received: by mail-yh0-f69.google.com with SMTP id b12sf1182423yha.8 for ; Wed, 24 Jul 2013 17:27:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:x-forwarded-to:x-forwarded-for:delivered-to:date:from :to:cc:subject:in-reply-to:message-id:references:user-agent :mime-version:x-gm-message-state:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :x-google-group-id:list-post:list-help:list-archive:list-unsubscribe :content-type; bh=LXG6yFKaxvCnE6LDj0mJecrAeCIU8ywm4npkI3gvKXo=; b=Kx7wy/tFJ85ZTSqhqXPf06YSXhd/4RXJSKfCZLsruMdK4GwhmZJ7OzOFcSzlDfBVIR cjRuOkFfplruOnsAB2ns4Vy/zRWop35S2lwj8g/pGdlYm7pvvtoVYzXrFVjWCGWOYVAo jYh3hu00CBOX2LUrmeavGc7xra59/qhLtLI2kFeX0HDx05dBqaIMRKePZofbYLJGCdUL P0NTpPXCFPM0HTnKR6u0x6a5csGVioOHYD+B69AZqrvJUDS5GTyXpRJMRF9W/ZxrpB9f jpJHqoWPMAtxD80PnXexHcHljJfEAjAlKp0XkhSFQiFnnGLeFFWc4E7tg/JQIF7X1bma fGbQ== X-Received: by 10.236.120.232 with SMTP id p68mr22429716yhh.43.1374712045408; Wed, 24 Jul 2013 17:27:25 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.49.26.234 with SMTP id o10ls460216qeg.27.gmail; Wed, 24 Jul 2013 17:27:25 -0700 (PDT) X-Received: by 10.52.178.10 with SMTP id cu10mr13792490vdc.8.1374712045292; Wed, 24 Jul 2013 17:27:25 -0700 (PDT) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx.google.com with ESMTPS id sj10si11229997vdc.144.2013.07.24.17.27.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 17:27:25 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.212.45 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.212.45; Received: by mail-vb0-f45.google.com with SMTP id p14so25529vbm.18 for ; Wed, 24 Jul 2013 17:27:25 -0700 (PDT) X-Received: by 10.52.27.172 with SMTP id u12mr13491091vdg.64.1374712045034; Wed, 24 Jul 2013 17:27:25 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patches@linaro.org Received: by 10.58.165.8 with SMTP id yu8csp53083veb; Wed, 24 Jul 2013 17:27:24 -0700 (PDT) X-Received: by 10.49.107.105 with SMTP id hb9mr25248064qeb.74.1374712044287; Wed, 24 Jul 2013 17:27:24 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by mx.google.com with ESMTPS id bd4si15993123qeb.20.2013.07.24.17.27.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 17:27:24 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.216.45 is neither permitted nor denied by best guess record for domain of nicolas.pitre@linaro.org) client-ip=209.85.216.45; Received: by mail-qa0-f45.google.com with SMTP id l18so1710713qak.4 for ; Wed, 24 Jul 2013 17:27:23 -0700 (PDT) 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 cc: Dave P Martin , Jon Medhurst , Russell King - ARM Linux , Pawel Moll , "patches@linaro.org" , Sudeep KarkadaNagesha , Achin Gupta , Olof Johansson , "linux-arm-kernel@lists.infradead.org" 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: ALoCoQnsQpP826ZHNmd6TjyxHn0EpZsm6nRzfoGeWTo6ITJqD4gxgCtLMvt8tx1dbHp21ZRb0EEC X-Original-Sender: nicolas.pitre@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.212.45 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Precedence: list Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org List-ID: X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , 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