Re: [PATCH V4 2/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

On 19/04/16 15:18, Arnd Bergmann wrote:
> On Tuesday 19 April 2016 14:59:49 Jon Hunter wrote:
>> On 19/04/16 14:25, Vinod Koul wrote:
>>> On Mon, Apr 18, 2016 at 04:06:23PM +0100, Jon Hunter wrote:
>>>> On 14/04/16 12:04, Jon Hunter wrote:
>>>>> I had a look at this, but actually, I don't think this is going to work.
>>>>>
>>>>> Looking at dma_request_channel(), it is going to get a DMA channel that
>>>>> matches the mask for any DMA controller. In the xlate I already know
>>>>> which DMA controller I am and I just want one of the channels. The flow
>>>>> here is ...
>>>>>
>>>>> dma_request_chan()
>>>>>   --> of_dma_request_slave_channel()
>>>>>     --> xlate()
>>>>>       --> dma_get_any_slave_channel()
>>>>>
>>>>> There are several other DMA drivers that are calling
>>>>> dma_get_any_slave_channel() from their xlate function which makes sense
>>>>> because they are requesting one of their own channels.
>>>>>
>>>>> I can understand that you wish to consolidate the APIs for requesting a
>>>>> channel, but it seems to me that you still need to have an API that DMA
>>>>> controller drivers can call where they can pass their dma_device
>>>>> structure to ensure you get a channel for the appropriate DMA controller.
>>>
>>> Yes but the idea was that xlate will help you to get the right channel. The
>>> whole dmaengine property was supposed to help you with that
>>
>> Well it depends on the DMA controller. In the case of tegra the xlate
>> helps you extract the slave request ID for a given device. However,
>> because any channel can be used with any slave request ID, we don't care
>> about the exact channel. So we request any available channel for the DMA
>> controller in question and program it with the slave request we got from
>> the xlate.
> 
> Right. the cleanup was supposed to reduce the number of interfaces
> that a slave driver can call and consolidate them as much as possible
> into dma_request_chan(), but we still need dma_get_any_slave_channel()
> as an interface for the dmaengine masters as you said.

OK, great.

Vinod, are you ok with this then? Any other items to fix-up?

>> I have seen some DMA drivers (such as imx-dma) use the filter function
>> to match the DMA controller, but it seems daft to use the filter
>> function to match the DMA controller when we already know in the xlate
>> which DMA controller we are.
> 
> The filter functions should ideally all go away after the cleanup
> is complete.

Wonderful! Thanks for the info.

Cheers
Jon