Re: [PATCH] dmaengine: dmatest: Add support for completion polling

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

On 04/06/2019 15.45, Vinod Koul wrote:
> On 03-06-19, 10:05, Peter Ujfalusi wrote:
> 
>>> I think the main question is how polling for completion should be
>>> handled when client does not request for completion interrupt, thus we
>>> will have no callback in the DMA driver when the transfer is completed.
>>>
>>> If DMA_PREP_INTERRUPT is set for the tx_descriptor then the polling will
>>> wait until the DMA driver internally receives the interrupt that the
>>> transfer is done and sets the cookie to completed state.
>>>
>>> However if DMA_PREP_INTERRUPT is not set, the DMA driver will not get
>>> notification from the HW that is the transfer is done, the only way to
>>> know is to check the tx_status and based on the residue (if it is 0 then
>>> it is done) decide what to tell the client.
>>>
>>> Should the client call dmaengine_terminate_* after the polling returned
>>> unconditionally to free up the descriptor?
>>
>> This is how omap-dma is handling the polled memcpy support.
> 
> Yes that is a good question. Even if the client does not set
> DMA_PREP_INTERRUPT would there be no interrupt generated by controller
> on txn completion? If not how will next txn be submitted to the
> hardware.
> 
> I think we should view DMA_PREP_INTERRUPT from client pov, but
> controller cannot get away with disabling interrupts IMO.

What happens if client is issuing a DMA memcpy (short one) while
interrupts are disabled?

The user for this is:
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c

commit: f5b9930b85dc6319fd6bcc259e447eff62fc691c

The interrupt based completion is not going to work in some cases, the
DMA driver should obey that the missing DMA_PREP_INTERRUPT really
implies that interrupts can not be used.

> Assuming I had enough caffeine before I thought process, then client would
> poll descriptor status using cookie and should free up once the cookie
> is freed, makes sense?

OK, so clients are expected to call dmaengine_terminate_*
unconditionally after the transfer is completed, right?

If we use interrupts then the handler would anyway free up the
descriptor, so terminating should not do any harm, if we can not have
interrupts then terminate will clear up the completed descriptor
proactively.

In any case I have updated the EDMA patch to do the same thing in case
of polling w/o interrupts as it would do in the completion irq handler,
and similar approach prepared for omap-dma as well.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki