On Mon, Jul 20, 2015 at 12:55:35PM +0200, Lars-Peter Clausen wrote: > On 07/19/2015 07:44 PM, Robert Jarzmik wrote: > >Vinod Koul <vinod.koul@xxxxxxxxx> writes: > > > >>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 > >Sure, works for me. > >I small detail : > > > > - can I submit a quick patch to renable virt-dma to have reusable txs, using > > DMA_DESC_REUSE instead of DMA_CTR_ACK so that you can pick it up in the same > > cycle ? > > > > - can I add a function to dmaengine to mark a tx as "finished", ie. not > > reusable any more, and freeable ? > > If so, I'd like a name for it please. > > What about void async_tx_finish_reusable(struct dma_async_tx_descriptor *tx) > > ? > > The naming convention for dmaengine API functions is a bit cluttered > at the moment. For new functions we should agree on a single prefix. > I'd suggest to call the function dmaengine_desc_release(). Yup no new APIs with async_xxx > > The other thing is making sure that the new API is complete enough > so that it is possible for different types of dmaengine drivers to > implement it. > > Currently the dmaengine API has the built-in assumption that > dmaengine_prep_*() function and dmaengine_submit() are always called > in pairs. And some drivers rely on this assumption. It might be a > good idea to add a dmaengine_prep_reuse() function that takes a > already allocated descriptor and must be called before > dmaengine_submit() can be called again. This solves two issues, the > first is that prep_*() and submit() will still be called in pairs, > the second one is that drivers have the chance to re-initialize some > state for the descriptor, e.g. set the progress for the descriptor > to 0, or similar. Drivers that don't need to do anything special to > reuse a descriptor don't need to implement the prep_reuse() callback > and the call becomes a no-op. > > The other thing I'd like to see is a feature flag in the > dma_slave_caps struct to indicate weather a dmaengine driver > supports re-usable descriptors or not. This is important for generic > code so it can figure out in advance whether a driver supports > re-usable descriptors or if it has to fallback allocating individual > descriptors for each transfer. Yes both of these suggestions make sense. We absolutely need caps to understand device support. -- ~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
