On 10 May 2012 22:30, Stephen Warren <swarren@xxxxxxxxxxxxx> 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 ?
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 :)
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.
>>
>> 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 ?
--
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
