On Fri, 2011-10-07 at 12:08 -0700, Bounine, Alexandre wrote: > Vinod Koul wrote: > > > > On Mon, 2011-10-03 at 09:52 -0700, Bounine, Alexandre wrote: Adding Jassi to this and sorry for late reply...
> ... 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. 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 :) 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...? -- ~Vinod _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
