Tearing down DMA transfer setup after DMA client has finished

Sebastian Frias [off-list ref] writes:

On 09/12/16 07:59, Vinod Koul wrote:

quoted

On Thu, Dec 08, 2016 at 04:48:18PM +0000, M?ns Rullg?rd wrote:

quoted

Vinod Koul [off-list ref] writes:

quoted

To make it efficient, disregarding your Sbox HW issue, the solution is
virtual channels. You can delink physical channels and virtual channels. If
one has SW controlled MUX then a channel can service any client. For few
controllers request lines are hard wired so they cant use any channel. But
if you dont have this restriction then driver can queue up many transactions
from different controllers.

Have you been paying attention at all?  This exactly what the driver
ALREADY DOES.

And have you read what the question was?

I wrote the driver.  I think I know what Mason and I are asking.

I think many people appreciate the quick turn around time and
responsiveness of knowledgeable people making constructive remarks in
this thread, but it looks we are slowly drifting away from the main
problem.

If we had to sum up the discussion, the current DMA API/framework in
Linux seems to lack a way to properly handle this HW (or if it has a
way, the information got lost somewhere).

What concrete solution do you propose?

Alternatively, one can think of the current issue (i.e.: the fact that
the IRQ arrives "too soon") in a different way.  Instead of thinking
the IRQ indicates "transfer complete", it is indicating "ready to
accept another command", which in practice (and with proper API
support) can translate into efficient queuing of DMA operations.

For multiple back to back transfers to the same peripheral, it is indeed
a slight optimisation.  What's apparently lacking is some way of doing a
full flush at the end of a series of transfers, before switching the
channel to another device.

-- 
M?ns Rullg?rd