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 839EFECAAA1 for ; Tue, 30 Aug 2022 15:46:09 +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=9orY9gIIur9bF14KFKvYdoXHbXZsmLJOZ+JI6yX7Aoc=; b=PE+9wGed0m1Tlr UauXh33WAtUW7whx6iu6UuoOE7EalVwt8QXN5xfllSIJ2qllkjFjd/zY+QgqrBSpKkl8vfKW/Suic GYBe6LLaB+CuiYNCG3rjSwPWroWpXG3zwXIBSXjPmE/llfNiQqCZI2Dv1JIvLGRCNaMkBiCwb3+md WSTLg+RuC5QtLi5OOMukyyxc46nbaoiMm6P38UW4+DQc46sBFZ3F9MfSaCIInNIwf5lP7C2rIktgQ IuOuB8lcde3iUxfyZDJvo9IX1CiTm3xPbagZyTHo7qCoAnlcZSLRYDRh6lJOKKGFWJOaw+QhJN6eN DNx5/bp3NfNkokK0iuxQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oT3QG-000MwI-R2; Tue, 30 Aug 2022 15:45:04 +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 1oT3Q9-000Mts-BV for linux-arm-kernel@lists.infradead.org; Tue, 30 Aug 2022 15:45:03 +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=0rngN2Nly2Td71lXPLgCZdlPaLmW/RE3t+pErTGRmOg=; b=i4t5QpuE62W/R0OPwt7BoikIOg qkvx7dNlculI+V9fFOnhxHhGQdlLv41mEyF8oVKDElfC+Q5zB9d7RwyKC8608wBCtAY3u+SP8AwYi cBQHSPuPzKWfZ3rVG9OQdabM1xar0TF+Saz+aqxMcjRP1dhktJYGV2g+v3FNGJ/YVr6wAKHLbc5ET Ouk8TMMu5RkOrGmGyGM8spP+M7879Z8CdTP6MH40dsTKCqRiF2eiKYN0PsdCm/uLaGmY9Xn24pECw /xYonHXfHc/hVvL7WuBYeqtq6xLX5ksyZdwMcmY+QuYRqjO6d4grSoP4V60QciZY4ccbpiViteH7S ubQzV0kg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:34004) 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 1oT3Q1-0002z9-S5; Tue, 30 Aug 2022 16:44:49 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1oT3Pw-0001fS-Ub; Tue, 30 Aug 2022 16:44:44 +0100 Date: Tue, 30 Aug 2022 16:44:44 +0100 From: "Russell King (Oracle)" To: Robin Murphy Cc: Yongqin Liu , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com, arnd@kernel.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, "Bajjuri, Praneeth" , Sumit Semwal Subject: Re: [PATCH 0/3] More ARM DMA ops cleanup Message-ID: References: <20220421141300.GC20492@lst.de> <665d2b46-c9e2-2543-cad5-9adf022e4bcb@arm.com> <9ec5ba90-150a-c675-d95b-b13e3a4e9e10@arm.com> <5c617d66-f04b-df26-bf7a-7f479d081ac2@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5c617d66-f04b-df26-bf7a-7f479d081ac2@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220830_084457_418806_6784DC02 X-CRM114-Status: GOOD ( 37.75 ) 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 30, 2022 at 04:36:19PM +0100, Robin Murphy wrote: > On 2022-08-30 16:19, Yongqin Liu wrote: > > Hi, Robin > > > > Thanks for the kind reply! > > > > On Tue, 30 Aug 2022 at 17:48, Robin Murphy wrote: > > > > > > On 2022-08-27 13:24, Yongqin Liu wrote: > > > > Hi, Robin, Christoph > > > > > > > > With the changes landed in the mainline kernel, > > > > one problem is exposed with our out of tree pvr module. > > > > Like the source here[1], arm_dma_ops.sync_single_for_cpu is called in > > > > the format like the following: > > > > arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart, > > > > DMA_FROM_DEVICE); > > > > > > > > Not sure if you could give some suggestions on what I should do next > > > > to make the pvr module work again. > > > > > > Wow, that driver reinvents so many standard APIs for no apparent reason > > > it's not even funny. > > > > > > Anyway, from a brief look it seemingly already knows how to call the DMA > > > API semi-correctly, so WTF that's doing behind an #ifdef, who knows? > > > However it's still so completely wrong in general - fundamentally broken > > > AArch64 set/way cache maintenance!? - that it looks largely beyond help. > > > "Throw CONFIG_DMA_API_DEBUG at it and cry" is about the extent of > > > support I'm prepared to provide for that mess. > > > > For the moment, I do not care about the AArch64 lines, like if we only > > say the following two lines: > > arm_dma_ops.sync_single_for_device(NULL, pStart, pEnd - pStart, > > DMA_TO_DEVICE); > > arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart, > > DMA_FROM_DEVICE); > > > > Could you please give some suggestions for that? > > Remove them. Then remove the #ifdef __arch64__ too, since the code under > there is doing a passable impression of generic DMA API usage, as long as > one ignores the bigger picture. > > arm64 already uses dma-direct. To say you don't care about the arm64 code > when asking how to deal with ARM having now been converted to use dma-direct > as well is supremely missing the point. It should also be pointed out that this culture of bodging around the DMA API by graphics drivers is entirely their own problem. If they used the proper interfaces that the kernel provides (like the DMA API) rather than thinking "I need to flush the caches in such-and-such a way here" so I need to find a function somewhere in the kernel's interfaces that I can get to in order to achieve that, and I don't care how that's done then maybe their code wouldn't keep breaking. This is really not our problem to solve. This is not limited to just PVR. I've seen it with other stuff as well, and it's the reason I was not in favour of exposing the dmac_* functions that we have in arch/arm/mm - which are part of the DMA API implementation, being moved into a header file. One can see from PVR that they also made use of these before I intentionally hid them from driver modules. Basically, out of tree graphics drivers will bodge around to get access to the specific cache manangement that they want to use - even if it means abusing stuff that may mean that their crappy drivers break when we make later changes. As I say, it's entirely _their_ problem to solve if they don't want to use our official interfaces. Or, they can decide to use our official interfaces, which would be nice. -- 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