aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/dma/dma-jz4780.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2017-12-04dmaengine: dma-jz4780: Use vchan_terminate_vdesc() instead of desc_freePeter Ujfalusi1-1/+9
To avoid race with vchan_complete, use the race free way to terminate running transfer. Implement the device_synchronize callback to make sure that the terminated descriptor is freed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-03Merge branch 'topic/compile_test' into for-linusVinod Koul1-1/+1
2016-09-30dmaengine: jz4780: fix resource leaks on error exit returnColin Ian King1-2/+6
In two cases when jz4780_dma_setup_hwdesc fails, there is a memory leak on the allocated desc and associated DMA pools on the error exit return path. Fix this by free'ing the resources before returning. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-09-26dmaengine: jz4780: make jz4780_dma_prep_dma_memcpy staticVinod Koul1-1/+1
Sparse complains: drivers/dma/dma-jz4780.c:399:32: warning: symbol 'jz4780_dma_prep_dma_memcpy' was not declared. Should it be static? So make this static Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-08-18dmaengine: jz4780: Kill tasklets before unregistering the deviceAlex Smith1-0/+6
Tasklets may have been scheduled as a result of an earlier interrupt that could still be running. Kill them before unregistering the device. Signed-off-by: Alex Smith <alex.smith@imgtec.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Cc: dmaengine@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-08-18dmaengine: jz4780: Don't use devm_*_irq() functionsAlex Smith1-4/+8
We must explicitly free the IRQ before the device is unregistered in case any device interrupt still occurs, so there's no point in using the managed variations of the IRQ functions. Change to the regular versions. Signed-off-by: Alex Smith <alex.smith@imgtec.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Cc: dmaengine@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-08-18dmaengine: jz4780: Ensure channel is on correct controller in filterAlex Smith1-3/+8
When scanning for a free DMA channel, the filter function should ensure that the channel is on the controller that it was requested to be on in the DT. Signed-off-by: Alex Smith <alex.smith@imgtec.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Cc: dmaengine@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-08-18dmaengine: jz4780: Use dma_get_slave_channel when requesting a specific channelAlex Smith1-2/+7
When the DT requests a specific channel to use it is not necesssary to scan through all DMA channels in the system. Just return the requested channel using dma_get_slave_channel(). Signed-off-by: Alex Smith <alex.smith@imgtec.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Cc: dmaengine@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-08-18dmaengine: jz4780: Fix error handling/signedness issuesAlex Smith1-16/+17
There are a some signedness bugs such as testing for < 0 on unsigned return values. Additionally there are some cases where functions which should return NULL on error actually return a PTR_ERR value which can result in oopses on error. Fix these issues. Signed-off-by: Alex Smith <alex.smith@imgtec.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Cc: dmaengine@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-08-18dmaengine: jz4780: Fall back on smaller transfer sizes where necessaryAlex Smith1-14/+23
For some reason the controller does not support 8 byte transfers (but does support all other powers of 2 up to 128). In this case fall back to 4 bytes. In addition, fall back to 128 bytes when any larger power of 2 would be possible within the alignment constraints, as this is the maximum supported. It makes no sense to outright reject 8 or >128 bytes just because the alignment constraints make those the maximum possible size given the parameters for the transaction. For instance, this can result in a DMA from/to an 8 byte aligned address failing. It is perfectly safe to fall back to smaller transfer sizes, the only consequence is reduced transfer efficiency, which is far better than not allowing the transfer at all. Signed-off-by: Alex Smith <alex.smith@imgtec.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Cc: dmaengine@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-08-18dmaengine: jz4780: Fix up dmaengine API function prototypesAlex Smith1-5/+9
Several function prototypes did not match the dmaengine API they were implementing, resulting in build warnings. Correct these. Signed-off-by: Alex Smith <alex.smith@imgtec.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Cc: dmaengine@vger.kernel.org Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-08-05dmaengine: Add an enum for the dmaengine alignment constraintsMaxime Ripard1-1/+1
Most drivers need to set constraints on the buffer alignment for async tx operations. However, even though it is documented, some drivers either use a defined constant that is not matching what the alignment variable expects (like DMA_BUSWIDTH_* constants) or fill the alignment in bytes instead of power of two. Add a new enum for these alignments that matches what the framework expects, and convert the drivers to it. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-04-01dmaengine: jz4780: add driver for the Ingenic JZ4780 DMA controllerAlex Smith1-0/+877
This patch adds a driver for the DMA controller found in the Ingenic JZ4780. It currently does not implement any support for the programmable firmware feature of the controller - this is not necessary for most uses. It also does not take priority into account when allocating channels, it just allocates the first available channel. This can be implemented later. Signed-off-by: Alex Smith <alex.smith@imgtec.com> Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> [Updated for dmaengine api changes, Add residue support, couple of minor fixes] Signed-off-by: Vinod Koul <vinod.koul@intel.com>