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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux