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

[Vinod Koul <vkoul@kernel.org>]

On 04-06-19, 16:35, Peter Ujfalusi wrote:
> 
> 
> 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.

well yes but how do we *assume* completion and issue subsequent txns?
Does driver create a task and poll?

> 
> > 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?

How do you know/detect transfer is completed?
> 
> 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.

yes terminate part is fine.

> 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

-- 
~Vinod