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

[Stephen Warren]

On 05/10/2012 01:59 PM, Jassi Brar wrote:
> On 10 May 2012 22:30, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 05/09/2012 03:38 PM, Jassi Brar wrote:
> 
>>> One point is about 'qos' here.... something like bandwidth allocation.
>>> If the dmac driver knew up-front the max possible clients that could be
>>> active simultaneously, it could "divide the bandwidth" accordingly.
>>> Again, the example of PL330 employing 2physical channels for better
>>> service - LLI (you got it right), where even 1 physical channel would
>>> also have served only not as reliably. I believe there would be
>>> more such scenarios.
>>
>> QoS seems like policy to me, whereas DT is more about describing the HW.
>> Is DT the correct place to describe QoS policy?
>>
>> I guess you are talking more about deriving policy from the description
>> of HW, i.e. how many client described in DT.
>
> Yeah, that's what I meant.
> 
>> However, for some reason that seems dangerous to me; what if clients
>> can be instantiated some other way?
>
> The other way could be hotplug ?

Yes. Also, there's probably some mix of DT-driven and non-DT-driven
instantiation during the transition to DT, although that's probably
temporary.

> Anyway in those machines every channel would be populated
> and dmac driver would always account for the all-ports-plugged case.
> 
>> For a 1:1 mapping (or 1:n mapping in HW with static selection specified
>> in the DT) between DMA client and DMA controller, perhaps the controller
>> can indeed make QoS decisions based on which (how many) clients are
>> connected to it.
>>
>> However, if a DMA client can be serviced by more than 1 DMA engine, and
>> the decision as to which DMA engine to use occurs at run-time by the DMA
>> driver core, rather than being statically configured in the DT, then the
>> DMA controller drivers cannot know ahead of time which will be used
>
> I think the dmac driver would make use of the routing flexibility to sustain its
> 'qos', and not the other way around (decide qos based on which one of the
> two dmacs would provide a channel to a client in future).
> Anyways, so far only Samsung SoCs seem to have that flexibility/redundancy
> and I have never had anyone asking for that runtime decision making.
> 
>>> The minor difference being, you use the {request-signal, phandle} pair
>>> to find the right channel, I used only 'token'.
>>
>> That's a pretty big difference, I think.
>>
>> In your proposal, every token was globally unique (well, within the 1 DT
>> file). I'd rather not see any more global numbering schemes.
>
> Probably my shallow experience, but "globally unique, within a file" sounds
> like an oxymoron :)

To the kernel, that one file describes everything it knows about the HW
(except for probed information), so it's global:-) Aside from that, I've
often seen the term "global" used relative to some specific scope.

> I think arbitrary numerical tokens are a reasonable price to pay for the
> robustness and simplicity they bring.

I have to disagree here.

Using phandle+ID is almost as simple, and much more flexible. Global IDs
have a number of disadvantages:

a) You have to somehow keep them unique. Even with just a single .dts
file, that's going to be a little painful since there's no central table
of these IDs.

What if the DT is composed of a bunch of chunks that represent pluggable
boards, which may be mixed/matched together depending on what the user
actually plugged in? Then, you have to be very careful to keep the n
different files' numbering ranges segregated, or conflicts will occur.

b) Everything else in DT already uses phandle+ID, so doing the same
thing would be much more familiar and consistent for DT users.

>> Now, DMA requests are signals /from/ a DMA client to a DMA controller
>> ("send more data please", or "pull more data please"). Hence, I assert
>> that the phandle should refer to the DMA client, not the DMA controller.
>
> OK, though we may just want to convey information about the h/w setup
> from the s/w POV, rather than info to simulate the h/w  ;)

DT is specifically about describing the HW from a HW perspective.

> For ex, the dma api and controller drivers don't really care about
> the fact that the client's driver must set some bit to trigger operation,
> whereas some simulator would need to care about that.
> 
> Anyways, I am OK with whatever works well and make things simpler.
> 
>>> Also note that, a client's dma specifier becomes perfectly general
>>> and future-proof
>>>
>>>    client1: spdif {
>>>           dma_tx = <278>
>>>           dma_rx = <723>
>>>     };
>>>
>>> otherwise the following representation
>>>
>>>     client1: spdif {
>>>                dma = <&sdma 2 1 &sdma 3 2>;
>>>      };
>>>
>>> could break with some weird dma setups (IIANW Russell already finds
>>> it wouldn't work for him).
>>
>> To solve Russell's HW, we need some way of representing the mux directly
>> in DT irrespective of how the DMA controller or DMA client specify what
>> they're connected to. Anything else isn't representing the HW in DT.
>>
>> Also, who knows how to control the mux? We need that to be fully
>> general, and so the mux itself really needs some kind of driver which
>> the DMA core or DMA controller can call into when the channel is
>> allocated in order to set up the mux. Right now, Russell's driver calls
>> in the a platform-/board-provided callback, but we should really
>> architect a generic driver framework for this.
>
> Well, I doubt if there would ever be enough such platforms to warrant a
> new generic framework. For now, I would leave that to be a matter between
> the dmac driver and its DT node.
>
> Similarly let every dmac, being unique, require DT data in it's own custom
> format - I don't believe we can find a generic DT format for every kind of
> dmac that does exist or would exist. (For ex, you found a way for RMK's
> mux'ed req_lines, but what about assigning priorities to clients which is
> possible with PL08X dmacs but not most others?)

Good question. Again thought that sounds a little like policy, so
perhaps should be negotiated at runtime rather than described in DT?

> So, I would strive only to make clients' dma specifier generic.
> 
>> client0: i2s {
>>   /* has 2 DMA request output signals: 0, 1 */
>> };
>>
>> client1: spdif {
>>   /* has 2 DMA request signals: 0, 1 */
>> };
>>
> Do we also need to somehow tag these signals for the client to
> differentiate between TX and RX channel ?

Yes, the client's DT binding would certainly need to describe how many
DMA request signals its HW generates, and give a unique ID to each. The
driver would need to request a DMA channel for a specific one of its DMA
requests.