On Mon, Oct 17, 2011 at 11:53 AM, Jassi Brar
[off-list ref] wrote:

=20
On 15 October 2011 23:05, Vinod Koul [off-list ref] wrote:
=20

quoted

Another alternate approach could be to add one more argument to
prep_slave_sg API which allows us to pass additional runtime

specific

quoted

parameters. This can be NULL and unused for existing drivers and

used

in

quoted

RIO and any future subsystems which want to use dmaengine.
Thoughts...?

That doesn't sound much different than passing the data via
dma_chan.private during prep_slave_sg. Only now we add to
the number of arguments.

One dma_chan may be used by multiple drivers requesting data transfer.
In this case we will need a lock to keep dma_chan and its private
coupled together.=20
If we consider this coupling as a valid way we may think about
adding a lock member into dma_chan structure. This will make locking
more effective for configurations with multiple DMA channels.=20

And then either this argument would be RapidIO specific (unfair
to other users) or generic. In latter case what would it look like ?

It should not be RapidIO specific. Just transfer specific context that
will be interpreted by participants. Given that we have a channel
filtering mechanism there is a little chance of wrongful usage of
that parameter.

Alex.