From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22078C433DB for ; Fri, 29 Jan 2021 10:55:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 93E2364DDE for ; Fri, 29 Jan 2021 10:55:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93E2364DDE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=TtrcNfNwmmGixyKsIkvmn7cfEsL1SblT7JdY/boZD+s=; b=k7vDKXDfmx9drx80EGwrVw67T kN+0grgBacaJ9UFnr/xjJkqPAPDYVjQchWPTDzvKyPmozkRh9PIjG5qhoCbw/oqPaXS2eWyzf6nZs xUq7vIJVAYYlMskAWNm6sXgI1JeFkAXPvP5/hTJv6182DuKZVe2MOAwzaHyIqoIFkcUvHp15uwTvj 0jtF+q8Eujyd6BDG+9zyPksndTkpGjw2C4eJz8f4vhhIGjrsfl7iyCXvfbKzIkVYYrnGKRqoJaypG kemG1Tut+io+8prg/68KGFF5Sx3iW5AR0LUorM8pd0BHEPrekLa79v8sWZFWiAbcCgzb9fPsEkazt uAunA0j4Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l5RPJ-0006Vu-9M; Fri, 29 Jan 2021 10:53:41 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l5RPH-0006VU-0P for linux-arm-kernel@lists.infradead.org; Fri, 29 Jan 2021 10:53:39 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id A3E5B64E0A for ; Fri, 29 Jan 2021 10:53:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611917617; bh=2eguWoS+j8WID7Dl6rssQTsPDJ9LaV5w6PuA6dlcMdE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=us43O8PKhDjQGgU7GKNONhg33UmMBh0ZWzCOwIZD0N6BqFQhnrsF12pU3cbo4Xr4L swiAbrUHNSd5dAuPXeKbhfWqpo1wiI0JYUJv3NVinFOhB09P7aJf1oiVmEC5cQlcPd rGuld1Hmq4AXbe1lROMu0ZjhWqyD9iKSnL/dnCI31tl4a25MkqS/B5AL5Ou0HENMzx Fk3Zru/fuCDPfpBhEE9SKtpZv8nM+PJMz8oxWyOPC7lOHDzhsrggbOm7GjUto82sK1 2pbDq1P2sXgPbdk+fF5rcQgN8wV+EKNWlOJdlhiQTPA//rDTTi+M0AtwuqTo77kzVo a6RoXMEIeinLQ== Received: by mail-oi1-f170.google.com with SMTP id j25so9451803oii.0 for ; Fri, 29 Jan 2021 02:53:37 -0800 (PST) X-Gm-Message-State: AOAM5331ZViCOVYkIADyN/c8BpFpPALcvG6oB7hDs9zuMEprP3AZiN+m uZs/v17agKdgLM4SCg826YaxBoI9AaIjpkcXylk= X-Google-Smtp-Source: ABdhPJwfjFVUhRiJJlt5Eighu1aVpdF1LbNiuMNARYqtwSbEWFzI0ITxnvZ0S1wlHO1Yq2idx266KGtY6Vx9DNHLRHc= X-Received: by 2002:aca:eb0a:: with SMTP id j10mr2345388oih.4.1611917616900; Fri, 29 Jan 2021 02:53:36 -0800 (PST) MIME-Version: 1.0 References: <20210116032740.873-1-thunder.leizhen@huawei.com> <20210116032740.873-5-thunder.leizhen@huawei.com> <20dac713-25b7-cddf-cc42-69a834487c71@huawei.com> <20210129103340.GW1551@shell.armlinux.org.uk> In-Reply-To: <20210129103340.GW1551@shell.armlinux.org.uk> From: Arnd Bergmann Date: Fri, 29 Jan 2021 11:53:20 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 4/4] ARM: Add support for Hisilicon Kunpeng L3 cache controller To: Russell King - ARM Linux admin X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210129_055339_189570_10C7347E X-CRM114-Status: GOOD ( 34.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree , Arnd Bergmann , Greg Kroah-Hartman , Will Deacon , linux-kernel , Haojian Zhuang , Rob Herring , Wei Xu , "Leizhen \(ThunderTown\)" , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jan 29, 2021 at 11:33 AM Russell King - ARM Linux admin wrote: > > On Fri, Jan 29, 2021 at 11:26:38AM +0100, Arnd Bergmann wrote: > > Another clarification, as there are actually two independent > > points here: > > > > * if you can completely remove the readl() above and just write a > > hardcoded value into the register, or perhaps read the original > > value once at boot time, that is probably a win because it > > avoids one of the barriers in the beginning. The datasheet should > > tell you if there are any bits in the register that have to be > > preserved > > > > * Regarding the _relaxed() accessors, it's a lot harder to know > > whether that is safe, as you first have to show, in particular in case > > any of the accesses stop being guarded by the spinlock in that > > case, and whether there may be a case where you have to > > serialize the memory access against accesses that are still in the > > store queue or prefetched. > > > > Whether this matters at all depends mostly on the type of devices > > you are driving on your SoC. If you have any high-speed network > > interfaces that are unable to do cache coherent DMA, any extra > > instruction here may impact the number of packets you can transfer, > > but if all your high-speed devices are connected to a coherent > > interconnect, I would just go with the obvious approach and use > > the safe MMIO accessors everywhere. > > For L2 cache code, I would say the opposite, actually, because it is > all too easy to get into a deadlock otherwise. > > If you implement the sync callback, that will be called from every > non-relaxed accessor, which means if you need to take some kind of > lock in the sync callback and elsewhere in the L2 cache code, you will > definitely deadlock. Fair enough. I mentioned the sync callback as the reason for using the relaxed accessor in l2x0 in my first reply. Clearly if there was a sync callback here, it would immediately deadlock when calling back into sync() from readl()/writel(). > It is safer to put explicit barriers where it is necessary. > > Also remember that the barrier in readl() etc is _after_ the read, not > before, and the barrier in writel() is _before_ the write, not after. > The point is to ensure that DMA memory accesses are properly ordered > with the IO-accessing instructions. > > So, using readl_relaxed() with a read-modify-write is entirely sensible > provided you do not access DMA memory inbetween. The part I was not sure about is what happens when you have a store to memory immediately before flushing the cache, and there are no barriers inbetween. Is there a possibility for the mmio store to cause the cache to be flushed before the prior memory store has made it into the cache? My guess would be that this cannot happen, but I'm not sure. If the code gets changed to raw_writel(), I think this should be documented next to the actual raw_writel(), explaining either the presence of the absence of such a barrier. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel