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

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

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.

However, for some reason that seems dangerous to me; what if clients
can be instantiated some other way?

The other way could be hotplug ?
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.

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 :)
I think arbitrary numerical tokens are a reasonable price to pay for the
robustness and simplicity they bring.

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  ;)
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

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?)

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 ?