On 5 May 2012 00:53, Arnd Bergmann [off-list ref] wrote:

On Friday 04 May 2012, Jassi Brar wrote:

quoted

I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.

I think such client->req_line map should be provided to the dmac controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.

Ideally the I2C driver should simply ask, say, a channel for TX and another
for RX, everything else should already be setup via dmac's dt nodes.

If I understand you correctly, you think we can generalize the dma-request
data in a way that we don't need to pass a specific dma engine phandle.
I very much doubt this is possible, given how different the requirements
are for each of the engines we support. You really need to pass a specific
phandle so that we can find the code that can interpret the data in a
meaningful way.

Hmm... there ought to be a way by which a client is handed a random 'token'
via its dt node and similarly the dmac informed which channel (and with what
capabilities) to allocate should it see a request coming with that token.

That way dmac and client drivers using DT could do away with the filter_fn.

Roughly speaking (I am not very well versed with DT syntax)

Client Node:-

mmc1: mmc@13002000 {
        ...
        dma_tx = <891>   //some platform-wide unique value
        dma_rx = <927>   //some platform-wide unique value
        ...
 };


Say the PL330 chapter of SoC's trm specifies that "channel_id" for
MMC1_TX is 7 and MMC1_RX is 8 on second instance of PL330.

DMAC's Node:-

pdma2: pdma@10800000 {
         .......
        dma_map = <891, 7>,       //Map mmc1_tx onto i/f 7
                              <927, 8>,      //Map mmc1_rx onto i/f 8
                              <487, 9>,      // Map other dma clients
                                    .......
};

The dma_map could also encode features like duplex, priority etc
depending on the needs of the client and capability of the dmac.
(The "channel_id" could very well be an composite value specifying
more than one parameter.... basically a value private to the dmac driver)

As a positive side effect, the dmac controller could populate channels only
for which some client exists on the machine.

Also the decision to map a client onto one of two or more supporting dmacs
is made here - token 927 wouldn't appear in dma_map of pdma1 even
if it also could do RX for MMC1.

The solution seems so simple that I am already cringing at the thought
of having overlooked something fundamental. Please clarify :)