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 13CB2C54EE9 for ; Wed, 7 Sep 2022 09:12:45 +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=Fn+plDHfV4fb1WiDUVwnAiTX0PB6ZicULyW7voyxRNg=; b=fTgvH5frMDGkR/ xJSYq/3QuCGmxcYEPQM+WMpCHTMysVfhRRg5PmO8oHBsayNesGLZMa3+gM8uMgyF7emnjtlG82w3j Qw5pbJnCjTv1YUn79XX3Ku+P1kY0p5G3EaG7OfN9soMevlCCHzbHffuxUBQnT0U6IH2s6TdMJoD2Z IHo8lqp7mgYPTB8O4Q+ZKPKyuUcmt3FkSosPZWB0deTc+hRl4Rjq0V43BKSYAKVqL1O580bYvLC7v sOEUKp3mkjJERWlQAUo3bG2YD9F5Tu818ubrnsd+fw6KJ3kkVtAH+KJxPOADpdrBV/Mk2I6jXHebE zuYKaRKOooisjpgE4Uhg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVr5u-004hkO-I6; Wed, 07 Sep 2022 09:11:39 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVqxj-004cUI-PZ for linux-arm-kernel@lists.infradead.org; Wed, 07 Sep 2022 09:03:13 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id C0BF868AFE; Wed, 7 Sep 2022 11:03:06 +0200 (CEST) Date: Wed, 7 Sep 2022 11:03:05 +0200 From: Christoph Hellwig To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Mark Rutland , Robin Murphy , Christoph Hellwig , Ard Biesheuvel Subject: Re: [PATCH] arm64: dma: Drop cache invalidation from arch_dma_prep_coherent() Message-ID: <20220907090305.GA30704@lst.de> References: <20220823122111.17439-1-will@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220823122111.17439-1-will@kernel.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220907_020312_047986_965E8CBC X-CRM114-Status: GOOD ( 17.16 ) 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 Tue, Aug 23, 2022 at 01:21:11PM +0100, Will Deacon wrote: > arch_dma_prep_coherent() is called when preparing a non-cacheable region > for a consistent DMA buffer allocation. Since the buffer pages may > previously have been written via a cacheable mapping and consequently > allocated as dirty cachelines, the purpose of this function is to remove > these dirty lines from the cache, writing them back so that the > non-coherent device is able to see them. Yes. > I'm slightly wary about this change as other architectures seem to do > clean+invalidate here, but I'd like to hear what others think in any > case. If arm64 is fine with having clean but present cachelines when creating an uncached mapping for a cache line, the invalidate is not required. But isn't it better for the cache if these by definition useless cachelines get evicted? My biggest concern here is that we're now moving from consolidating these semantics in all the different architectures to different ones, making a centralization of the policies even harder. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel