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