Messages in this thread | | | Date | Thu, 28 Sep 2023 16:47:07 +0100 | Subject | Re: [PATCH v1 1/1] ARM: Select DMA_DIRECT_REMAP to fix restricted DMA | From | Robin Murphy <> |
| |
On 28/09/2023 1:07 pm, Jim Quinlan wrote: > On Wed, Sep 27, 2023 at 7:10 PM Linus Walleij <linus.walleij@linaro.org> wrote: >> >> Hi Jim, >> >> thanks for your patch! >> >> On Tue, Sep 26, 2023 at 7:52 PM Jim Quinlan <james.quinlan@broadcom.com> wrote: >> >>> Without this commit, the use of dma_alloc_coherent() while >>> using CONFIG_DMA_RESTRICTED_POOL=y breaks devices from working. >>> For example, the common Wifi 7260 chip (iwlwifi) works fine >>> on arm64 with restricted memory but not on arm, unless this >>> commit is applied. >>> >>> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> >> >> (...) >>> + select DMA_DIRECT_REMAP >> >> Christoph invented that symbol so he can certainly >> explain what is missing to use this on ARM. >> >> This looks weird to me, because: >>> git grep atomic_pool_init >> arch/arm/mm/dma-mapping.c:static int __init atomic_pool_init(void) >> kernel/dma/pool.c:static int __init dma_atomic_pool_init(void) >> >> Now you have two atomic DMA pools in the kernel, >> and a lot more than that is duplicated. I'm amazed that it >> compiles at all. >> >> Clearly if you want to do this, surely the ARM-specific >> arch/arm/mm/dma-mapping.c and arch/arm/mm/dma-mapping-nommu.c >> needs to be removed at the same time? >> >> However I don't think it's that simple, because Christoph would surely >> had done this a long time ago if it was that simple. > > Hello Linus, > > Yes, this is the reason I used "RFC" as the fix looked too easy to be viable :-) > I debugged it enough to see that the host driver's > writes to the dma_alloc_coherent() region were not appearing in > memory, and that > led me to DMA_DIRECT_REMAP.
Oh, another thing - the restricted-dma-pool is really only for streaming DMA - IIRC there can be cases where the emergency fallback of trying to allocate out of the bounce buffer won't work properly. Are you also using an additional shared-dma-pool carveout to satisfy the coherent allocations, per the DT binding?
Thanks, Robin.
| |