Re: [PATCH/RFC] dmaengine: add a slave parameter to__dma_request_channel()

[Vinod Koul]

On Mon, 2012-03-19 at 15:45 +0100, Guennadi Liakhovetski wrote:
> > 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,
correct

>  (2) (potentially) 
> dynamic: any burst sizes etc.
I dont think burst-size would be dynamic, are they on sh- ?

>  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.
I think most of generic parameters are already there. As long as you
dont have abnormal controller current dma_slave_config should suffice.
Again, if you have specific need pls let us know, this structure can &
should be expanded if dmacs needs something for slave configuration.

>  Otherwise we could pass static 
> configuration, supplied by the platform,
platform, where is that coming into configuration discussion. Platforms
role is only for *mapping* and not for configuration.
>  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.
DMAC do not and should not check that. It is again job of client to
check that.
I know sh- doesnt do it this way, but after we sort of mapping, I expect
this to be gone. DMACs should not know anything about clients.

> 
> 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?...
There are few options and considerations:
a) if platform map forces you to use specific channel for TX and
specific one for RX, then you should have mapping explicitly tell you
about RX and TX channels.
b) if not, then you should get a channel which can work with a client.
And then use direction to find about TX and RX for a descriptor. I know
some controller can use same channel for both RX and TX.

-- 
~Vinod

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/