On Wed, 2012-08-01 at 15:43 -0500, Jon Hunter wrote:

Hi Vinod,

On 07/31/2012 06:12 AM, Vinod Koul wrote:

quoted

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

quoted

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

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

quoted

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.

So would you envision something like (copying from Guennadi's API but
changing direction to flags) ...

struct dma_chan *dma_request_slave_channel(struct device *dev,
					char *name, unsigned int flags)
{
	/* If device-tree is present get slave info from here */
	if (dev->of_node)
		return of_dma_request_slave_channel(dev, name, flags);

	return NULL;
}

Ok, so right now the above is nothing more than a simple wrapper around
a DT dma function to extract the slave info. However, it would allow us
to add another means for getting the slave info in the future if
necessary by adding an else part to the above.

Yup, something like above should work well. But without any dependency
from dmac's (unlike the RFC propsed)


-- 
~Vinod