AM62A3: Linux DMA Identifiers for GPMC Device Register to Memory Transfer

Hi Craig,

The DMA driver in the current kernel for AM62Ax devices requires the interface to have PDMA module to use DMA_DEV_TO_MEM or DMA_MEM_TO_DEV transfer mode. But GPMC doesn't have PDMA.

You potentially could use DMA_MEM_TO_MEM on AM62Ax GPMC. Can you please describe your data transfer scenario on GPMC then I will know if it is possible to use DMA on your GPMC usecase?

Craig Boardman said:

I've examined `drivers/dma/ti/k3-psil-am62a.c`, but don't find anything related to GPMC in the `am62a_src_ep_map`.

GPMC doesn't have PDMA module, so the psil driver is irrelevant.

Ok, that would explain why I didn't find anything relating to it, thanks for the clarification.

My data transfer scenario is that I have a 64-bit register on the GPMC device that I read N times to fill a sample buffer in memory. I would like to set up a transfer that kicks off the read process, and on completion notify user-space of the data. A new process would then be started, filling a free memory buffer.

Thanks,

 Craig.

Hi Craig,

So the 64-bit GPMC register acts as a FIFO, DMA keeps reading it N times to get 8N bytes data to a buffer in DDR, correct?

What triggers the DMA transfer, software (kernel driver) or hardware event from GPMC?

Essentially. The register is read say 1024 times to fill a buffer, which is then processed by the user application. This is some custom hardware, and a polling technique is used in a synchronized fashion. The DMA is triggered when a separate user space event is received via an ioctl command. The app polls whether the DMA buffer is ready at various synchronization points, and when a new buffer is available, it uses it, an starts the next transfer.

Hi Craig,

As I explained early, the kernel DMA driver in the Processor SDK doesn't support this usecase. However, I recently implemented the solution for a customer, which is very similar to your use case. The only difference in that use case is that the GPMC/FPGA drives a GPIO to directly trigger DMA transfer when GPMC data are ready, CPU only gets DMA completion interrupt when DMA transfer is complete.

Please review the following e2e thread which covers all the details of the implementation. Be aware this thread is very long!

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1200987/am625-rerouting-interrupt-to-dma-event-and-dma_dev_to_mem-channel-selection

Thanks Bin, I'll read up on that (very long) thread :)

Hi Bin,

I finally got back to making this work for my product. After examining the thread you provided, I'd like to go through how I would set this up, and hopefully have you confirm I'm on the correct track. Basically I have a shell driver that attempts to transfer data from a register on a device attached to the GPMC bus. The dma transfer is triggered by an ioctl command the indicates how many times the register should be read (say 1000), into a memory buffer. Below are some snippets form the device tree, driver dma initialization code, and ioctl command to start the transfer. 

Node in device tree:

	my_dma_driver {
		compatible = "my_dma_driver";
		#address-cells = <1>;
		#size-cells = <1>;
		/* Register to read on the GPMC bus */
		reg = <0x0 0x5000DE80 0x0 8>;
		/* Buffer declared as coherent memory */
		memory-region = <&my_dma_coherent_buffer_region>;
		dmas = <&main_bcdma 1 0 0>;
		dma-names = "rx";
		status = "okay";
	};

Code in invoked from probe to initialize DMA:

static int init_dma(struct my_dma_data* priv) {
	struct dma_slave_config dma_config;
	struct dma_chan *dma_chan;
	int ret;

	/* Declare the reserved memory of for the dma operation to be the
	 * coherent memory allocated by the dma operations for this device
	 * driver */
	ret = dma_declare_coherent_memory(
			priv->dev,
			(phys_addr_t)priv->dma_phys_start,
			(dma_addr_t)priv->dma_phys_start,
			priv->dma_phys_size);
	if (ret != 0) {
		dev_err(priv->dev, "dma_declare_coherent_memory error (%d)", ret);
		return ret;
	}

	/* Request the rx dma channel to be used by the driver */
	dma_chan = dma_request_chan(priv->dev, "rx");
	if (IS_ERR_OR_NULL(dma_chan)) {
		ret = PTR_ERR(dma_chan);
		dev_err(priv->dev, "DMA rx channel request failure (err=%d, ptr=%px)\n", 
				ret, dma_chan);
		return ret;
	}
	priv->dma_chan = dma_chan;

	/* Configure the slave transaction for the requested memory transfer */
	dma_config.direction = DMA_DEV_TO_MEM;
	dma_config.src_addr = priv->src_addr;
	dma_config.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
	dma_config.src_maxburst = 4;
	ret = dmaengine_slave_config(priv->dma_chan, &dma_config);
	if (ret != 0) {
		dev_err(priv->dev, "Failed to set slave config (err=%d)\n", ret);
		return ret;
	}

	return 0;
}

