[PATCH] DMA: extend documentation to provide more API details

Guennadi Liakhovetski g.liakhovetski at gmx.de
Tue Oct 8 03:17:35 EDT 2013


On Tue, 8 Oct 2013, Vinod Koul wrote:

> On Mon, Oct 07, 2013 at 10:43:51PM +0200, Guennadi Liakhovetski wrote:
> > On Mon, 7 Oct 2013, Vinod Koul wrote:
> > 
> > > On Mon, Oct 07, 2013 at 05:28:37PM +0200, Guennadi Liakhovetski wrote:
> > > > > > > > > No, not something in the middle. I was thinking about
> > > > > > > > > 
> > > > > > > > > (1) cookie 1-3 are submitted
> > > > > > > > > (2) cookie 1 succeeds
> > > > > > > > > (3) a DMA error occurs, cookies 2-3 are discarded
> > > > > > > discarded using terminate_all right?
> > > > > > 
> > > > > > No, by the dmaengine driver as a part of the error processing.
> > > > > And how will that be done...?
> > > > 
> > > > Sorry, I meant - DMA descriptors with cookies #2 and #3 will be cancelled 
> > > > and recycled by the dmaengine driver. That's what you have to do, when 
> > > > processing DMA error IRQ.
> > > well the term cancel means someone went ahead and requested abort/terminate of a
> > > transaction...
> > > 
> > > As we discussed in other mail on this thread the most common occurrence will be
> > > timeout on client side and client cant cancel selectively.
> > > 
> > > For dma driver detection error, which is quite rare in slave usages, if people
> > > think its common for them we cna indicate this thru status in callback. Then
> > > client will know and doesnt need to query.
> > > 
> > > Recycling cookie has a large space so i dont think we will get confused
> > > with a recycled one
> > 
> > If you reset cookies, as you proposed, IMHO, this can very well lead to a 
> > confusion: suppose cookie #1000 caused an error. We drop queued transfers 
> > with cookies #1001-1005 and reset to #1. When we're at #100 the user asks 
> > for a status of cookie #1003, which we have aborted. However, the 
> > following check in dma_async_is_complete():
> Well you are missing an important point. Who is doing abort. It is the client
> driver, the user.

No. "cookie #1000 caused an error" - a DMA error. The dmaengine driver 
detects it. The user knows nothing about it, so, they cannot call 
terminate_all(). The "we" above refers to the dmaengine driver.

So, that's exactly the case, discussed in the other mail too. And your 
proposed error / status reporting callback will fix this, so, let's do 
that!

Thanks
Guennadi

> And as i said previously before calling terminate_all he will forget about the
> cookies allocated previosuly, So after that he cant invoke any of the old
> cookie. If he is, then that is wrong and needs to be fixed :)
> 
> So while user is dealing with new transactions (cookies), he doesnt know
> anything about old ones and cant query as in above example 1003!
> > 
> > 	if (last_complete <= last_used) {
> > 		if ((cookie <= last_complete) || (cookie > last_used))
> > 			return DMA_SUCCESS;
> > 
> > will confirm success to the user.
> Not in above example!, if you are at #100, query for #1003 will return
> DMA_IN_PROGRESS.
> 
> --
> ~Vinod
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/



More information about the linux-arm-kernel mailing list