Hi Vinod,
On 07/31/2012 06:12 AM, Vinod Koul wrote:
> On Thu, 2012-07-26 at 12:43 -0500, Jon Hunter wrote:
>>>> So yes I can see that a channel itself could be configured to
>> support a
>>>> given direction, but when we ask for a channel via
>> dma_request_channel()
>>>> we are going to get a channel that matches the criteria we pass
>> using
>>>> the filter parameter. So here the thinking was that "flags" is a
>> filter
>>>> parameter that the user could specify and one example being
>> direction
>>>> but it could be something else too.
>>> Yes that can be done, but I am leaning towards clients not have to
>> do
>>> 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
>>
>>> Maybe for slave case we need to create dma_request_slave_channel()
>> which
>>> 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.
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.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
