On Wed, 2012-02-01 at 01:09 +0100, Guennadi Liakhovetski wrote: > On Mon, 30 Jan 2012, Vinod Koul wrote: > > > On Thu, 2012-01-26 at 16:22 -0500, Alexandre Bounine wrote: > > > As we agreed during our discussion about adding DMA Engine support for > > > RapidIO > > > subsystem, RapidIO and similar clients may benefit from adding an extra > > > context > > > parameter to device_prep_slave_sg() callback. > > > See https://lkml.org/lkml/2011/10/24/275 for more details. > > > > > > Adding the context parameter will allow to pass client/target specific > > > information associated with an individual data transfer request. > > > > > > In the case of RapidIO support this additional information consists of > > > target > > > destination ID and its buffer address (which is not mapped into the local > > > CPU > > > memory space). Because a single RapidIO-capable DMA channel may queue data > > > transfer requests to different target devices, the per-request > > > configuration > > > is required. > > > > > > The proposed change eliminates need for new subsystem-specific API. > > > Existing DMA_SLAVE clients will ignore the new parameter. > > > > > > This RFC only demonstrates the API change and does not include > > > corresponding > > > changes to existing DMA_SLAVE clients. Complete set of patches will be > > > provided > > > after (if) this API change is accepted. > > This looks good to me. But was thinking if we need to add this new > > parameter for other slave calls (circular, interleaved, memcpy...) > > Yes, we (shdma.c) also need to pass additional slave configuration > information to the dmaengine driver and I also was thinking about > extending the existing API, but my ideas were going more in the direction > of adding a parameter to __dma_request_channel() along the lines of So your question is more on the lines of channel mapping/allocation? The approach here is to pass controller specific parameters which are required to setup the respective transfer. Since this is dependent on each transfer, this needs to be passed in respective prepare.
The two things are completely orthogonal and shouldn't be clubbed. For your issue we need a separate debate on how to solve this... I am open to ideas... -- ~Vinod _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
