[lkml]   [2013]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 01/28] dmaengine: use DMA_COMPLETE for dma completion status
On Thu, Oct 17, 2013 at 10:27:13AM +0200, Guennadi Liakhovetski wrote:
> On Thu, 17 Oct 2013, Vinod Koul wrote:
> > On Wed, Oct 16, 2013 at 11:45:48AM -0700, Dan Williams wrote:
> > > On Wed, Oct 16, 2013 at 11:29 AM, Guennadi Liakhovetski
> > > >
> > > > Doesn't this break kernel compilation for a total of 27 commits? Or am I
> > > > missing anything?
> > >
> > > Yes, I think at the start DMA_COMPLETE should just be a alias for
> > > DMA_SUCCESS, then after all the driver renames are in delete
> > Oops, taht was bad of me. ffixes in v2 and sending patch 29 for removal case
> Ok, yes, this should work now. I'm wondering though - is DMA_COMPLTE
> really a better name? AFAICS, we can only differentiate between 2
> possibilities with the current API: a transfer is "in progress" - between
> last used and last completed, and "unknown" - either completed, or
> aborted, or not yet submitted - if the cookie is larger, than last
> completed and we assume, that it has wrapped.
well, once you submit N, and chekcing status, if you get last > N, then you
assume it completed. If last is M then M is completed and M + 1 running and rest
in queue. You know which one is last submitted in client

> Actually for a driver, that I'm currently working on, I implemented a
> cache of N last cookies (e.g. 128), which is a bitfield, where I just
> record a 1, if that descriptor has failed, and a 0, if completed
> successfully. That way I can report one of 4 states: cookie on queue,
> completed successfully, failed, unknown. I'm not sure, whether I'll keep
> this in the final version, this doesn't really fit the present dmaengine
> API concept. We could make this generic, if desired. Otherwise your
> proposed error callback should help too. But in either case I think with
> the current implementation we cannot find out whether a specific cookie
> completed successfully or failed.
The propsed error callback will tell you if dmaengine detected a failure or not.
That should with above cover well

> One more observation: I looked at a couple of drivers, using the DMA_ERROR
> state. E.g. mmp_tdma.c, mxs-dma.c. They store errors in a .status field in
> their private data. Then they return that status in their
> .device_tx_status() methods - independent on the cookie! This doesn't look
> right to me... at_hdmac.c does something similarly strange.
Yup bunch of ones arent being good citizens..


 \ /
  Last update: 2013-10-17 13:21    [W:0.111 / U:13.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site