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 80DCAC433F5 for ; Tue, 4 Oct 2022 07:26:41 +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=i30ul2lXNqmSlsV6cfxbTZCyti+kla24zMFgb2UwYIQ=; b=35i15IWmP7376i mZ1O+cu+gMKaIDcINF11HJb0peejG8XYkSnIcsbICPBGKM1ldtxk3VyrfnofceAP9oPuG4zxLxDU7 zFeZK0Vxn8Y6zrgLcKy7j6GWlwwGOJvVAXfhRoR/7t2cUmLzuwg6+ftWX6n/GYfuCGOj0g5E6r5CT EjdvDjHo1U4WCU9/rMDkunMhex5m4iExtv8Pz1/z8vuEYQcmQFqjA8iTxJCjVYi9sZ1zZ/U4LdtF+ AjfZoKWxdmmlxVWmiZttsxH9+IxwFSa7RRtnq8gxsYT3L+TNjyOShRAJsU23RluHe6+ocbW//eqsd R2nfwzftHh6Yg2nBD+og==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ofcJ2-008k6h-RQ; Tue, 04 Oct 2022 07:25:32 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ofcIy-008k5a-20 for linux-arm-kernel@lists.infradead.org; Tue, 04 Oct 2022 07:25:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=41B+f/42sfK8aPP75DmHTka6nBNpx5mHQBzuCD5X9G0=; b=dNZDpvhdpQ9VnL5sP5ax3HxvxL cOhcDlYIs/ltA3N0/0vn04BZT+BlBwUOovhQauy36uv7xPHdIT45eT09nriN7MXdITDjfch4+SC+3 ROQQvz1dNfQv31Q5BnbrrSaBDXaEha0YxMAARIgKWMJzMDhuQhL1DXv0PPcdWFe0foqSeOaj0Hpzr LCRBI2x3fGJo5Jv3o3f/ZpOjDOxesvibmTaUXke2gLkSG6x/qJ4O6c9rl8EWG4feWcEDtfE+8RTkU ZK/MtXQzblwlbz6hHnXMQKGFBM76b8zWp+x916aqu6fD3KaMiFz7CULDzO8KwlAQUYaQ2P/muRmId NVrQlLkQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:34574) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ofcIk-0007mX-LN; Tue, 04 Oct 2022 08:25:14 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1ofcIf-0004CZ-2I; Tue, 04 Oct 2022 08:25:09 +0100 Date: Tue, 4 Oct 2022 08:25:09 +0100 From: "Russell King (Oracle)" To: Marcin Wojtas Cc: Marek =?iso-8859-1?Q?Beh=FAn?= , pali@kernel.org, Christoph Hellwig , Robin Murphy , Arnd Bergmann , Andre Przywara , Marc Zyngier , Linus Torvalds , Andrew Lunn , Gregory Clement , Greg Kroah-Hartman , iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org Subject: Re: REGRESSION in 6.0-rc7 caused by patch "ARM/dma-mapping: use dma-direct unconditionally" Message-ID: References: <20220930151028.0e518421@dellmb> <630be11f-09ef-02d4-69f7-c7880ae5674c@arm.com> <20220930165234.729ad68c@dellmb> <20220930170205.490f1a6b@dellmb> <20221003073037.GB2108@lst.de> <20221003172533.6dc87184@dellmb> 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-20221004_002528_159867_6C0C491F X-CRM114-Status: GOOD ( 23.27 ) 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 Mon, Oct 03, 2022 at 11:30:31PM +0200, Marcin Wojtas wrote: > I think the DMA_FROM_DEVICE is used rather properly in the RX path of > the driver - the CPU doesn't access the payload afterward. Please look at the bigger picture rather than concentrating on what happens when a packet is received. The issue is that the CPU writes to the buffer prior to handing the buffer over to the hardware, and then the BM reads from the buffer. This is DMA _to_ the device no matter how you look at it. The BM later writes the received packet to the buffer. This is DMA _from_ the device. So, we have DMA in both directions, hence it really is bidirectional, and using DMA_FROM_DEVICE in the RX path _is_ incorrect. Architectures _can_ and _do_ invalidate the data cache when mapping a buffer for DMA_FROM_DEVICE and any writes in the data cache for that buffer will be discarded. If the writes don't hit the data cache, then they will be unaffected by this. IMHO, having read the docs on the buffer manager, the use of DMA_FROM_DEVICE in mvneta in this path is a long-standing bug - it should be bidirectional for the reason I state above - the hardware both reads and writes the buffer that is passed to it, expecting to read data written by the CPU initially. > Another thought - when writing to *buf (memory normal) shouldn't we add a dsb()? That will make no difference to this - this is not about barriers, it's about caches. > I have one overall concern here. On all kinds of A38x-based boards I > worked on, by default, the firmware set all devices (e.g. network, > AHCI, XHCI) on MBUS as fully IO cache coherent - it should be > reflected in the MVNETA_WIN_BASE(w) registers attribute field. Bits > [15:8] should be set to 0x1D (or 0x1E if there is a second DRAM CS > used). Can you please try adding 'dma-coherent;' property under the > 'internal-regs' node? I did notice that there was no dma-coherent markings in DT, which means that the DMA API will assume the device is non-coherent, and cache maintenance will be performed. If it is dma-coherent, then cache maintenance won't be performed, and DT needs to be updated to indicate this. If firmware is making the devices DMA coherent, and it's under firmware control, then shouldn't firmware also be updating the kernel's device tree to indicate how it's configured the hardware coherency? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel