dmaengine: usage of dmaengine_get() and dma_find_channel()

[Federico Vaga <federico.vaga@cern.ch>]

Hello,

I am a bit puzzle about the proper usage these two functions:

void dmaengine_get(void)
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type)

Looking into the kernel sources dma_find_channel is not used, despite the fact 
that it looks as one of the suggested mechanism to access a DMA engine. So, I 
cannot find a valid example of its usage.

The same for dmaengine_get(). On the other hand, at least this function is 
used in: drivers/video/fbdev/mx3fb.c. But I believe that its usage is wrong 
because it uses: dmaengine_get() + dma_request_channel(), instead of 
dmaengine_get() + dma_find_channel().

Reading the code my understanding is that dmaengine_get() + dma_find_channel() 
should be used for "public" (not private) DMA engine channels.

It's here where things are getting obscure to me. My understanding is that DMA 
channels which are not private can be used by several drivers at the same 
time. In principle they submit all their transfers and the DMA engine will 
process them and then the DMA engine will notify the drivers about their 
completion.

My understanding is also that the dmaengine subsystem assumes that "public" 
channels of the same type are interchangeable.

In my use case I wrote a DMA engine which is specific for a subset of driver, 
and it cannot be used by others (so is sharable among a group of drivers). All 
these drivers, potentially, they can submit their transfers to the DMA engine 
in parallel; but I cannot do it because I'm forced to use 
dma_request_channel() in order to be able to filter the DMA channels, and this 
will make automatically the channel PRIVATE which prevents other drivers to 
use the same channel.

With the current API I do not see alternative for me. I have to use 
dma_request_channel() in order to filter DMA channels. But I am wondering if 
it make sense for you, and if it does, is there a solution today? Or, is it 
possibile to design one?

Thanks (I do not know if this message is clear enough)