On Thu, 2012-07-26 at 12:43 -0500, Jon Hunter wrote:

quoted

quoted

So yes I can see that a channel itself could be configured to

support a

quoted

quoted

given direction, but when we ask for a channel via

dma_request_channel()

quoted

quoted

we are going to get a channel that matches the criteria we pass

using

quoted

quoted

the filter parameter. So here the thinking was that "flags" is a

filter

quoted

quoted

parameter that the user could specify and one example being

direction

quoted

quoted

but it could be something else too.

Yes that can be done, but I am leaning towards clients not have to

do

quoted

anything :) DMAEngine needs to know mapping and when
dma_request_channel() is called it _always_ gives you the right

channel.

Ok, so are you proposing to remove the filter function and parameter
from the dma_request_channel()?

No. But add a new request call, dma_request_slave_channel() which is
exclusive for slave usages and takes into account the mapping to be done
for channels

quoted

Maybe for slave case we need to create dma_request_slave_channel()

which

quoted

has additional arguments for dmaengine to do the filtering.

Yup

Ok, so what is not clear to me is if you envision that
dma_request_slave_channel() is using a mapping table based look-up or
the DT scheme or both.

The API should not worry about it. It would be good to have DT/ other be
behind this API, so it is transparent to users. They just request a
slave channel.

As Arnd highlighted the DT convention is to store the DMA info in each
of the device nodes and not store in a global mapping table which
conflicts with having a mapping table approach for non-DT usage. So I
am
still not sure how you envision this function working for both the
non-DT and DT use-cases. 

I expect the clients to pass the mapping information to dmaengine in way
dmaengine understands. This information can come from DT or other
places. That way dmaengine gets info from any system being used and be
able to allocate slave channel properly.
-- 
~Vinod