Re: [PATCH v2 2/5] dmaengine: dw-edma: Add DMA_SG support

[Frank Li <Frank.li@oss.nxp.com>]

On Fri, Aug 14, 2026 at 03:58:48PM +0200, Manivannan Sadhasivam wrote:
> On Thu, Aug 06, 2026 at 02:06:30PM -0500, Frank Li wrote:
> > On Mon, Aug 03, 2026 at 04:01:44PM +0530, Sumit Kumar wrote:
> > > [You don't often get email from sumit.kumar@oss.qualcomm.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Synopsys DesignWare eDMA supports a linked-list mode where each list item
> > > carries independent source and destination addresses, letting multiple
> > > independent memory transfers be described in one linked list and submitted
> > > to the hardware as a single DMA transaction. The IP processes list items
> > > strictly in order, so paired scatter-gather entries are never reordered.
> > >
> > > Implement the DMA_SG capability by adding a new EDMA_XFER_DUAL_SG transfer
> > > type and a corresponding struct dw_edma_dual_sg carrying the paired source
> > > and destination SG lists. dw_edma_device_transfer() walks both lists in
> > > lockstep, building a single hardware linked-list; a per-entry length
> > > mismatch or premature list end fails the whole request.
> >
> > It is not as simple as it.  for example, if you want to transfer 9k data
> > from src to dest
> >
> > src virtual addr 0x1004,        dest 0xA0001008
> >
> > when map_sg, src's sg maybe
> >
> > 0x1000  .. 4k   offset 4,
> > 0x9000  .. 4k   offset 0
> > 0xA000  .. 4k   offset 0
> >
> > or
> > 0x1000 .. 8k  offset 4
> > 0xA000 .. 4k  offset 0
> >
> > which totally depend on physical address allocation although most likely
> > first case happen
> >
> > dest sg
> > 0xA001000 .. 4k offset 8
> > 0xA008000 .. 4k offset 0
> > 0xA00E000 .. 4k offset 0
> >
> > descriptors
> > 1 	transfer 4k-8
> > 2       transfer tail 4 byte
> > 3 	transfer 4k-8
> > 4       transfer tail 4 byte
> > ...
> >
> > the start address of src and dest is highly possible differences. So it
> > is very hard to match your requirement, both sg's structure is the same.
> >
>
> That's the API limitation, isn't it? The callers have to supply the same length
> src/dst pairs to work with this API. But they don't necessarily need to use

Define API is memcpy, not memory to peripherail Or peripherail to memory

dmaengine_prep_dma_sg() - Prepare a memory-to-memory scatter-gather DMA descriptor.

Most memcpy user need call dma_map_sg() to get sg.  And most likely two
virutal address offset to page is difference.

So most likely return failure by this API.

What next, if failure,  fallback other DMAengine API or return user?

If fallback to other APIs, code logic become more complex. If return to
user, user will be strange why failure at some time, but success at
some time.

Frank

> dma_map_sg() which can provide fragmented mappings as you described. They can
> use dma_map_single() or even the bus addresses directly as the MHI client is
> already doing.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்