Messages in this thread | | | From | Yongqin Liu <> | Date | Thu, 1 Sep 2022 00:41:29 +0800 | Subject | Re: [PATCH 0/3] More ARM DMA ops cleanup |
| |
Hi, Robin
On Tue, 30 Aug 2022 at 23:37, Robin Murphy <robin.murphy@arm.com> 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 <robin.murphy@arm.com> 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.
> 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.
Sorry for that, I am not familiar with the dma part, and just know "dma-direct" from here, will check how "dma-direct" should be used next, and check if there is something wrong in the pvr source code. It would be appreciated if you could suggest some links on "dma-direct" I can study with.
Thanks, Yongqin Liu > > > > > >>> Thanks in advance! > >>> > >>> [1]: https://android-git.linaro.org/kernel/omap-modules.git/tree/pvr/services4/srvkm/env/linux/osfunc.c?h=android-mainline#n4615 > >>> > >>> Thanks, > >>> Yongqin Liu > >>> > >>> On Thu, 21 Apr 2022 at 22:35, Robin Murphy <robin.murphy@arm.com> wrote: > >>>> > >>>> On 2022-04-21 15:13, Christoph Hellwig wrote: > >>>>> On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> Thanks to Christoph's latest series, I'm reminded that, if we're going > >>>>>> to give the ARM DMA ops some cleanup this cycle, it's as good a time as > >>>>>> any to dust off these old patches and add them on top as well. I've > >>>>>> based these on the arm-dma-direct branch which I assume matches the > >>>>>> patches posted at [1]. > >>>>> > >>>>> All these do look sensible to me. But weren't you working on replacing > >>>>> the ARM iommu dma_ops with dma-іommu anyway? > >>>> > >>>> Yes, that's somewhat entangled with the IOMMU bus ops stuff, so I'll > >>>> probably get to the point of having to revisit it in a couple of months > >>>> or so. These patches are off the bottom of that stack from my first > >>>> attempt, where the aim was to make the current ops the same shape first > >>>> so that the switch is then easier to reason about (particularly in terms > >>>> of sounding out any issues with the hooking up of dev->dma_coherent, > >>>> although your series will now be taking most of the load off there). > >>>> > >>>> Cheers, > >>>> Robin. > >>> > >>> > >>> > > > > > >
-- Best Regards, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android
| |