Re: Question: partial transfers of DMABUFs

[Paul Cercueil <paul@crapouillou.net>]

Hi Christian,

Le mercredi 15 février 2023 à 13:58 +0100, Christian König a écrit :
> Hi Paul,
> 
> Am 15.02.23 um 11:48 schrieb Paul Cercueil:
> > Hi,
> > 
> > I am working on adding support for DMABUFs in the IIO subsystem.
> > 
> > One thing we want there, is the ability to specify the number of
> > bytes
> > to transfer (while still defaulting to the DMABUF size).
> > 
> > Since dma_buf_map_attachment() returns a sg_table,
> 
> Please don't assume that this is an sg_table. We just used it as 
> container for DMA addresses, but this has proven to be a mistake.

TL/DR, why was it a mistake? Just curious.

> There is work underway to replace the sg_table with (for example)
> just 
> an array of DMA addresses.

Ok, so I believe at some point we will need an equivalent of
dmaengine_prep_slave_sg() which takes an array of DMA addresses.

> > I basically have two options, and I can't decide which one is the
> > best (or the less ugly):
> > 
> > - Either I add a new API function similar to
> > dmaengine_prep_slave_sg(),
> > which still takes a scatterlist as argument but also takes the
> > number
> > of bytes as argument;
> > 
> > - Or I add a function to duplicate the scatterlist and then shrink
> > it
> > manually, which doesn't sound like a good idea either.
> > 
> > What would be the recommended way?
> 
> I strongly recommend to come up with a new function which only takes
> DMA 
> addresses and separate segment length.

Alright, thanks for your input.

So I would add a new dma_device.dma_prep_slave_dma_array() callback
with a corresponding API function, and then the drivers can be
converted from using .dma_prep_slave_sg() to this new function in due
time.

Vinod, that works for you?

Cheers,
-Paul