On Fri, Jul 17, 2015 at 12:13:48PM +0200, Lars-Peter Clausen wrote: > On 07/16/2015 09:05 PM, Robert Jarzmik wrote: > >Lars-Peter Clausen <lars@xxxxxxxxxx> writes: > > > >>On 07/16/2015 03:08 PM, Vinod Koul wrote: > >>>On Mon, Jul 13, 2015 at 01:00:54PM +0200, Lars-Peter Clausen wrote: > >>>>>>>Actually there has never been a recommendation for slave cases. It came from async > >>>>>>>API and slave users should never have used it, untill now. > >>>>>> > >>>>>>That doesn't reflect reality. The fast majority slave API users set > >>>>>>the flag and some DMAengine drivers expect it to be set. > >>>>>That is simply wrong and we need to fix that > >>>> > >>>>Could you explain why you think that it is wrong? > >>>> > >>>>I think we might have different understandings of what exactly the > >>>>DMA_CTRL_ACK flag means. > >>>This is documented now > >>> > >>> * DMA_CTRL_ACK > >>> - If set, the transfer can be reused after being completed. > >>> - There is a guarantee the transfer won't be freed until it is acked > >>> by async_tx_ack(). > >>> - As a consequence, if a device driver wants to skip the dma_map_sg() > >>> and > >>> dma_unmap_sg() in between 2 transfers, because the DMA'd data wasn't used, > >>> it can resubmit the transfer right after its completion. > >>> > >>>Any user who doesnt want this interpretation should be fixed, any driver not > >>>doing this should be fixed :) > >> > >>That would be every user and every driver. This documentation was added as part > >>of Robert's series, but does not agree, with either other documentation of the > >>flag, e.g. in include/linux/dmaengine.h, nor with any of the users. The > >>documentation needs to be fixed, not the other way around. I agree with this part... > >Might it be possible that I implemented code and documentation with the inverted > >logic ? Or said differently, if I had written : > > - If *clear*, the transfer can be reused after being completed. > >And inverted the test in virt-dma.c, would it be better, Vinod ? Okay, I am thinking not to overload stuff and go with Lar's suggestion of having anew flag and lets have this explicitly > >I'm asking because in the code I read : > > - include/linux/dmaengine.h: > > if clear, the descriptor cannot be reused until the client > > acknowledges receipt. > > - drivers/dma/virt-dma.c > > If set, the transfer can be reused after being completed. > > > >If I invert my DMA_CTRL_ACK documentation and code logic in virt-dma.c, would > >that fit the old meaning, and would that still be acceptable by Vinod ? > > It would certainly bring the two closer and fix most of the fallout > we are seeing at the moment. > > But I still believe that support for re-usable descriptors deserve > their own flag. Drivers which support DMA_CTRL_ACK wont > automatically be able to support re-usable descriptors. The > assumption currently is that each descriptor is submitted exactly > once. The dmaengine documentation even states that submit() needs to > be called right after device_prep_*() since some driver might take a > lock in the first and release it in the second. This is something > that will obviously not work with re-usable descriptors. That would be better idea also not confuse folks. So I would revert the original patch, Documentation update, add new flag DMA_DESC_REUSE for this and let Robert's driver use this So is this plan fine with all, if so I push these changes tomorrow -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
