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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5716CC54EE9 for ; Thu, 8 Sep 2022 13:28:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=rZFFuQEsqVdRTAYquL3oDbDxq4gaWp5ryjO6nH7RTKA=; b=pa+WZZ9Jl4OEsz NicacxCNeNuRX+6beeBGP13+KROOyu2VXIBGWqILQjNhuk9+XFO8yVm4ap2tbkyL39aDnBjTvduMb Xchhy+Q62fSEGLHi047WnSiqbIF5S9Gp48lvSLfKZcXUBNhuMVgx8OqPvifmwZTlexbr5hFjEfUjf Rj25G+YPVJPGqNAysbV3b9v1CCez4F0rYPu+4i1J5XEGvS0t9p3pXD0OtiChrg/VKVMAWxnYXs8y2 V1DF6hmXHmvxfJcHiRlLRCgQPtw8SE+xYp90di1DCc/KwWTXnRYmrQDUGYGpTi68UtZGzRL98DUFS 6078nWY19xcE+oy/CAWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oWHZ5-003oZc-Ge; Thu, 08 Sep 2022 13:27:31 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oWHZ1-003oTw-Q7 for linux-arm-kernel@lists.infradead.org; Thu, 08 Sep 2022 13:27:29 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7286DB820FC; Thu, 8 Sep 2022 13:27:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79F67C433C1; Thu, 8 Sep 2022 13:27:23 +0000 (UTC) Date: Thu, 8 Sep 2022 14:27:19 +0100 From: Catalin Marinas To: Robin Murphy Cc: Will Deacon , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, Mark Rutland , Ard Biesheuvel Subject: Re: [PATCH] arm64: dma: Drop cache invalidation from arch_dma_prep_coherent() Message-ID: References: <20220823122111.17439-1-will@kernel.org> <20220907090305.GA30704@lst.de> <5d856574-4cd7-70d0-adcb-3e284fef315f@arm.com> <20220907162543.GA30558@willie-the-truck> <6dfd53a1-ce24-086d-1ce6-093d48b033da@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220908_062728_015623_5A9E5818 X-CRM114-Status: GOOD ( 24.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Thu, Sep 08, 2022 at 02:02:13PM +0100, Catalin Marinas wrote: > On Thu, Sep 08, 2022 at 12:32:42PM +0100, Robin Murphy wrote: > > On 2022-09-08 11:32, Catalin Marinas wrote: > > > The architecture requires invalidate or clean while also stating that > > > clean+invalidate can be used instead, so I don't think there's much to > > > justify. From the mismatched attributes section: > > > > > > 1. If the mismatched attributes for a memory location all assign the > > > same shareability attribute to a Location that has a cacheable > > > attribute, > > > > This is not describing our case, though. We do have a cacheable attribute in > > at least one alias, but the shareability is *not* the same across all > > aliases, therefore at face value it clearly does not apply. > > From the CPU perspective, both the cacheable and non-cacheable aliases > have the same inner shareable attribute. The device accessing the buffer > presumably should use the same shareability attributes. In the worst > case it's outer shareable but on most implementations the inner and > outer shareability domains are the same. Ah, so you are referring to this paragraph: The shareability field is only relevant if the memory is a Normal Cacheable memory type. All Device and Normal Non-cacheable memory regions are always treated as Outer Shareable, regardless of the translation table shareability attributes. I think so far we've ignored this case and I'm not aware hardware that would break coherency here. There's a theoretical risk that some system level cache only resides in the outer shareable domain and any cache maintenance on the inner shareable alias does not affect it. IIRC we have another case where the architecture requires the inner and outer shareable domains to be the same (a fairly recent update w.r.t. FWB). We could ask the architects to clarify the mismatched aliases to include the outer vs inner case here. But if you want the same attributes, we can change the Linux linear mapping to outer shareable. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel