On Mon, Dec 08, 2014 at 05:59:58PM +0100, Maxime Ripard wrote: > On Mon, Dec 08, 2014 at 09:44:49PM +0530, Vinod Koul wrote: > > On Mon, Dec 08, 2014 at 03:13:16PM +0100, Maxime Ripard wrote: > > > On Mon, Dec 08, 2014 at 06:23:52PM +0530, Vinod Koul wrote: > > > > On Mon, Dec 08, 2014 at 10:00:41AM +0200, Laurent Pinchart wrote: > > > > > > + This should NOT be set or expected to be set for memcpy operations > > > > > > > > > > How about "Drivers that implement memcpy operations don't need to implement > > > > > this call." ? It makes it clearer that drivers that support both slave and > > > > > memcpy must implement dma_slave_config. > > > > > > > > That is a problem we want to fix of not having drivers which implement both > > > > slave and memcpy rely on dma_slave_config for memcpy operations. Maxime got > > > > bitten by that recently so lets fix documentation for this > > > > > > I really think that while the documentation should make it clear, we > > > should be able to support dmaengine drivers that implement both slave > > > and async operations. > > > > > > It is totally allowed by the framework for now, and some hardware > > > doesn't make any distinction between what's considered a slave > > > transfer and a memcpy for example. So I'm not really convinced we > > > should make that distinction in the framework either. > > > > the dma_slave_config simply doesn't make sense for memcpy. User should be > > able to invoke memcpy operation without making any other configuration. > > We do agree on that. But we shouldn't discourage people from > implementing dma_slave_config if that makes sense either, and that's > what you were implying. Yup :) -- ~Vinod
Attachment:
signature.asc
Description: Digital signature
