On Mon, 2012-06-11 at 09:24 +0100, Russell King - ARM Linux wrote: > On Mon, Jun 11, 2012 at 10:20:49AM +0530, Vinod Koul wrote: > > I think it is a good idea. And I would like to extend it even a little > > bit. Do we have any users of peripheral to peripheral slave dma? > > IIRC that is not the case, or does anyone know of existence or plans > > for such a h/w? > > > > If not, lets junk the src/dst fields and keep burst, length, addr fields > > which point to the peripheral values. > > > > Alternatively if we need both, then we can't have union and Russell's > > idea seems good one :) > > We don't need the union whatever way that goes. Based on comment we need to support both. > > The question over whether we have the src/dst fields is whether we want > to support a different configuration for DMA_DEV_TO_MEM/DMA_MEM_TO_DEV > without having to reconfigure the channel each time its direction is > switched. The biggest issue here is the design of the API. IMO the slave_config should be passed along with respective prepare API for slave and not thru separate slave config. That will remove the unnecessary limitation and allow the same channel to be used for tx for one transfer and rx for subsequent etc. In the .device_prep_slave_sg() we should add the struct slave_config as an argument. Obviously the slave_config will have _one_ pair of members (not both src/dstn fields then). For DMA_DEV_TO_DEV, anyway we need a new API, which can have both src and dstn slave_config Thoughts..? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
