Messages in this thread | | | Date | Tue, 30 Aug 2022 10:48:08 +0100 | Subject | Re: [PATCH 0/3] More ARM DMA ops cleanup | From | Robin Murphy <> |
| |
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.
Thanks, Robin.
> 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. > > >
| |