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