Code to start the DMA (invoked from an ioctl):

static int dma_start(dma_data* priv, unsigned long user_param) {
	struct device *dev;
	struct dma_par par;
	struct dma_async_tx_descriptor *tx;
	dma_cookie_t cookie;
	int ret;

	dev = priv->dev;
	ret = copy_from_user((void *)&par,
				(const void __user *)user_param,
				sizeof(par));
	if (ret != 0) {
		dev_err(dev, "dma_start: copy_from_user failure");
		return -1;
	}

	/* Prepare DMA transaction */
	tx = dmaengine_prep_slave_single(priv->dma_chan,
					(dma_addr_t)par.dst, par.len,
					 DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
	if (IS_ERR_OR_NULL(tx)) {
		long err = PTR_ERR(tx);
		dev_err(priv->dev, "dma_start: DMA transaction preparation failed (%ld)\n", err);
		return -1;
	}

	tx->callback = dma_async_tx_callback;

	cookie = dmaengine_submit(tx);
	if (dma_submit_error(cookie)) {
		dev_err(priv->dev, "DMA transaction submission failed\n");
		return -1;
	}
	priv->dma_cookie = cookie;

	dma_async_issue_pending(priv->dma_chan);

	return 0;
}

The intention would then be to apply the patch you provided in the referenced thread that allows the bcdma to work in this situation:

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index ff3dc91f826c..f06899367ebd 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -952,9 +952,14 @@ static int udma_start(struct udma_chan *uc)
 		udma_rchanrt_write(uc, UDMA_CHAN_RT_CTL_REG,
 				   UDMA_CHAN_RT_CTL_EN);
 
-		/* Enable remote */
-		udma_rchanrt_write(uc, UDMA_CHAN_RT_PEER_RT_EN_REG,
+		if (!uc->config.tr_trigger_type)
+			/* Enable remote */
+			udma_rchanrt_write(uc, UDMA_CHAN_RT_PEER_RT_EN_REG,
 				   UDMA_PEER_RT_EN_ENABLE);
+		else
+			udma_tchanrt_write(uc, UDMA_CHAN_RT_CTL_REG,
+				   UDMA_CHAN_RT_CTL_EN);
+
 
 		break;
 	case DMA_MEM_TO_DEV:
@@ -2827,7 +2832,7 @@ static struct udma_desc *udma_alloc_tr_desc(struct udma_chan *uc,
 	if (uc->cyclic)
 		reload_count = CPPI5_INFO0_TRDESC_RLDCNT_INFINITE;
 
-	if (dir == DMA_DEV_TO_MEM)
+	if (dir == DMA_DEV_TO_MEM && !uc->config.tr_trigger_type)
 		ring_id = k3_ringacc_get_ring_id(uc->rflow->r_ring);
 	else
 		ring_id = k3_ringacc_get_ring_id(uc->tchan->tc_ring);
@@ -2987,6 +2992,7 @@ udma_prep_slave_sg_triggered_tr(struct udma_chan *uc, struct scatterlist *sgl,
 	int num_tr = 0;
 	int tr_idx = 0;
 	u32 burst, trigger_size, port_window;
+	int dim1;
 	u64 asel;
 
 	if (dir == DMA_DEV_TO_MEM) {
@@ -3021,6 +3027,7 @@ udma_prep_slave_sg_triggered_tr(struct udma_chan *uc, struct scatterlist *sgl,
 		tr_cnt1 = burst;
 	}
 	trigger_size = tr_cnt0 * tr_cnt1;
+	dim1 = (uc->config.tr_trigger_type) ? 0 : (-1) * tr_cnt0;
 
 	/* estimate the number of TRs we will need */
 	for_each_sg(sgl, sgent, sglen, i) {
@@ -3085,7 +3092,7 @@ udma_prep_slave_sg_triggered_tr(struct udma_chan *uc, struct scatterlist *sgl,
 			tr_req[tr_idx].icnt1 = tr_cnt1;
 			tr_req[tr_idx].icnt2 = tr0_cnt2;
 			tr_req[tr_idx].icnt3 = tr0_cnt3;
-			tr_req[tr_idx].dim1 = (-1) * tr_cnt0;
+			tr_req[tr_idx].dim1 = dim1;
 
 			tr_req[tr_idx].daddr = sg_addr;
 			tr_req[tr_idx].dicnt0 = tr_cnt0;
@@ -3132,7 +3139,7 @@ udma_prep_slave_sg_triggered_tr(struct udma_chan *uc, struct scatterlist *sgl,
 				tr_req[tr_idx].icnt1 = tr_cnt1;
 				tr_req[tr_idx].icnt2 = tr1_cnt2;
 				tr_req[tr_idx].icnt3 = 1;
-				tr_req[tr_idx].dim1 = (-1) * tr_cnt0;
+				tr_req[tr_idx].dim1 = dim1;
 
 				tr_req[tr_idx].daddr = sg_addr;
 				tr_req[tr_idx].dicnt0 = tr_cnt0;
@@ -3417,6 +3424,7 @@ udma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 	struct udma_desc *d;
 	u32 burst;
 
+#if 0
 	if (dir != uc->config.dir &&
 	    (uc->config.dir == DMA_MEM_TO_MEM && !uc->config.tr_trigger_type)) {
 		dev_err(chan->device->dev,
@@ -3426,6 +3434,7 @@ udma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 			dmaengine_get_direction_text(dir));
 		return NULL;
 	}
+#endif
 
 	if (dir == DMA_DEV_TO_MEM) {
 		dev_width = uc->cfg.src_addr_width;
@@ -3446,7 +3455,7 @@ udma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 	if (uc->config.pkt_mode)
 		d = udma_prep_slave_sg_pkt(uc, sgl, sglen, dir, tx_flags,
 					   context);
-	else if (is_slave_direction(uc->config.dir))
+	else if (is_slave_direction(uc->config.dir) && !uc->config.tr_trigger_type)
 		d = udma_prep_slave_sg_tr(uc, sgl, sglen, dir, tx_flags,
 					  context);
 	else
@@ -3778,6 +3787,9 @@ static void udma_issue_pending(struct dma_chan *chan)
 	struct udma_chan *uc = to_udma_chan(chan);
 	unsigned long flags;
 
+	if (uc->config.tr_trigger_type && uc->bchan)
+		dev_info(NULL, "___chan%d: id %d\n", uc->id, uc->bchan->id);
+
 	spin_lock_irqsave(&uc->vc.lock, flags);
 
 	/* If we have something pending and no active descriptor, then */

Hi Craig,

Nice to see you are making progress.

Craig Boardman said:

Code to start the DMA (invoked from an ioctl):

In your use case, is the GPMC data are ready when application invokes the ioctl to run dma_start() function, so when dma_async_issue_pending() is called, the DMA channel should start moving data right away?

Yes, that's the way it is intended to operate.

I am having a number of issues getting this working. I haven't yet been able to get through the `dmaengine_prep_slave_single` call. It makes it into `udma_prep_slave_sg_triggered_tr` which then causes the system to freeze in the `udma_alloc_tr_desc`. I'm currently trying to track down how it's dying there... I'm not even getting panic info out of the system at that point.

Ok, your use case is much simpler than the previous one which you referred to.

Please give me a few days to review your code. I am currently debugging another customer issue.

Thanks Bin, I'll try applying this patch, and see how it goes.

One point that may have been missed is that I was getting a kernel crash when the dmaengine_prep_slave_single eventually invoked udma_alloc_tr_desc . I'm not sure what was causing this. One thought was maybe that the dma_declare_coherent_memory allocation was interfering with the dma allocation of the TR's.

Hi Bin,

I finally got some time to try this out. I applied the patch, and incorporated your driver with a few changes to read from the device register. As far as I can tell, everything worked perfectly. Next step for me is to incorporate the changes into the actual driver. I'll update you when I get that sorted.

Thanks a lot for the help you have provided.

HI Craig,

This is great progress. Thanks for the update.