AM3358: Porting GPMC edma solution from 3.2.X kernel to 6.12.X

Hi Viktor,

Ii won't be possible to point out what exact is mis-configured by just reviewing the code segments you provided. You might want to compare the EDMA registers to see what is configured differently.

Hello,

The problem that the configuration related EDMA the same.

Maybe in 6.12 I have to explicitly configure some interrupts which was implicitly  configured in 3.2 ?

After more deep investigation I found that in case of 3.2 kernel PARAM_SET OPT register looks like:

EDMA_OPT 0x80102000

The bit 31 (PRIV) has value 1. In case of 6.12 kernel this bit is 0.

Can it be  the reason?

Thank you!

In the end I have launched the DMA transaction from GPMC to memory via EDMA.

The problem was that I has configured my DMA in DMA_DEV_TO_MEM mode. How it's recommended in most documents pages. The DMA_DEV_TO_MEM mode REQIRED the HW trigger. Honestly about it mentioned in debug message:

edma 49000000.dma: Got eDMA channel 52 for virt channel 50 (HW trigger)

But in my case I don't have a HW trigger. The source code which I have in 3.2 kernel describes a DMA_MEM_TO_MEM concept.

Below presented code snippet which I worked on my side:

dma_cap_zero(mask);
dma_cap_set(DMA_MEMCPY,  mask);
dma_ch = dma_request_channel(mask, NULL, NULL);
    
dma_virt_addr = dma_alloc_coherent(dev->parent, 1024*1024, &dma_addr, GFP_KERNEL);
dma_desc = dmaengine_prep_dma_memcpy(dma_ch, dma_addr, gpmc_base.start,	2*0x2480, DMA_PREP_INTERRUPT);
 
if (!dma_desc)
{
	DRV_MSG("DMA busy\n");
    return -1;
}

dma_desc->callback = dma_complete_callback
dma_desc->callback_param = dma_virt_addr;

dma_cookie = dmaengine_submit(dma_desc);
if (dma_submit_error(dma_cookie)) {
	DRV_MSG("DMA transaction submission FAILED\n");
	return -1;
}

DRV_MSG("DMA transaction submission SUCCESS\n");
    
dma_async_issue_pending(fpga_stream.dma_ch);
DRV_MSG("DMA start\n");	

After launch my code I see following message in dmesg:

edma 49000000.dma: Got eDMA channel 20 for virt channel 0 (SW trigger)

In this case I've a question. Is it correct way to use DMA_MEM_TO_MEM instead of  DMA_DEV_TO_MEM  related GPMC bus?

Hi Viktor,

Sorry I was debugging a different issue today and didn't get time to review your message. I will try to review it tomorrow and get back to you.

Hi Viktor,

I am configured in the way you use dma on kernel 6.12.

In your original post:

dma_cfg.src_addr = fpga_stream.gpmc_base.start; //0x09000000
dma_cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
dma_cfg.src_maxburst = 16;

ret = dmaengine_slave_config(fpga_stream.dma_ch, &dma_cfg);
if (ret) {
    DRV_MSG("DMA engine slave config failed: %d\n", ret);
    return -1;
}  
 
dma_desc = dmaengine_prep_slave_single(fpga_stream.dma_ch, dma_addr, 1024, DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);

which uses DEV_TO_MEM to transfer 1024 bytes with bus width of 4 bytes. But in your post on 6/19:

dma_cap_set(DMA_MEMCPY,  mask);
dma_ch = dma_request_channel(mask, NULL, NULL);
    
dma_virt_addr = dma_alloc_coherent(dev->parent, 1024*1024, &dma_addr, GFP_KERNEL);
dma_desc = dmaengine_prep_dma_memcpy(dma_ch, dma_addr, gpmc_base.start,    2*0x2480, DMA_PREP_INTERRUPT);

which uses MEM_TO_MEM to transfer 2*0x2480 bytes.

Which version is the final one? How exactly are your FPGA data presented to the GPMC interface? Is it in FIFO mode with 4 bytes FIFO width or the entire data frame is memory mapped to GPMC address space? You would need DEV_TO_MEM for the former case but MEM_TO_MEM for latter case.

Hello Bin,

Both sizes 1024 and 2*0x2480 are valid. It's just a different frames which FPGA can send to CPU via GPMC.

In case of DMA_MEM_TO_MEM both sizes are working properly. In case of DMA_DEV_TO_MEM also both doesn't work.

We use the data mapping to GPMC memory space (at leas ACNT=FPGA_FRAME_SIZE)

Look like that DMA_MEM_TO_MEM correct. But I'm bit worry about future. 

Physically we are talking about DEV - > MEMORY data transfer via GPMC bus.

In our project we have to carry about following important points:

- security aspect

- possibilities for migration on the next revision of Linux kernel

I'm afraid that in future the approach MEM -> MEM can be deprecated and prohibited in case if we are talking about data transfer from device.

Hi Viktor,

The DMA_MEM_TO_MEM doesn't not mean that it is only for memory and cannot be used on device. MEM_TO_MEM is for DMA transfers that have the same size in source and target address. For example, to read from GPMC NAND, DMA_DEV_TO_MEM is used, while to read from GPMC NOR, DMA_MEM_TO_MEM is used.

Viktor Butckikh said:

I'm afraid that in future the approach MEM -> MEM can be deprecated

Where did you get the information that MEM_TO_MEM will be deprecated?

Hello Bin,

Where did you get the information that MEM_TO_MEM will be deprecated?

It's just a my private doubt.

About NAND interface I have a good example for usage DMA interface:

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/mtd/nand/raw/omap2.c?h=ti-linux-6.12.y

Could you please provide the link on the GPMC NOR implementation with DMA.

Thank you!

Hi Viktor,

I am not aware of any GPMC NOR driver, but following is the kernel OSPI driver which has serial NOR device attached to.

drivers/spi/spi-cadence-quadspi.c

its function cqspi_direct_read_dma() uses dmaengine_prep_dma_memcpy().