Hi Vinod, On Monday 08 December 2014 21:44:49 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. Of course. My point was that your proposed patch appears (to me) to mean that a driver that supports memcpy must no implement dma_slave_config. What the documentation ought to make clear is that memcpy must work without dma_slave_config, but drivers that support both memcpy and slave operations must implement dma_slave_config for the slave operations. -- Regards, Laurent Pinchart -- 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
