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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ABD33ECAAD4 for ; Thu, 1 Sep 2022 02:04:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232753AbiIACEg (ORCPT ); Wed, 31 Aug 2022 22:04:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232487AbiIACEd (ORCPT ); Wed, 31 Aug 2022 22:04:33 -0400 Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F20F5122BE4 for ; Wed, 31 Aug 2022 19:04:32 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id r6so12417539qtx.6 for ; Wed, 31 Aug 2022 19:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=saPMMzuK3Ho4SUDDsCSKY8/njcHtrQrgxH2RFe9bLtY=; b=K9IDTvUvJFqhOsyyJMTui8J3nK54HCRWlFQ0E2R2CIXsDOGaEPoLRfixcVoGQ42Nai 8fojjLOAuj6zDPY/I0YRch7xQz4Rjri5/GpCJhlQlouT66IK0PIxX3Md1KE64GytB5PJ NMw/7TQlKB78JKfav0Xn8sxyA/bNwKSndshAJd8S9Cv9sjTVDv6bYkuju2EuyZFFmWk6 NVeNoS7u5cJ8d9Hug0VoEnXI3X1Le8ppuHPthxxjbSX+2mIBm3yUlxKNUeiHRKxPAmO4 FIDZ0N5upArZ39fzCWiKhABpoEqStPHFtMLfTFP+Cr7hl7rIrf8hgb/uxkTzBGj2vRTe Pe5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=saPMMzuK3Ho4SUDDsCSKY8/njcHtrQrgxH2RFe9bLtY=; b=oLYpUGRoUxe1RzBdMhqHt7VR6qPYdeP1tCE0ZdHf9caO8dD41rM3B401gU1ZxaR4gX v5XBuZIJIzGn5X45D45K+6Gv5g0pYLYPvXrUqyztVMh2hzhIPLnj99duSfwoqehuIgcp gHd/8DK1QSAF+RFsnbCvIfMH7WBnhJf2/yphmcItqAvQspvswQeW3+U+UQwPUv6zxDM0 h4AzA2EevC1wxUebKmBLKIxIAuAOnKEy7BEo4Sl1IgWkuQRi34YWnPlKpJctutmjUy5p 8a6eyXegWlKkg7775KvYwn6AlA1tGRB9ci2iZUeEGwiCytTjKNBZfh0OyfjRqAbDAKo0 vf9A== X-Gm-Message-State: ACgBeo3+5H8lsmPTq32LJQ6uBJ9D+YkY66rumhlOukj5UgsU1rsbsVq6 iC/g0q8mu+Nd1rfeayIlQyPEYzvh2453k+mPSBj0hw== X-Google-Smtp-Source: AA6agR6R6a9y6NVWlb8HXU/ybD+Q0Mnf5IJ7JiD8dpmIgIz7qgchladeggSJF9076AcPv4IxW6Y7O+QrOHrrGSgKZzw= X-Received: by 2002:ac8:5853:0:b0:343:7b95:96ff with SMTP id h19-20020ac85853000000b003437b9596ffmr22411999qth.386.1661997872094; Wed, 31 Aug 2022 19:04:32 -0700 (PDT) MIME-Version: 1.0 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> <6cc93088-981e-5c2d-a757-90508455aa42@arm.com> In-Reply-To: <6cc93088-981e-5c2d-a757-90508455aa42@arm.com> From: Yongqin Liu Date: Thu, 1 Sep 2022 10:04:21 +0800 Message-ID: Subject: Re: [PATCH 0/3] More ARM DMA ops cleanup To: Robin Murphy Cc: Christoph Hellwig , linux@armlinux.org.uk, 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Robin On Thu, 1 Sept 2022 at 01:10, Robin Murphy wrote: > > On 2022-08-31 17:41, Yongqin Liu wrote: > > Hi, Robin > > > > On Tue, 30 Aug 2022 at 23:37, 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. > > > > I tried with this method, and found that if I only update for the > > pvr_flush_range > > and the pvr_clean_range functions, the build still could boot to the > > home screen. > > > > but if I update all the pvr_flush_range, pvr_clean_range and > > pvr_invalidate_range > > functions with this method(remove the arm_dma_ops lines and the #ifdef > > __arch64__ lines), > > then a "Unable to handle kernel NULL pointer dereference at virtual > > address 0000003c" > > error is reported like here: http://ix.io/49gu > > > > Not sure if you have any idea from the log, or could you please give > > some suggestions > > on how to debug it. > > Obviously there's almost certainly going to be more work to do on top to > make the newly-exposed codepath actually behave as expected - I was > simply making a general suggestion for a starting point based on looking > at half a dozen lines of code in isolation. > > To restate the point yet again in the hope that it's clear this time, > the DMA ops on ARM are now effectively the same as the DMA ops on arm64, > and will behave the same way. Thanks for confirming again here! > Assuming the driver already works on > arm64, then the aim should be to unify all the ARM and arm64 codepaths > for things that involve the DMA API. Thanks for the suggestion here, I will try to see if I could find anything there. > If you don't understand the code > well enough to do that, please contact Imagination; I don't support > their driver. Will try to contact the maintainer of the PVR source, but as you could guess, it might take quite a long time before it's fixed in the perfect way, and before that I need to have the build continue even with various workarounds based on my limited undersanding:( Thanks again for all the kind help and suggestions! -- Best Regards, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android 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 B4EACECAAD4 for ; Thu, 1 Sep 2022 02:05:46 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=INyUXec06Q9oLklQYSIUsKepwwmw1ADzFs3AKsMr1/s=; b=BUWvvPV8+LD8i+ iRDo3otv7PiwYpZHcO4LXxagHuWkAQuayoc5X4/LqxG/2TOMklNFUj/8UIJQtRphdKo9hXlOJXBTi nUNj+K0FVyQr0Y16+/pz0AHoqBFcY/qeeYItUqC0bAM1v6GQq5sfFPAmQzE91ParSpax53k16XGmZ Mo6XTdeGWqqAXJ6c66KeyiPzYrK1Jc0WDQP8aZy4TsNaHwzxk1Puj8P0kHH7kHlXoLoK56Ny0UTqa Da4eMR1sb0glMSGTFOxffbq6cIwHYMSajLMaErhIKSdrpX4KJsZnij/rHdKfIGt/vU8GUgIsbBbgM M40Pg150oy9qPx0l3R/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTZZP-0096gr-Ic; Thu, 01 Sep 2022 02:04:39 +0000 Received: from mail-qt1-x831.google.com ([2607:f8b0:4864:20::831]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTZZL-0096eV-Dc for linux-arm-kernel@lists.infradead.org; Thu, 01 Sep 2022 02:04:37 +0000 Received: by mail-qt1-x831.google.com with SMTP id c20so12400934qtw.8 for ; Wed, 31 Aug 2022 19:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=saPMMzuK3Ho4SUDDsCSKY8/njcHtrQrgxH2RFe9bLtY=; b=K9IDTvUvJFqhOsyyJMTui8J3nK54HCRWlFQ0E2R2CIXsDOGaEPoLRfixcVoGQ42Nai 8fojjLOAuj6zDPY/I0YRch7xQz4Rjri5/GpCJhlQlouT66IK0PIxX3Md1KE64GytB5PJ NMw/7TQlKB78JKfav0Xn8sxyA/bNwKSndshAJd8S9Cv9sjTVDv6bYkuju2EuyZFFmWk6 NVeNoS7u5cJ8d9Hug0VoEnXI3X1Le8ppuHPthxxjbSX+2mIBm3yUlxKNUeiHRKxPAmO4 FIDZ0N5upArZ39fzCWiKhABpoEqStPHFtMLfTFP+Cr7hl7rIrf8hgb/uxkTzBGj2vRTe Pe5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=saPMMzuK3Ho4SUDDsCSKY8/njcHtrQrgxH2RFe9bLtY=; b=B5VcibeYsVmfet5eS/3JAxG+96a75kUQ/jdsvuv98gb56LwF6KDIcgkVDq8G9bbp5N sMB0eXjTnIgc3fP0WXvxOSc02oQ1APzpUrXphAlZNT5XODzIfJc4VGeI++8OJWNTGZMI j4OzAgkQs4oigPNsw+1NFvTC63kafEFOL7afWv3aPFNzLNtUU/e7qMwM7YvWvR741CXo eY8XaO6OhqaWntJ0oafx3pGRyUADYhCKvQps1/092kO5oQHiQYZx5vhpi98ogIb0ESWC NHIUjVMR4I8m2mXw3SWNevalk4y4dLwXoS2EpuQKciFCslYff3DW0d5uJ2xBJjbdBk14 b0nw== X-Gm-Message-State: ACgBeo2XE+Y442Sl5X+rBftHNGXvKKui9LfUH0SQOiImFCNS5ERBr8qi eqMKin1SW4whd0VFa0boj/ei0EFFlDDLhHWeERKzKw== X-Google-Smtp-Source: AA6agR6R6a9y6NVWlb8HXU/ybD+Q0Mnf5IJ7JiD8dpmIgIz7qgchladeggSJF9076AcPv4IxW6Y7O+QrOHrrGSgKZzw= X-Received: by 2002:ac8:5853:0:b0:343:7b95:96ff with SMTP id h19-20020ac85853000000b003437b9596ffmr22411999qth.386.1661997872094; Wed, 31 Aug 2022 19:04:32 -0700 (PDT) MIME-Version: 1.0 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> <6cc93088-981e-5c2d-a757-90508455aa42@arm.com> In-Reply-To: <6cc93088-981e-5c2d-a757-90508455aa42@arm.com> From: Yongqin Liu Date: Thu, 1 Sep 2022 10:04:21 +0800 Message-ID: Subject: Re: [PATCH 0/3] More ARM DMA ops cleanup To: Robin Murphy Cc: Christoph Hellwig , linux@armlinux.org.uk, 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220831_190435_557914_5350E3F1 X-CRM114-Status: GOOD ( 45.21 ) 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 Hi, Robin On Thu, 1 Sept 2022 at 01:10, Robin Murphy wrote: > > On 2022-08-31 17:41, Yongqin Liu wrote: > > Hi, Robin > > > > On Tue, 30 Aug 2022 at 23:37, 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. > > > > I tried with this method, and found that if I only update for the > > pvr_flush_range > > and the pvr_clean_range functions, the build still could boot to the > > home screen. > > > > but if I update all the pvr_flush_range, pvr_clean_range and > > pvr_invalidate_range > > functions with this method(remove the arm_dma_ops lines and the #ifdef > > __arch64__ lines), > > then a "Unable to handle kernel NULL pointer dereference at virtual > > address 0000003c" > > error is reported like here: http://ix.io/49gu > > > > Not sure if you have any idea from the log, or could you please give > > some suggestions > > on how to debug it. > > Obviously there's almost certainly going to be more work to do on top to > make the newly-exposed codepath actually behave as expected - I was > simply making a general suggestion for a starting point based on looking > at half a dozen lines of code in isolation. > > To restate the point yet again in the hope that it's clear this time, > the DMA ops on ARM are now effectively the same as the DMA ops on arm64, > and will behave the same way. Thanks for confirming again here! > Assuming the driver already works on > arm64, then the aim should be to unify all the ARM and arm64 codepaths > for things that involve the DMA API. Thanks for the suggestion here, I will try to see if I could find anything there. > If you don't understand the code > well enough to do that, please contact Imagination; I don't support > their driver. Will try to contact the maintainer of the PVR source, but as you could guess, it might take quite a long time before it's fixed in the perfect way, and before that I need to have the build continue even with various workarounds based on my limited undersanding:( Thanks again for all the kind help and suggestions! -- Best Regards, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel