AM625-Q1: DMA transfers to and from GPMC bus in Linux kernel module

Hi Iker,

Thanks for the detailed report. It is very helpful!

The test result with the patch is expected, as the patch only enables DMA_DEV_TO_MEM transfer from GPMC, so write to GPMC is not expected to work.

I can help to implement DMA_MEM_TO_DEV transfer to GPMC. What is the schedule for your project? I currently don't have much bandwidth for it until mid June.

Hi Bin,

Thank you very much for your quick and efficient response. I really appreciate it.

Before developing anything, I would like to confirm whether this patch you’re proposing is the only and/or most appropriate solution for reading from and writing to the GPMC bus from a memory buffer using DMA transfers.

I mention this because it is important for me to keep the kernel unpatched in order to guarantee the compatibility of my modules with future kernel updates.

Hi Iker,

It depends on how data move to/from the device attached to GPMC. The kernel dmaegine API supports basically two types:

1. DMA_DEV_TO_MEM and DMA_MEM_TO_DEV;

2. DMA_MEM_TO_MEM.

Without patching the kernel K3 UDMA driver, #1 is not supported to transfer data with GPMC. (The patch you used enables DMA_DEV_TO_MEM.)

The unpatched kernel should already supports #2, using dmaengine_prep_dma_memcpy().

Hi bin,

Could you elaborate more on the condition “it depends on how data move”?

That thing about “DMA_MEM_TO_MEM” should work with unpatched kernel sounds interesting. In the attached tests, there is a test case where I'm trying to write to the GPMC bus using the dmaengine_prep_dma_memcpy() API without good results (see “2_1_8_dmatest_result.log”). Is it possible that this test case isn’t working because I’m executing it on the SK-AM62 evaluation board? I am still in the proof-of-concept phase and don’t have the full hardware board available (AM62 connected to FPGA).

Thank you very much for your help.

Hi Iker,

Iker Conde said:

Could you elaborate more on the condition “it depends on how data move”?

I meant the two type of transfers I mentioned, dev_to_mem and mem_to_dev has the "FIFO" based device attached to GPMC, while mem_to_mem has the memory-mapped device attached to GPMC.

Iker Conde said:

Is it possible that this test case isn’t working because I’m executing it on the SK-AM62 evaluation board?

I actually don't know if this test is valid, the test tried to write to GPMC address 0x51000000 using mem_to_mem, but nothing is attached to the GPMC interface on SK-AM62 board, right?

BTY, the OSPI driver (drivers/spi/spi-cadence-quadspi.c) uses dmaengine_prep_dma_memcpy() to access OSPI memory. It should be the same as to memory-mapped devices on GPMC.

Hi Bin,

I meant the two type of transfers I mentioned, dev_to_mem and mem_to_dev has the "FIFO" based device attached to GPMC, while mem_to_mem has the memory-mapped device attached to GPMC.

I definitely want to use the "mem_to_mem" mode.

I actually don't know if this test is valid, the test tried to write to GPMC address 0x51000000 using mem_to_mem, but nothing is attached to the GPMC interface on SK-AM62 board, right?

That's correct, nothing is attached to the GPMC interface on the SK-AM62 board (see image below). If you can confirm that dmaengine_prep_dma_memcpy() API for "mem_to_dev" transfers fail when nothing is connected to the GPMC bus, I’ll wait until the full hardware setup is available to verify that the "write" operation completes successfully.

BTY, the OSPI driver (drivers/spi/spi-cadence-quadspi.c) uses dmaengine_prep_dma_memcpy() to access OSPI memory. It should be the same as to memory-mapped devices on GPMC.

This information has been very helpful. I’ve seen that reads are performed using the dmaengine_prep_dma_memcpy() API, while writes are done “indirectly” through a kind of DMA engine internal to the OSPI peripheral. However, can you confirm that both reading from and writing to memory mapped I/O can be done reliably using the dmaengine_prep_dma_memcpy() API?

Thank you so much for your time and detailed insights.

Hi Bin,

I will wait until the full hardware board is available, and then I will test reading and writing using MEM_TO_MEM DMA.

I will contact you again if I encounter any issues when I test it.

Thank you very much for your help!

Hi Iker,

Sounds good.

As you might know, the e2e threads will be locked if no activity in 30 days then you can no longer reply to the threads.

So if this thread is locked in 30 days, you can still click the yellow "+ Ask a related question" button at the top right corner of this page to create a new e2e thread, which will refer to this page to provide the context.