Question: partial transfers of DMABUFs
Paul Cercueil
paul at crapouillou.net
Wed Feb 15 13:24:24 UTC 2023
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
More information about the dri-devel
mailing list