CMA Memory Allocation

[Wobaffet]

Hello, We've been working on our custom board with i.MX8MP running with 512MiB LPDDR4 RAM. Our CMA config for the DT is below:

                linux,cma { 
                        compatible = "shared-dma-pool";
                        reusable;
                        size = <0 0x8000000>;
                        alloc-ranges = <0 0x40000000 0 0x20000000>;
                        linux,cma-default;
                };

At the Boot, I get the log that cma is initilized but the DMA-API warning is thrown. Everything seems to be normal but cma_alloc() tries to allocate from non defined ranges! Can you please check what could be wrong? 

Mar 03 09:49:19 imx8mp-lpddr4-evk kernel: Reserved memory: created CMA memory pool at 0x0000000058000000, size 128 MiB
Mar 03 09:49:19 imx8mp-lpddr4-evk kernel: OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool

Mar 03 09:49:19 imx8mp-lpddr4-evk kernel: On node 0, zone DMA: 8192 pages in unavailable ranges
Mar 03 09:49:19 imx8mp-lpddr4-evk kernel: cma: dma_contiguous_reserve(limit 60000000)

Mar 03 09:49:19 imx8mp-lpddr4-evk kernel: of_reserved_mem_lookup() returned NULL

Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: cma: cma_alloc(cma 000000006b59b19e, count 1000, align 8)
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: cma: cma_alloc(): memory range at 0000000063e3b33f is busy, retrying
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: cma: cma_alloc(): memory range at 0000000052d254b4 is busy, retrying
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: cma: cma_alloc(): memory range at 000000003e24e32e is busy, retrying
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: cma: cma_alloc(): returned 0000000006605662
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: ------------[ cut here ]------------
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: DMA-API:  (null): mapping sg segment longer than device claims to support [len=4096000] [max=65536]
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: WARNING: CPU: 2 PID: 423 at kernel/dma/debug.c:1160 debug_dma_map_sg+0x2b0/0x350
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: Modules linked in:
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: CPU: 2 PID: 423 Comm: weston Not tainted 6.1.36+g50616ee8f18b #1
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: Hardware name: NXP i.MX8MPlus EVK board (DT)
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: pc : debug_dma_map_sg+0x2b0/0x350
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: lr : debug_dma_map_sg+0x2b0/0x350
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: sp : ffff80000aacb910
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: x29: ffff80000aacb910 x28: 0000000000010000 x27: ffff00000c2b8e80
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: x26: ffffffffffffffff x25: ffff000010942d00 x24: 0000000000000000
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: x23: ffff800009d58be8 x22: 0000000000000001 x21: 0000000000000001
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: x20: 0000000000000000 x19: ffff80000aacbad0 x18: 0000000000000006
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: x17: 7420736d69616c63 x16: 2065636976656420 x15: 6e61687420726567
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: x14: 6e6f6c20746e656d x13: ffff800009d72588 x12: 0000000000000504
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: x11: 00000000000001ac x10: ffff800009dca588 x9 : ffff800009d72588
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: x8 : 00000000ffffefff x7 : ffff800009dca588 x6 : 80000000fffff000
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: x5 : ffff000015ecea18 x4 : ffff000015ecea18 x3 : ffff000015ed1c20
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000118c2c40
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: Call trace:
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  debug_dma_map_sg+0x2b0/0x350
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  __dma_map_sg_attrs+0xa0/0x110
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  dma_map_sgtable+0x28/0x44
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  drm_gem_map_dma_buf+0x5c/0xd4
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  __map_dma_buf+0x2c/0xa0
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  dma_buf_map_attachment+0xa0/0x130
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  dma_buf_ioctl+0x27c/0x650
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  __arm64_sys_ioctl+0xac/0xf0
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  invoke_syscall+0x48/0x114
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  el0_svc_common.constprop.0+0xcc/0xec
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  do_el0_svc+0x2c/0xd0
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  el0_svc+0x2c/0x84
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  el0t_64_sync_handler+0xf4/0x120
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel:  el0t_64_sync+0x18c/0x190
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: ---[ end trace 0000000000000000 ]---
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: cma: cma_alloc(cma 000000006b59b19e, count 1000, align 8)
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: cma: cma_alloc(): returned 00000000a3311193
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: cma: cma_alloc(cma 000000006b59b19e, count 1000, align 8)
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: cma: cma_alloc(): memory range at 00000000a7cbb8b6 is busy, retrying
Mar 03 09:49:24 imx8mp-lpddr4-evk kernel: cma: cma_alloc(): returned 000000003f063574

Thank you in advance!

Best Regards,

Gencay

[Dhruvit]

Hi @Wobaffet,

I hope you are doing well

The mentioned warning regarding the CMA allocation failure seems to be coming from the mm/cma.c. The cause of the same is mentioned in the below commit and it is reverted in the latest BSP version.

https://github.com/nxp-imx/linux-imx/commit/60a60e32cf91169840abcb4a80f0b0df31708ba7

I hope this information helps you.

Thanks & Regards,

Dhruvit Vasavada

[Wobaffet]

Hello Dhruvit,

I am using the latest BSP from NXP. My cma.c seems to have the mentioned reverted patch. What else could be the issue?

Thank you in advance!

Best Regards.

[Dhruvit · Accepted solution]

Hi @Wobaffet,

I hope you are doing well.

These logs are for warnings that occur when the DMA_API_DEBUG_SG is enabled in the kernel/dma/debug.c. It will perform some extra checking for the DMA API usage.

One can try to remove the DMA_API_DEBUG_SG configuration.

It is mentioned in the kernel/dma/Kconfig that 

"This is particularly likely to have been overlooked in cases where the

 dma_map_sg() API is used for general bulk mapping of pages rather than
 preparing literal scatter-gather descriptors, where there is a risk of
 unexpected behavior from DMA API implementations if the scatterlist
 is technically out-of-spec."

I hope it helps!

Thanks & Regards,

Dhruvit Vasavada