Hi Christian,
Le mercredi 15 février 2023 à 13:58 +0100, Christian König a écrit :
Hi Paul,TL/DR, why was it a mistake? Just curious.
Am 15.02.23 um 11:48 schrieb Paul Cercueil:
Hi,Please don't assume that this is an sg_table. We just used it as
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,
container for DMA addresses, but this has proven to be a mistake.
There is work underway to replace the sg_table with (for example)Ok, so I believe at some point we will need an equivalent of
just
an array of DMA addresses.
dmaengine_prep_slave_sg() which takes an array of DMA addresses.
Alright, thanks for your input.I basically have two options, and I can't decide which one is theI strongly recommend to come up with a new function which only takes
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?
DMA
addresses and separate segment length.
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