| Message ID | cover.1650539846.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | More ARM DMA ops cleanup | expand |
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?
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.
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.
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.
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. > > >
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? 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. > > > > > >
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. 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. Robin. > > 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. >>> >>> >>> > > >
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 <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. > > 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.
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. > >>> > >>> > >>> > > > > > >
On 2022-08-31 17:41, Yongqin Liu wrote: > 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. 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. 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. If you don't understand the code well enough to do that, please contact Imagination; I don't support their driver. Thanks, Robin.
Hi, Robin On Thu, 1 Sept 2022 at 01:10, Robin Murphy <robin.murphy@arm.com> wrote: > > On 2022-08-31 17:41, Yongqin Liu wrote: > > 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. > > 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!