On 05/04/2012 09:06 AM, Jon Hunter wrote:
> Hi Stephen,
>
> On 05/03/2012 05:26 PM, Stephen Warren wrote:
>> On 04/30/2012 03:17 PM, Jon Hunter wrote:
>>> From: Jon Hunter <jon-hunter@xxxxxx>
>>>
>>> This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
>>> to add some basic helpers to retrieve a DMA controller device_node and the
>>> DMA request/channel information.
...
>>> +
>>> + sdma: dmaengine@48000000 {
>>> + compatible = "ti,omap4-sdma"
>>> + reg = <0x48000000 0x1000>;
>>> + interrupts = <4>;
>>> + #dma-cells = <2>;
>>> + #dma-channels = <32>;
>>> + #dma-requests = <127>;
>>> + };
>>> +
>>> +
>>> +* DMA client
>>> +
>>> +Client drivers should specify the DMA property using a phandle to the controller
>>> +followed by the number of DMA request/channel and the transfer type of the
>>
>> What exactly is "request/channel"? Is it a request ID, a channel ID,
>> both packed into a single integer (which bits are used for each field),
>> etc.?
>
> The thought here was that some DMAs may distinguish between devices by a
> request ID or a channel ID or both. In the case of say an OMAP4, we have
> 32 channels and 127 request IDs. From a h/w perspective we need to know
> both. Each of the 32 channels can be programmed to use any one of the
> 127 h/w request signals.
>From a HW perspective, do you actually need to know both? I think the HW
description must specify the request ID, but because any channel can be
programmed to any request ID, you don't actually care about the channel
ID; it can be dynamically allocated by the DMA driver when the client
driver calls dma_request_channel().
Actually, you say the following below, so I guess you already agree here:
> Yes this is the same as OMAPs SDMA. In the case of such DMA controllers
> you only really care about the request ID and total number of channels
> that are available to you.
...
>> This is why I think DMA controller should specify the format of their
>> own DMA specifier in DT, and why they should provide an xlate function
>> to parse that.
>
> Ok fair enough. However, it seems that at a minimum we could provide one
> or two xlate functions in the generic binding for people to use. One
> could be the DMA engine xlate binding and another could be the simple
> xlate binding Nicolas proposed for a DMA controller that returns a
> single channel/request ID.
>
> However, at the same time, may be people would prefer that devices such
> as tegra, omap, at91, etc, offer their own xlate function for DMA
> engine. I am not sure, but we could go either way.
I'd expect the bindings to be written to allow the individual DMA
controllers to have complete control over the meaning of the DMA specifier.
That said, I would certainly expect some common patterns to emerge, such
as a single cell to specify the DMA channel ID, or a single cell to
specify the DMA request/selector ID. We should certainly make sure that
where different controllers need the same information, they use the same
way to represent it, and use common utility code to implement the xlate
functionality. We could perhaps even write these common cases into the
core DMA bindings as examples to help ensure uniformity. However, we
just need to do this in a way that allows other cases too.
--
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
