Re: Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård
Date: Fri Dec 09 2016 - 06:34:51 EST
Sebastian Frias <sf84@xxxxxxxxxxx> writes:
> On 09/12/16 07:59, Vinod Koul wrote:
>> On Thu, Dec 08, 2016 at 04:48:18PM +0000, Måns Rullgård wrote:
>>> Vinod Koul <vinod.koul@xxxxxxxxx> writes:
>>>> 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
> 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