lkml.org 
[lkml]   [2014]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1 3/3] dma: tegra: avoid int overflow for transferred count
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.



\
 
 \ /
  Last update: 2014-05-08 01:21    [W:0.044 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site