From patchwork Mon Mar 17 21:54:42 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 3846421 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 ACE8CBF540 for ; Mon, 17 Mar 2014 21:55:45 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D282A201FA for ; Mon, 17 Mar 2014 21:55:44 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BD214201F5 for ; Mon, 17 Mar 2014 21:55:43 +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 1WPfVB-0006kC-30; Mon, 17 Mar 2014 21:55:21 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WPfV8-0008Bn-K1; Mon, 17 Mar 2014 21:55:18 +0000 Received: from relais.videotron.ca ([24.201.245.36]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WPfV6-0008BB-Ox for linux-arm-kernel@lists.infradead.org; Mon, 17 Mar 2014 21:55:17 +0000 MIME-version: 1.0 Received: from yoda.home ([66.130.143.177]) by VL-VM-MR001.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0N2L00M28OV79BB1@VL-VM-MR001.ip.videotron.ca> for linux-arm-kernel@lists.infradead.org; Mon, 17 Mar 2014 17:54:43 -0400 (EDT) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTPSA id EDC3D2DA05FA; Mon, 17 Mar 2014 17:54:42 -0400 (EDT) Date: Mon, 17 Mar 2014 17:54:42 -0400 (EDT) From: Nicolas Pitre To: Russell King - ARM Linux Subject: Re: PL310 errata workarounds In-reply-to: <20140317211455.GM21483@n2100.arm.linux.org.uk> Message-id: References: <20140314144835.GP21483@n2100.arm.linux.org.uk> <20140314150110.GQ21483@n2100.arm.linux.org.uk> <20140316115207.GW21483@n2100.arm.linux.org.uk> <20140317153738.GB21483@n2100.arm.linux.org.uk> <20140317172943.GI24070@arm.com> <20140317194440.GG21483@n2100.arm.linux.org.uk> <20140317211455.GM21483@n2100.arm.linux.org.uk> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140317_175516_841653_05DDB549 X-CRM114-Status: GOOD ( 24.56 ) X-Spam-Score: -1.2 (-) Cc: Catalin Marinas , Will Deacon , Santosh Shilimkar , "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, T_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 Mon, 17 Mar 2014, Russell King - ARM Linux wrote: > On Mon, Mar 17, 2014 at 05:09:46PM -0400, Nicolas Pitre wrote: > > L2 is normally a per cluster resource. It is flushed by the last man > > standing when no other CPUs might contend for the L2 controller. And if > > the outer cache is shared by multiple clusters then some additional > > handling (such as "last cluster standing") would need to be implemented. > > > > Clearly this outer_cache_flush() call is just a hint if someone were to > > copy that file to write their own backend. If it is causing problems > > then it should just be removed altogether. No platforms with MCPM that > > I know of have an actual outer cache at the moment. And certainly not > > the platform where dcscb.c is used. > > This sounds to me like an invitation to kill it :) Killing it off > would be good, though maybe a comment should be left behind at this > site? > > As you're the most familiar with this code, I'd prefer to commit a > patch from you rather than just deleting the reference myself. OK, what about the following: ----- >8 Subject: ARM: dcscb.c: remove actual call to outer_flush_all() Strictly speaking this call is a no-op on the platform where dcscb.c is used since it only has architected caches. The call was there as a hint to people who would be inspired by this code to write their own backend but the hint might not always be correct. For example, if a PL310 were to be used this wouldn't be safe to call the regular outer_flush_all() anyway as it makes use of atomic instructions for locking which cannot be assumed to still be operational after v7_exit_coherency_flush() has returned. Given no other CPUs (in the cluster) should be running at that point then standard concurrency concerns wouldn't apply. So let's simply kill this call for now and enhance the existing comment. Signed-off-by: Nicolas Pitre diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c index 14d4996887..e717515999 100644 --- a/arch/arm/mach-vexpress/dcscb.c +++ b/arch/arm/mach-vexpress/dcscb.c @@ -137,11 +137,10 @@ static void dcscb_power_down(void) v7_exit_coherency_flush(all); /* - * This is a harmless no-op. On platforms with a real - * outer cache this might either be needed or not, - * depending on where the outer cache sits. + * A full outer cache flush could be needed at this point + * on platforms with a real outer cache. This might either + * be needed or not depending on where the outer cache sits. */ - outer_flush_all(); /* * Disable cluster-level coherency by masking