On Sat, Oct 15, 2011 at 1:36 PM, Vinod Koul <vinod.k...@intel.com> wrote: > > > ... skip ... > > > > > > > > Second, having ability to pass private target information allows me to > > > > pass > > > > information about remote target device on per-transfer basis. > > > Okay, then why not pass the dma address and make your dma driver > > > transparent (i saw you passed RIO address, IIRC 64+2 bits) > > > Currently using dma_slave_config we pass channel specific information, > > > things like peripheral address and config don't change typically > > > between > > > transfers and if you have some controller specific properties you can > > > pass them by embedding dma_slave_config in your specific structure. > > > Worst case, you can configure slave before every prepare > > > > In addition to address on target RIO device I need to pass corresponding > > device destination ID. With single channel capable to transfer data between > > local memory and different RapidIO devices I have to pass device specific > > information on per transfer basis (destID + 66-bit address + type of write > > ops, etc.). > > > > Even having 8 channels (each set for specific target) will not help me with > > full support of RapidIO network where I have 8- or 16-bit destID (256 or 64K > > devices respectively). > > > > RapidIO controller device (and its DMA component) may provide services to > > multiple device drivers which service individual devices on RapidIO network > > (similar to PCIe having multiple peripherals, but not using memory mapped > > model - destID defines route to a device). > > > > Generic RapidIO controller may have only one DMA channel which services all > > target devices forming the network. We may have multiple concurrent data > > transfer requests for different devices. > > > > Parallel discussion with Dan touches the same post-config approach and > > another option. I like Dan's idea of having RIO-specific version of > > prep_sg(). > > At the same time my current implementation of rio_dma_prep_slave_sg() with > > added appropriate locking may do job as well and keeps DMA part within > > existing API (DMA_RAPIDIO removed). > Thanks this helps to understand your model. > > Per above you need destID, 66bit address and type of write to be passed > for each transfer. Looking at your rio_dma_data, i cant see the destID. > destID is extracted by rio_dma_prep_slave_sg() from the rio_dev parameter and passed down prep_slave_sg() as part of rio_dma_ext structure (as dchan->private).
> Nevertheless we have few ways to solve this, pass this using > dma_slave_config _every-time_ before doing a prep_slave_sg. Or as Dan > pointed out create RIO specific version. Principally I am not for > adding > a subsystem specific stuff, even more when we are talking about > converging and cutting down on dmaengine API :) > Agree. This is why I am trying to find my way within boundaries of DMA_SLAVE API first. > Another alternate approach could be to add one more argument to > prep_slave_sg API which allows us to pass additional runtime specific > parameters. This can be NULL and unused for existing drivers and used > in > RIO and any future subsystems which want to use dmaengine. > Thoughts...? > This is exactly what I need and it may be useful for future systems. This makes DMA_SLAVE prepared for variations in device addressing. Plus, this will make porting RIO DMA to previous kernel versions relatively easy for those who prefers/requires that. Based on the fact that you started transition to the new DMA transfer direction flags, it may be a good time to add that extra argument to prep_slave_sg(). Alex. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev