[PATCH V3 1/2] of: Add generic device tree DMA helpers

[Jon Hunter]

Hi Arnd,

On 06/08/2012 07:04 PM, Arnd Bergmann wrote:
> On Friday 08 June 2012, Jon Hunter wrote:
>> On 05/21/2012 03:32 PM, Stephen Warren wrote:
>>> On 05/21/2012 12:18 PM, Arnd Bergmann wrote:
>>>> On Monday 21 May 2012, Stephen Warren wrote:
>>>>>
>>>>> If so, that seems a little odd; you have to request a DMA channel for
>>>>> "TX", but then end up having the common code check all the entries in
>>>>> the dmas property since it can't know which are TX, and then have the
>>>>> wrong ones almost accidentally fail, since the DMAC will then determine
>>>>> that it can't support TX on the RX DMA request IDs.
>>>>
>>>> I think the direction must be encoded in a way that does not depend on
>>>> the binding for the specific controller. There are two ways I can see
>>>> how we might do it:
>>>>
>>>> 1. have separate property names for tx and rx channels, and probably
>>>>    one for combined rx/tx channels
>>>
>>>> 2. define the second cell in each channel specifier to be the direction
>>>>    in a predefined format, followed by the other (controller specific)
>>>>    attributes, if any.
>>>
>>> In this option, lets say bit 0 is 0==TX, 1==RX (or perhaps 2 bits if
>>> combined TX/RX is needed)
>>>
>>> Then, we could reserve say bits 7:1 as client DMA request ID.
>>>
>>> And then have bits 31:8 as DMAC specific data.
>>>
>>> Wouldn't that allow us to have our cake and eat it?
>>
>> Sorry for not responding sooner.
>>
>> It seems to me we were pretty close on alignment. In fact, I was quite
>> happy with Steven's 2nd to last proposal of  ...
>>
>> simple 1 req:
>> dmas = <0 &dmac1 xxx>;
>>
>> simple 2 req:
>> dmas = <0 &dmac1 xxx 1 &dmac1 yyy>;
>>
>> multiple dmacs:
>> dmas = <0 &dmac1 xxx 0 &dmac2 zzz 1 &dmac1 yyy>;
>>
>> Arnd, I know that you had some concerns. However, in the above case I
>> would expect that the 3rd parameter be optional and it can be some sort
>> of match variable. In other words, we don't care how the 32-bits are
>> encoded or what they represent but they would be used appropriately by
>> the xlate function being used. So the xlate and this "match" variable
>> would have to speak the same language.
> 
> I would at least put the &dmac part first to be consistent with other
> bindings that refer to some node. That controller should then be
> able to specify the number of additional cells used to describe the
> dma request. We can define that the first cell after the controller
> phandle is always the same thing, e.g. the direction (in/out/inout)
> or a client-specific ID or a combination of that with other predefined
> bits that are not dependent on dma controller specifics.

I agree with putting the &dmac phandle first, that makes sense.

> As I said previously, I think just encoding the direction but not
> the client specific ID (meaning we would have to disambiguate
> the more complex cases that Stephen mentioned using a dma-names
> property) would be the best because it keeps the common case simple,
> but I could live with other things going in there too.

Ok, so you are saying that there are some DMA controllers where there is
no channel/request ID and only a direction is needed? So an even simpler
case than what I had imagined.

So in that case, I don't see why the first cell after the phandle could
not be an index which could be either a direction or request-id and then
the next cell after that be a secondary match variable.

So simple case with just a index (either req-id or direction) ...

dmas = <&dmac0 index>

More complex case ...

dmas = <&dmac0 index match>

For example, for OMAP index = req-id and match = direction ...

dmas = <&dmac0 req-id direction>

Or am I way off the page?

Cheers
Jon