On Fri, Oct 7, 2011 at 4:27 AM, Jassi Brar <jaswinder.singh@linaro.org> wrote:> On 7 October 2011 11:15, Vinod Koul <vinod.koul@intel.com> wrote:>>> Thru this patch Jassi gave a very good try at merging DMA_SLAVE and>> memcpy, but more we debate this, I am still not convinced about merging>> memcpy and DMA_SLAVE yet.>>> Nobody is merging memcpy and DMA_SLAVE right away.> The api's primary purpose is to support interleave transfers.> Possibility to merge other prepares into this is a side-effect.>>> I would still argue that if we split this on same lines as current>> mechanism, we have clean way to convey all details for both cases.>>> Do you mean to have separate interleaved transfer apis for Slave> and Mem->Mem ? Please clarify.>

This is a tangent, but it would be nice if this API extension alsocovered the needs of the incoming RapidIO case which wants to specifynew device context information per operation (and not once atconfiguration time, like slave case). Would it be enough if thetransfer template included a (struct device *context) member at theend? Most dma users could ignore it, but RapidIO could use it to dosomething like:

struct rio_dev *rdev = container_of(context, typeof(*rdev), device);

That might not be enough, but I'm concerned that making the context a(void *) is too flexible. I'd rather have something like this thanacquiring a lock in rio_dma_prep_slave_sg() and holding it over->prep(). The alternative is to extend device_prep_slave_sg to takean extra parameter, but that impacts all other slave implementationswith a dead parameter.