RFC: changing DMA slave configuration API
Vinod Koul
vinod.koul at linux.intel.com
Tue Jun 12 02:04:39 EDT 2012
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
More information about the linux-arm-kernel
mailing list