Re: [PATCH] dmaengine: add dmanegine slave map api's

[Vinod Koul]

On Mon, 2012-09-17 at 22:57 +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 17, 2012 at 03:20:29PM +0530, Vinod Koul wrote:
> > On Mon, 2012-09-17 at 09:36 +0100, Russell King - ARM Linux wrote:
> > > > > I'm not saying take the slave_id out of the map.  I'm saying, let the
> > > > > DMA engine driver itself figure out what dma_chan to return. 
> > > > But wont that assume the dma controller knows which channel to allocate.
> > > > And how would it know this information? This can be problematic for hard
> > > > wired muxes, but can be easily done for controller which have
> > > > programmable mux.
> > > 
> > > Well, as I have already said, at the moment you're returning the _first_
> > > _free_ _channel_ on a DMA device, which almost certainly will always be
> > > the wrong one. 
> > Yes I overlooked, the continue is wrong. It needs to move to next
> > available channel. I have fixed it.
> > 
> > Now on the question if we should allow dmaengine to select channel or
> > let dma engine driver do that, I don't see how that helps for hard wired
> > muxes where dma engine driver doesn't know anything of mapping.
> > 
> > For your OMAP dma this wont matter as I think you have a programmable
> > mux so you maybe able to use any channel with rightly programmed mux,
> > right?
> 
> Except that we expose one 'channel' per mux setting, so as far as DMA
> engine goes, the mux number _is_ the channel number - which is the same
> approach taken by the PL08x and sa11x0 DMA engine drivers.  It is the
> only sane approach to dealing with N hardware channels vs >>N clients.
Sure that makes things easy in dmaengine code.

So we allocate channel number given by slave id (if set) or first free
channel. This would also mean people need to update their drivers to use
virtual channel which indeed is a good idea :)

-- 
~Vinod

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/