Cyclic DMA - callback properties and tx_status residue

Vinod Koul vinod.koul at linux.intel.com
Fri May 4 08:45:50 EDT 2012


On Fri, 2012-05-04 at 13:26 +0100, Russell King - ARM Linux wrote:
> On Wed, May 02, 2012 at 05:27:02PM +0100, Russell King - ARM Linux wrote:
> > On Wed, May 02, 2012 at 09:31:15PM +0530, Vinod Koul wrote:
> > > From what I understand (Dan please correct me as you may know this much
> > > better than me), the tx_status tells you wrt passed cookie what is the
> > > status. Further, (as you pointed), it also tells you which is last
> > > completed cookie and what is the current "running". And wrt the
> > > currently "running" cookie it tells you how may bytes are left.
> > 
> > That means we have a number of buggy drivers on both sides of the API...
> > PL08x for example always total up all the pending bytes from the position
> > in the current descriptor to the last issued descriptor.  Many other
> > implementations simply always return zero.
> 
> Right, as there's been no reply on this, I'll see about changing PL08x
> and SA11x0 to do exactly this.  I'll also see about implementing it in
> the new OMAP DMA engine driver.
> 
> The semantics I intend to implement are:
> 
> If the cookie has completed successfully, the residue will be zero.  If
> it is queued, it will be the number of bytes in the descriptor identified
> by the cookie.  If it is in progress, it will be the number of bytes yet
> to be transferred.
Today is is supposed to be defined as:
* @residue: the remaining number of bytes left to transmit
*      on the selected transfer for states DMA_IN_PROGRESS and
*      DMA_PAUSED if this is implemented in the driver, else 0
So what you are saying is correct and already documented.

> 
> Now, there is a bit of ambiguity over "number of bytes yet to be transferred"
> with DMA hardware which reads from memory into a FIFO, and then transfers
> to the peripheral when the peripheral requests DMA service.  Do we define
> it as the number of bytes read from memory, or the number of bytes to be
> transferred to the peripheral.
> 
> The latter may not be easy for DMA hardware to report to us... so my
> initial implementation will be number of bytes remaining calculated using
> the DMA address pointer into memory.
yes, it may not be possible to get this information, so lets take the
dma pointer in memory and do the math.

-- 
~Vinod




More information about the linux-arm-kernel mailing list