Hi Jassi,
On 05/04/2012 02:01 PM, Jassi Brar wrote:
> On 4 May 2012 20:47, Jon Hunter <jon-hunter@xxxxxx> wrote:
>> Hi Jassi,
>>
>> On 05/04/2012 01:56 AM, Jassi Brar wrote:
>>> On 1 May 2012 02:47, Jon Hunter <jon-hunter@xxxxxx> 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.
>>>>
>>>> Aim of DMA helpers
>>>> - The purpose of device-tree (as far as I understand), is to describe the
>>>> capabilites of the hardware. Thinking about DMA controllers purely from the
>>>> context of the hardware to begin with, we can describe a device in terms of
>>>> a DMA controller as follows ...
>>>> 1. Number of DMA controllers
>>>> 2. Number of channels (maybe physical or logical)
>>>> 3. Mapping of DMA requests signals to DMA controller
>>>> 4. Number of DMA interrupts
>>>> 5. Mapping of DMA interrupts to channels
>>>> - With the above in mind the aim of the DT DMA helper functions is to extract
>>>> the above information from the DT and provide to the appropriate driver.
>>>> However, due to the vast number of DMA controllers and not all are using a
>>>> common driver (such as DMA Engine) it has been seen that this is not a
>>>> trivial task.
>>>>
>>> Sorry for being slow, but so far I thought DT is only to provide _h/w_
>>> specific info
>>> to the _controller_ drivers. It was not supposed to provide any info
>>> pertaining to
>>> some API (dmaengine in this case).
>>>
>>> And I believe this is one of few situations where we are better off
>>> not generalizing
>>> the interface - pass controller specific info in the controller
>>> driver's specified format.
>>> Generalizing only seems to complicate things here, when we anyway have machine
>>> specific dtb, which could always have clients requesting and the
>>> controllers given
>>> dma's info in controller driver's specific format.
>>>
>>> Perhaps I am overlooking the need to generalize. If you think so, please help me
>>> understand by pointing out some use case for it.
>>
>> No not really, your points are valid. From reading the previous
>> discussions one of the items that was clearly lacking was the ability to
>> represent and identify a device having more than one DMA controller. In
>> other words, when you request the DMA resource, how do you identify
>> which DMA controller in the system that resource belongs too. With DMA
>> engine there are ways we can do this.
>>
> Well, if we really can't have dmac drivers make 'intelligent' runtime decision
> of request mapping on more than one capable controllers, we still can
> make it simpler than the proposed scheme.
>
> + i2c1: i2c@1 {
> + ...
> + dma = <&sdma 2 1 &sdma 3 2>;
> + ...
> + };
>>
> I see this requires a client driver to specify a particular req_line on a
> particular dma controller. I am not sure if this is most optimal.
Actually, no. The phandle in the DT specifies the DMA controller to use.
Then the client simply asks for a channel with a particular property,
for example, DMA_MEM_TO_DEV (ie. TX) and the channel information is return.
> I think such client->req_line map should be provided to the dmac controller
> driver via its dt node in some format. The dmac driver could then populate
> a dma_chan, or similar, only for that req_line and not for the unused one
> which otherwise could also have served the same client.
>
> Ideally the I2C driver should simply ask, say, a channel for TX and another
> for RX, everything else should already be setup via dmac's dt nodes.
Yes that is the intention here.
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
