On Wed, May 07, 2014 at 12:15:39PM -0700, Lars-Peter Clausen wrote: > On 05/07/2014 06:38 PM, Stephen Warren wrote: > > On 05/06/2014 03:22 PM, Christopher Freeman wrote: > >> bytes_transferred will overflow during long audio playbacks. Since > >> the driver only ever consults this value modulo bytes_requested, store the > >> value modulo bytes_requested. > > > > The audio driver may only interpret the value modulo bytes_requested, > > but what about other drivers such as the high-speed UART (and SPI?) drivers? > > > > What is the dmaengine API's design requirement here, and what do other > > dmaengine drivers do. If it's to store the modulo, then I'm fine with > > this change. > > Yep, this part of the API. The residue should be between transfer length and > 0. While 0 is special and should only be returned if the transfer has > finished. For cyclic transfers this means it should never be zero. So if > transferred_bytes is incremented modulo length and residue is length - > transferred_bytes you get the correct result. > What each driver receives remains unchanged here. bytes_transferred is only ever read modulo bytes_requested in all cases (audio, spi, uart) This shifts that part of the calculation to the assignment. I guess this is a roundabout way of saying it's not any more wrong than it could have possibly been before. We can rename "bytes_transferred" to something like "residue" or "segment_residue" though. -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
