Messages in this thread | | | Subject | Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel() | From | Vinod Koul <> | Date | Wed, 07 Mar 2012 11:58:07 +0530 |
| |
On Tue, 2012-03-06 at 14:03 +0100, Guennadi Liakhovetski wrote: <adding few folks to thread, who i may be intrested in this discussion> > But the DMAC is certainly a better match for making channel-selection > decisions. I am not sure about that as well... > > > Bigger question is who knows about this mapping and how do we > > incorporate this mapping into channel allocation > > The platform does. And this knowledge has to be passed to the relevant > driver. But I think it's the DMAC driver, that is relevant, not the client > driver. The platform would supply information like > > DMAC #1 > channel #1 > (can be used for) device #1 > device #2 > ... > channel #2 > ... > ... right :-) and we need to ensure that somehow this information is presented to dmaengine and dmaengine uses this information to filter the channel requests. In past we had good discussion [1], [2], [3] on this topic but unfortunately nothing came out of it.
I like the approach outlined by Linus W [1], where we can get the information from platform (DT, FW,....) and its presented to dmaengine.
I think we need to solve this _now_. There are two aspects a) to ensure dmaengine understand channel-client mapping. For this we can start with idea in [1] and see if this suits everyones needs b) how to ensure the platform gives this information in variety of arch we have (arm, x86, sh-....)
Thoughts...? > And I don't think, it would be reasonable to let every slave driver use > this information. These lists can also be optimised for specific > platforms. E.g., on some sh-mobile SoCs you have two DMAC types. One of > them can serve devices from list A on any channel, the other one - from > list B. So, all you have to do, is to reference either A or B from your > DMAC platform data. Whereas doing a reverse mapping: for each (potential) > DMA user reference a list of channels, that it can use - would be really > clumsy. > [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/060717.html [2]: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/059212.html [3]: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/059217.html
-- ~Vinod
| |