Le mercredi 15 février 2023 à 13:13 +0100, Maarten Lankhorst a écrit : > > On 2023-02-15 13:00, Paul Cercueil wrote: > > Hi Maarten, > > > > Le mercredi 15 février 2023 à 12:52 +0100, Maarten Lankhorst a > > écrit : > > > Hey, > > > > > > On 2023-02-15 12:47, Paul Cercueil wrote: > > > > Hi Maarten, > > > > > > > > Le mercredi 15 février 2023 à 12:30 +0100, Maarten Lankhorst a > > > > écrit : > > > > > Hey, > > > > > > > > > > On 2023-02-15 11:48, Paul Cercueil wrote: > > > > > > 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, 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? > > > > > Does this need an api change? If you create a DMA-BUF of size > > > > > X, > > > > > it > > > > > has > > > > > to be of size X. You can pad with a dummy page probably if > > > > > you > > > > > know > > > > > it > > > > > in advance. But after it has been imported, it cannot change > > > > > size. > > > > Yes, the sizes are fixed. > > > > > > > > > You don´t have to write the entire dma-buf either, so if you > > > > > want > > > > > to > > > > > create a 1GB buf and only use the first 4K, that is allowed. > > > > > The > > > > > contents of the remainder of the DMA-BUF are undefined. It's > > > > > up > > > > > to > > > > > userspace to assign a meaning to it. > > > > > > > > > > I think I'm missing something here that makes the whole > > > > > question > > > > > m,ake > > > > > more sense. > > > > I want my userspace to be able to specify how much of the > > > > DMABUF is > > > > to > > > > be read from or written to. > > > > > > > > So in my new "dmabuf enqueue" IOCTL that I want to add to IIO, > > > > I > > > > added > > > > a parameter to specify the number of bytes to transfer (where 0 > > > > means > > > > the whole buffer). > > > > > > > > The problem I have now, is that the current dmaengine core does > > > > not > > > > have a API function that takes a scatterlist (returned by > > > > dma_map_attachment()) and a transfer size in bytes, it will > > > > always > > > > transfer the whole scatterlist. > > > > > > > > So my two options would be to add a new API function to support > > > > specifying a bytes count, or add a mechanism to duplicate a > > > > scatterlist, so that I can tweak it to the right size. > > > This doesn't have to happen through DMA-BUF. Presumably you are > > > both > > > the > > > importer and the exporter, so after you know how much is read, > > > you > > > can > > > tell this to the importer that X number of bytes can be read from > > > DMA-BUF Y. > > Yes, I do that already as it is an argument in my ioctl. > > > > > In your case, when enqueing you will get a full SG list, but if > > > you > > > know > > > only X bytes are read/written you only have to map the first X > > > bytes > > > to > > > your IIO device. The rest of the SG list could be ignored safely. > > Yes. But I don't know how to "ignore the rest of the SG list". > > > > - dma_buf_map_attachment() does not have a parameter to specify > > that I > > only need the first X bytes mapped; > > > > - if I map the whole thing, dmaengine_prep_slave_sg() does not have > > an > > option to specify that I only want the first X bytes transferred. > > sg_split apppears to allow you to split it? I'm not 100% sure whether > it > leaves the original SG untouched, but you can try to put it in > between > those 2 calls to get a smaller SG to pass to prep_slave_sg. I overlooked sg_split. It looks like it could work for me. Thanks! Cheers, -Paul
