Patch "dmaengine: at_xdmac: double FIFO flush needed to compute residue" has been added to the 4.4-stable tree
Subsystems (3)
This is a note to let you know that I've just added the patch titled
dmaengine: at_xdmac: double FIFO flush needed to compute residue
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
dmaengine-at_xdmac-double-fifo-flush-needed-to-compute-residue.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
9295c41d77ca93aac79cfca6fa09fa1ca5cab66fMon Sep 17 00:00:00 2001
From: Ludovic Desroches <[email protected]>
Date: Thu, 12 May 2016 16:54:10 +0200
Subject: dmaengine: at_xdmac: double FIFO flush needed to compute residue
From: Ludovic Desroches <[email protected]>
commit 9295c41d77ca93aac79cfca6fa09fa1ca5cab66f upstream.
Due to the way CUBC register is updated, a double flush is needed to compute an accurate residue. First flush aim is to get data from the DMA FIFO and second one ensures that we won't report data which are not in memory.
eXtended DMA Controller driver")
--- drivers/dma/at_xdmac.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)
drivers/dma/at_xdmac.c +23 -1
@@ -1413,7 +1413,16 @@ at_xdmac_tx_status(struct dma_chan *chan residue = desc->xfer_size;/* * Flush FIFO: only relevant when the transfer is source peripheral -* synchronized. +* synchronized. Flush is needed before reading CUBC because data in +* the FIFO are not reported by CUBC. Reporting a residue of the +* transfer length while we have data in FIFO can cause issue. +* Usecase: atmel USART has a timeout which means I have received +* characters but there is no more character received for a while. On +* timeout, it requests the residue. If the data are in the DMA FIFO, +* we will return a residue of the transfer length. It means no data +* received. If an application is waiting for these data, it will hang +* since we won't have another USART timeout without receiving new +* data. */ mask =AT_XDMAC_CC_TYPE |AT_XDMAC_CC_DSYNC ; value =AT_XDMAC_CC_TYPE_PER_TRAN |AT_XDMAC_CC_DSYNC_PER2MEM ;
@@ -1469,6 +1478,19 @@ at_xdmac_tx_status(struct dma_chan *chan }/* +* Flush FIFO: only relevant when the transfer is source peripheral +* synchronized. Another flush is needed here because CUBC is updated +* when the controller sends the data write command. It can lead to +* report data that are not written in the memory or the device. The +* FIFO flush ensures that data are really written. +*/ +if ((desc->lld.mbr_cfg & mask) == value) { +at_xdmac_write (atxdmac,AT_XDMAC_GSWF , atchan->mask); +while (!(at_xdmac_chan_read (atchan,AT_XDMAC_CIS ) &AT_XDMAC_CIS_FIS )) +cpu_relax (); + } + +/* * Remove size of all microblocks already transferred and the current * one. Then add the remaining size to transfer of the current * microblock.
Patches currently in stable-queue which might be from [email protected] are
queue-4.4/dmaengine-at_xdmac-fix-residue-corruption.patch queue-4.4/dmaengine-at_xdmac-double-fifo-flush-needed-to-compute-residue.patch queue-4.4/dmaengine-at_xdmac-align-descriptors-on-64-bits.patch