CMA Memory Allocation

Wobaffet — Mon, 27 Nov 2023 08:33:38 GMT

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

Re: CMA Memory Allocation

Dhruvit — Mon, 27 Nov 2023 12:56:07 GMT

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

elloRe: CMA Memory Allocation

Wobaffet — Wed, 29 Nov 2023 11:25:24 GMT

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.

Re: elloRe: CMA Memory Allocation

Dhruvit — Mon, 04 Dec 2023 05:21:53 GMT

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."