Messages in this thread | | | Date | Mon, 19 Mar 2012 15:45:45 +0100 (CET) | From | Guennadi Liakhovetski <> | Subject | Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel() |
| |
On Mon, 19 Mar 2012, Vinod Koul wrote:
> On Mon, 2012-03-19 at 15:09 +0100, Guennadi Liakhovetski wrote: > > YES! This is exactly what I am talking about! We need an additional > > parameter to dma_request_channel(). Whereas in the discussion, that you > > pointed me to, it still had the same 3 parameters, as now. (Maybe this has > > already been decided upon before - to add an additional parameter, not > > sure anymore, this thread has become too long and too slow... My apologies > > in this case) So, this can be a device pointer or some specialised slave > > ID. Device pointer is nice, I agree. And the next change, that I'd like to > > request is pass this parameter further on to DMA device driver's > > .device_alloc_chan_resources() method. > Sorry my bad. I confused your request for additional parameter as > request for adding slave_config etc stuff into request API. > > Yes this API would need to be modified for telling dmaengine about > client. Now Given that this is more slave stuff, I have leaning to > adding a slave specific request api, something like > dmaengine_request_slave_channel() which is used for our purpose while > keeping the original API intact for async_tx usages. > > Btw why should .device_alloc_chan_resources() need this, I so no reason, > unless we are working around some other issue.
The reason is the following: with the proposed modifications to the existing API we want to achieve:
1. client requests a channel dmaengine_request_slave_channel(dev) 2. the core looks through platform-specific mapping tables and finds a suitable channel 3. the core calls device driver's .device_alloc_chan_resources() method for that channel 4. the client uses dmaengine_slave_config(chan, config) to configure the channel
Now, that last channel configuration can have two aspects: (1) static: routing, multiplexing, peripheral address. This needs to be set only once per each such channel allocation to a specific client, (2) (potentially) dynamic: any burst sizes etc. We can pass both these configuration types together to the DMA device driver at step 4. For that the slave would have to embed struct dma_slave_config into another hardware-specific type with additional routing parameters. Otherwise we could pass static configuration, supplied by the platform, from the client to the DMA device driver already at step 1. This way we would avoid having to embed struct dma_slave_config and pass it around even if the driver doesn't actually use it. In some cases step 4 would be then dropped completely. But I can live with either solution.
Another reason is, that in the future it can happen, that we get further restrictions on channel selection, that will not fit into the standard mapping scheme. In this case, having access to slave's identification, the DMA device driver will have another chance to check, whether the proposed channel is indeed suitable.
BTW, if we only pass a device pointer and return to the client channels one-by-one, how will the client know, which channel it just has got back - Tx or Rx? Will it have to try to configure it for each role and see, which one succeeds?...
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
| |