On 05/10/2012 01:59 PM, Jassi Brar wrote:

On 10 May 2012 22:30, Stephen Warren [off-list ref] wrote:

quoted

On 05/09/2012 03:38 PM, Jassi Brar wrote:

quoted

quoted

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.

quoted

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.

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

quoted

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.

quoted

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.