Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751895AbdHaQeu (ORCPT ); Thu, 31 Aug 2017 12:34:50 -0400 Received: from smtprelay.synopsys.com ([198.182.60.111]:35686 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751623AbdHaQet (ORCPT ); Thu, 31 Aug 2017 12:34:49 -0400 From: Alexey Brodkin To: Vineet Gupta CC: "linux-kernel@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" Subject: Re: [PATCH] arc: Flush and invalidate caches on start Thread-Topic: [PATCH] arc: Flush and invalidate caches on start Thread-Index: AQHTImSFFtUehpI7V0KxfIF57RuoqqKehuaAgAAA0QA= Date: Thu, 31 Aug 2017 16:34:29 +0000 Message-ID: <1504197268.3799.8.camel@synopsys.com> References: <20170831142158.27245-1-abrodkin@synopsys.com> <7a5267e3-c012-7bfd-ced2-cfaa3f47524a@synopsys.com> In-Reply-To: <7a5267e3-c012-7bfd-ced2-cfaa3f47524a@synopsys.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.121.8.86] Content-Type: text/plain; charset="utf-8" Content-ID: <1AA90FF34FE45C449D52354E061A7616@internal.synopsys.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v7VGYt6b007434 Content-Length: 1861 Lines: 59 Hi Vineet, On Thu, 2017-08-31 at 09:31 -0700, Vineet Gupta wrote: > On 08/31/2017 07:22 AM, Alexey Brodkin wrote: > > > > This is useful to make sure no stale data exists in caches after bootloaders. > > The worst thing could be some lines of cache were locked in a bootloader > > for example during DDR recalibration and never unlocked. This may lead > > to really unpredictable issues later down the line. > > > > Signed-off-by: Alexey Brodkin > > --- > >   arch/arc/kernel/head.S | 16 ++++++++++++++++ > >   1 file changed, 16 insertions(+) > > > > diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S > > index 8b90d25a15cc..04e28b664183 100644 > > --- a/arch/arc/kernel/head.S > > +++ b/arch/arc/kernel/head.S > > @@ -34,6 +34,10 @@ > >   #endif > >    sr r5, [ARC_REG_IC_CTRL] > >    > > + ; Invalidate entire I$ > > + mov r5, 1 > > + sr r5, [ARC_REG_IC_IVIC] > > + > >   1: > >    lr r5, [ARC_REG_DC_BCR] > >    breq    r5, 0, 1f ; D$ doesn't exist > > @@ -46,6 +50,18 @@ > >   #endif > >    sr r5, [ARC_REG_DC_CTRL] > >    > > + ; Flush entire D$ > > + mov r5, 1 > > + sr r5, [ARC_REG_DC_FLSH] > > + ; Wait for flush operation to complete > > +1: > > + lr r5, [ARC_REG_DC_CTRL] > > + bbit1 r5, DC_CTRL_FLUSH_STATUS, 1b > > + > > + ; Invalidate entire D$ > > + mov r5, 1 > > + sr r5, [ARC_REG_DC_IVDC] > > + > > AFAIK uboot already flushes the caches before handing control over to kernel - so  > why do we need it here. > If uboot is locking lines, it needs to fix that and not penalize the general case  > with or w/o uboot ! U-Boot indeed flushes caches.. but doesn't invalidate them! And only invalidation unlocks locked lines. That indeed should be added in U-Boot but I'd say above stuff doesn't influence a lot code size or execution time while makes system more fool-proof. -Alexey