On 12 May 2012 00:58, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> On 05/10/2012 01:59 PM, Jassi Brar wrote:
>
>> 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.
>
You might want to revisit this point after working out the finer details of what
you propose for a client's specifier :)
>>
>> 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?
>
As much as we love everything to be runtime configurable, I am afraid it
can't be. We can't add new calls to the dmaengine api for simply
supporting specific features of various dmacs (priority in this case)
Because that would mean ideally every client going through the mostly
useless ritual of querying/setting those features and most dmacs
just 'pretending' to support some, except for the rare ones that actually do.
So as much as these sound like policy, they would usually be directly
hardcoded via dt for the machine or deducted by the dmac driver.
>>
>>> 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.
>
Did I read "give a unique ID to each" correctly ?
Could you please take some time out to jot down an example of how a
typical client's dma specifier should look.
FWIW, I think I can live with what you propose. Let us go for the kill.
Thanks.
--
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
