Re: [PATCH v2 23/23] dmaengine: sdxi: Add DMA engine provider

["Lynch, Nathan" <nathan.lynch@amd.com>]

On 5/11/2026 3:47 PM, Frank Li wrote:
>> +static struct dma_async_tx_descriptor *
>> +sdxi_dma_prep_memcpy(struct dma_chan *dma_chan, dma_addr_t dst,
>> +		     dma_addr_t src, size_t len, unsigned long flags)
>> +{
>> +	struct sdxi_akey_ent *akey = to_sdxi_dma_chan(dma_chan)->akey;
>> +	struct sdxi_cxt *cxt = to_sdxi_dma_chan(dma_chan)->cxt;
>> +	u16 akey_index = sdxi_akey_index(cxt, akey);
>> +	struct sdxi_dma_desc *sddesc;
>> +	struct sdxi_copy copy = {
>> +		.src = src,
>> +		.dst = dst,
>> +		.src_akey = akey_index,
>> +		.dst_akey = akey_index,
>> +		.len = len,
>> +	};
>> +
>> +	/*
>> +	 * Perform a trial encode to a dummy descriptor on the stack
>> +	 * so we can reject bad inputs without touching the ring
>> +	 * state.
>> +	 */
>> +	if (sdxi_encode_copy(&(struct sdxi_desc){}, &copy))
>> +		return NULL;
>> +
>> +	sddesc = (flags & DMA_PREP_INTERRUPT) ?
>> +		prep_memcpy_intr(dma_chan, &copy) :
>> +		prep_memcpy_polled(dma_chan, &copy);
> 
> Maybe I am wrong. According to my understand "DMA_PREP_INTERRUPT" is trigger
> irq when complete.  without DMA_PREP_INTERRUPT, don't trigger irq when
> complete, not means use polling.

OK, my choice of function names there arises from the dmatest 'polled'
parameter which selects the completion signaling mode. I can rename it
to prep_memcpy_nointr() or otherwise refactor to avoid the confusion, if
that's the issue.


> for example,
> tx1 = prep(flags = 0)
> submit(tx1);
> tx2 = prep(flags = DMA_PREP_INTERRUPT)
> submit(tx2);
> 
> issue_pending();
> 
> DMA Consummer just expect get irq when tx2 complete to reduce irq numbers.

Yes, I believe the SDXI DMA provider satisfies this expectation as
currently written.

> If using polling here, it will reduce transfer efficacy.

The SDXI code does not poll for any descriptor's status unless the
dmaengine API asks it to, I think? E.g. via device_tx_status().