[PATCH/RFC 1/4] dma: add a function to request a DMA channel for a specific client

[Guennadi Liakhovetski]

On Fri, 3 Aug 2012, Vinod Koul wrote:

> On Thu, 2012-08-02 at 11:11 +0200, Guennadi Liakhovetski wrote:
> > > > +           chan = device->mux->request_chan(device, dev, direction, name);
> > > NAK
> > > 
> > > 1. We dont want dmacs to have anything to do with filtering and
> > > allocating. That is role of dmaengien and we need to add stuff there
> > > only.
> > > 2. Even if we start using optional name argument here we still don't
> > > know out of 4 channels dmac supports which one to allocate.
> > 
> > I don't think we can be generic enough in the dmaengine core to identify 
> > which channels are suitable for all slave requests. This is why I proposed 
> > a concept of a DMA channel multiplexer driver, and this is exactly what 
> > this callback is. I tried to explain this in the patch description above. 
> > I thought we discussed this earlier in this thread and agreed, that a 
> > multiplexer API is the way to go with channel allocation. I think, I 
> > mentioned in one of my mails, that in the beginning I wanted to implement 
> > multiplexers as a proper (platform) device, but at least one problem with 
> > this is, that at least on my hardware the multiplexer and the DMAC share 
> > registers, and an MFD seems an overkill for this, but we can discuss this. 
> > I don't know, whether there are systems, where multiplexers are really 
> > separate hardware blocks, if there are, we can think of a way to handle 
> > those nicely too.
> I would disagree.
> 
> As I have said in past, we need the mapping information to be available
> with dmaengine for slave channels even before any slave allocation
> occurs. This way dmaengine knows what to do with a channel.

I think, this depends on our interpretation of what struct dma_chan 
represents and who has control over it. If we think, that this is a 
purely software object, which at allocation time has absolutely no 
hardware association attached to it, then yes, only the dmaengine core 
should manage them at least at that time. If, however, we define, that 
struct dma_chan _can_ get hardware association already at allocation time 
in the context of DMAC's .alloc_chan_resources() function, then it's 
the DMAC that has to manage them.

And, I think, there is one important aspect to this, that tells us, that 
those channels cannot be absolutely hardware-agnostic: they are attached 
to DMAC instances. So, they intrinsically have some hardware association.

So, you have to take into account hardware limitations already at 
allocation time. You can do this by either asking the DMAC, whether a 
certain allocation can be performed (what we currently do with filters, 
and what this patch proposed to do with the multiplexer callback), or you 
can require some static information from DMACs, like a mapping that you 
propose.

Currently both approaches seem possible, however, a static mapping seems 
less flexible to me, I don't know whether it can describe all available 
hardware configurations. We shouldn't forget, that those mappings can be 
many-to-many, as in the sh-dma example. On sh-dma it would suffice and be 
optimal enough to have a pointer to a slave list in struct dma_chan. Would 
this also suit everyone else? Is this what you're thinking about?

Thanks
Guennadi

> I am planning to add the support in dmanegine for this...
> 
> The problem with this solution here is again how the hell will a dmac
> know what to do with alloc request. It doesn't and any current way it
> does is just a hack and nothing else. This also prevenrts us form
> building genric dmac driver which should only know how to deal with dmac
> only and nothing else.
> 
> -- 
> ~Vinod
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/