linux/drivers/dma, branch v2.6.38.4

Merge branch 'imx' into dmaengine-fixes

2011-02-14T10:40:46Z

dma: ipu_idmac: do not lose valid received data in the irq handler

2011-02-14T10:28:16Z

Currently when two or more buffers are queued by the camera driver and so the double buffering is enabled in the idmac, we lose one frame comming from CSI since the reporting of arrival of the first frame is deferred by the DMAIC_7_EOF interrupt handler and reporting of the arrival of the last frame is not done at all. So when requesting N frames from the image sensor we actually receive N - 1 frames in user space. The reason for this behaviour is that the DMAIC_7_EOF interrupt handler misleadingly assumes that the CUR_BUF flag is pointing to the buffer used by the IDMAC. Actually it is not the case since the CUR_BUF flag will be flipped by the FSU when the FSU is sending the _NEW_FRM_RDY signal when new frame data is delivered by the CSI. When sending this singal, FSU updates the DMA_CUR_BUF and the DMA_BUFx_RDY flags: the DMA_CUR_BUF is flipped, the DMA_BUFx_RDY is cleared, indicating that the frame data is beeing written by the IDMAC to the pointed buffer. DMA_BUFx_RDY is supposed to be set to the ready state again by the MCU, when it has handled the received data. DMAIC_7_CUR_BUF flag won't be flipped here by the IPU, so waiting for this event in the EOF interrupt handler is wrong. Actually there is no spurious interrupt as described in the comments, this is the valid DMAIC_7_EOF interrupt indicating reception of the frame from CSI. The patch removes code that waits for flipping of the DMAIC_7_CUR_BUF flag in the DMAIC_7_EOF interrupt handler. As the comment in the current code denotes, this waiting doesn't help anyway. As a result of this removal the reporting of the first arrived frame is not deferred to the time of arrival of the next frame and the drivers software flag 'ichan->active_buffer' is in sync with DMAIC_7_CUR_BUF flag, so the reception of all requested frames works. This has been verified on the hardware which is triggering the image sensor by the programmable state machine, allowing to obtain exact number of frames. On this hardware we do not tolerate losing frames. This patch also removes resetting the DMA_BUFx_RDY flags of all channels in ipu_disable_channel() since transfers on other DMA channels might be triggered by other running tasks and the buffers should always be ready for data sending or reception. Signed-off-by: Anatolij Gustschin Reviewed-by: Guennadi Liakhovetski Tested-by: Guennadi Liakhovetski Signed-off-by: Dan Williams

Merge branch 'dmaengine-shawn' into dmaengine

2011-01-31T11:42:51Z

Merge branch 'dmaengine-sdma' into dmaengine

2011-01-31T11:42:48Z

dmaengine: imx-sdma: fix up param for the last BD in sdma_prep_slave_sg()

2011-01-31T11:42:23Z

As per the reference manual, bit "L" should be set while bit "C" should be cleared for the last buffer descriptor in the non-cyclic chain, so that sdma can stop trying to find the next BD and end the transfer. In case of sdma_prep_slave_sg(), BD_LAST needs to be set and BD_CONT be cleared for the last BD. Signed-off-by: Shawn Guo Signed-off-by: Sascha Hauer

dmaengine: imx-sdma: correct sdmac->status in sdma_handle_channel_loop()

2011-01-31T11:42:12Z

sdma_handle_channel_loop() is the handler of cyclic tx. One period success does not really mean the success of the tx. Instead of DMA_SUCCESS, DMA_IN_PROGRESS should be the one to tell. Signed-off-by: Shawn Guo Signed-off-by: Sascha Hauer

dmaengine: imx-sdma: return sdmac->status in sdma_tx_status()

2011-01-31T11:41:59Z

The sdmac->status was designed to reflect the status of the tx, so simply return it in sdma_tx_status(). Then dma client can call dma_async_is_tx_complete() to know the status of the tx. Signed-off-by: Shawn Guo Signed-off-by: Sascha Hauer

dmaengine: imx-sdma: set sdmac->status to DMA_ERROR in err_out of sdma_prep_slave_sg()

2011-01-31T11:41:50Z

sdma_prep_dma_cyclic() sets sdmac->status to DMA_ERROR in err_out, and sdma_prep_slave_sg() needs to do the same. Otherwise, sdmac->status stays at DMA_IN_PROGRESS, which will make the function return immediately next time it gets called. Signed-off-by: Shawn Guo Signed-off-by: Sascha Hauer

dmaengine: imx-sdma: remove IMX_DMA_SG_LOOP handling in sdma_prep_slave_sg()

2011-01-31T11:41:43Z

This is a leftover from the time that the driver did not have sdma_prep_dma_cyclic callback and implemented sound dma as a looped sg chain. And it can be removed now. Signed-off-by: Shawn Guo Signed-off-by: Sascha Hauer

dmaengine i.MX dma: initialize dma capabilities outside channel loop

2011-01-31T11:36:23Z

The capabilities are device specific fields, not channel specific fields. Signed-off-by: Sascha Hauer