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
