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 CC2AFC3F6B0 for ; Wed, 24 Aug 2022 22:01:40 +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=GArsFmOvxYzCQGDFv+1dbXv6/hy22C4YyjLmD4Qeu4A=; b=i2gYVbHM/gYyxv V4p8eBYN5G5aUkg0OHgN+pKa5RIMg0lCJuz30zZt6pv4kB2dzMO2fEo4BqRnhfL7F7ownmTBv160/ a1s+722bUQidSmGIvwaIUa7tPfAAKVB5SkLbz8JeIEPMZdRkxEt4XgYRPpIHSy+8+aGRTX0Eqry/M iDDOz7F/H/S2htANK5ZfvU1Ic98N3mChbxhbLSywzkBiYVYWPjGEltdmzgZ9taK2ax5KZTZb2DFuB 320f8i3Mo2hAWE6cUM9/N9fpht3oX3AHtMrUPUUJtT6B1YKF8hSreqVe+1y/DNGcHSa8Ds9PTGtsP 61Kq/gDqnw7BAbXJhSrQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oQyPt-001z4l-MR; Wed, 24 Aug 2022 22:00:05 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oQyPq-001z1l-I8 for linux-arm-kernel@lists.infradead.org; Wed, 24 Aug 2022 22:00:04 +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 dfw.source.kernel.org (Postfix) with ESMTPS id BE3E36192E; Wed, 24 Aug 2022 22:00:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC8C5C433C1; Wed, 24 Aug 2022 21:59:58 +0000 (UTC) Date: Wed, 24 Aug 2022 23:00:02 +0100 From: Catalin Marinas To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Mark Rutland , Robin Murphy , Christoph Hellwig , Ard Biesheuvel Subject: Re: [PATCH] arm64: dma: Drop cache invalidation from arch_dma_prep_coherent() Message-ID: References: <20220823122111.17439-1-will@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220823122111.17439-1-will@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220824_150002_683286_0E8939AC X-CRM114-Status: GOOD ( 23.53 ) 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. > > On arm64, this operation can be achieved with a clean to the point of > coherency; a subsequent invalidation is not required and serves little > purpose in the presence of a cacheable alias (e.g. the linear map), > since clean lines can be speculatively fetched back into the cache after > the invalidation operation has completed. > > Relax the cache maintenance in arch_dma_prep_coherent() so that only a > clean, and not a clean-and-invalidate operation is performed. > > Cc: Catalin Marinas > Cc: Mark Rutland > Cc: Robin Murphy > Cc: Christoph Hellwig > Cc: Ard Biesheuvel > Signed-off-by: Will Deacon > --- > > 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. Given that we still have the cacheable alias around, I don't see much point in the invalidation. So: Reviewed-by: Catalin Marinas (I was wondering why not just invalidate without clean but it could be that the allocated memory was zeroed and we want that to make it to the PoC) -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel