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 > > > DMA_SUCCESS. > > 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.. ~Vinod -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/