On 2016-02-26 14:45, Peter Ujfalusi wrote:

On 2016-02-26 13:25, Russell King - ARM Linux wrote:

quoted

quoted

quoted

Your original commit adding the original hack that you're now removing
above says that this is to support polled operation: I'm not aware of
DMA engine supporting such a mode.  DMA_PREP_INTERRUPT is a mechanism
where requests can be queued without an interrupt to allow batching.

Also it is used to suppress DMA interrupts during audio playback for example.
In this case we will run w/o interrupts and the position is polled.

quoted

See the raid5/async_tx code, which queues a set of operations without
DMA_PREP_INTERRUPT, with the final operation with DMA_PREP_INTERRUPT
set.

We only allow the interrupts to be disabled in cyclic or memcpy mode. With
slave_sg we have interrupts as it is needed to move to the next SG.

quoted

As the driver is reliant on interrupts to move to the next transfer,
the patch which causes DMA_PREP_INTERRUPT to influence whether
interrupts are sent is actually buggy, and will prevent several
queued DMA operations to fail.

Yes, the omap-dma only allows the interrupts to be actually disabled when it
is save to do so. slave_sg can not work w/o interrupts so there we don't
disable them.

I get the impression that you haven't taken in what I've said, because
each fragment of your reply is just repeating what the previous fragment
said.

Sorry about that. I got it.

quoted

Let me state that I don't believe you need any hacks here, and this patch
is not necessary: the final operation in a set of chained memcpy()s should
have DMA_PREP_INTERRUPT set.

calling the omap_dma_callback() from the tx_status() was a bad idea, this is
why I'm fixing it.

The reason that we need to be able to determine if the channel is done with
the copy by polling the tx_status is: we need to read and write tiler
registers with DMA on dra7 as per one ERRATA document. This read/write can be
executed in interrupt context so we can not rely on DMA callback to be
notified about the completion of the read/write.

As for the DMA_PREP_INTERRUPT not enabling interrupt was introduced by:
4ce98c0a20bef (dmaengine: omap-dma: Add support for memcpy)

While we do not have users submitting multiple descriptors I agree that this
is a possibility and the driver should not fail in such a case.
I can send a followup patch to fix the omap_dma_prep_dma_memcpy()

With the updated patch based on your comments I can fix the polling in the
tx_status callback and with a separate patch I can address your concern
regarding to multiple transfers queued with only the last one having
DMA_PREP_INTERRUPT (and callback provided).

-- 
P?ter