linux-stable.git/drivers/dma, branch v4.0.7

dmaengine: at_xdmac: lock fixes

2015-06-23T00:03:27+00:00

commit 4c374fc7ce944024936a6d9804daec85207d9384 upstream.

Using _bh variant for spin locks causes this kind of warning:
Starting logging: ------------[ cut here ]------------
WARNING: CPU: 0 PID: 3 at /ssd_drive/linux/kernel/softirq.c:151
__local_bh_enable_ip+0xe8/0xf4()
Modules linked in:
CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.1.0-rc2+ #94
Hardware name: Atmel SAMA5
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from []
(warn_slowpath_common+0x80/0xac)
[] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[] (warn_slowpath_null) from []
(__local_bh_enable_ip+0xe8/0xf4)
[] (__local_bh_enable_ip) from []
(at_xdmac_device_terminate_all+0xf4/0x100)
[] (at_xdmac_device_terminate_all) from []
(atmel_complete_tx_dma+0x34/0xf4)
[] (atmel_complete_tx_dma) from []
(at_xdmac_tasklet+0x14c/0x1ac)
[] (at_xdmac_tasklet) from []
(tasklet_action+0x68/0xb4)
[] (tasklet_action) from []
(__do_softirq+0xfc/0x238)
[] (__do_softirq) from [] (run_ksoftirqd+0x28/0x34)
[] (run_ksoftirqd) from []
(smpboot_thread_fn+0x138/0x18c)
[] (smpboot_thread_fn) from [] (kthread+0xdc/0xf0)
[] (kthread) from [] (ret_from_fork+0x14/0x34)
---[ end trace b57b14a99c1d8812 ]---

It comes from the fact that devices can called some code from the DMA
controller with irq disabled. _bh variant is not intended to be used in
this case since it can enable irqs. Switch to irqsave/irqrestore variant to
avoid this situation.

Signed-off-by: Ludovic Desroches 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: at_xdmac: rework slave configuration part

2015-06-23T00:03:27+00:00

commit 765c37d876698268eea8b820081ac8fc9d0fc8bc upstream.

Rework slave configuration part in order to more report wrong errors
about the configuration.
Only maxburst and addr width values are checked when doing the slave
configuration. The validity of the channel configuration is done at
prepare time.

Signed-off-by: Ludovic Desroches 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: Fix choppy sound because of unimplemented resume

2015-06-23T00:03:27+00:00

commit 88d04643c66052a1cf92a6fd5f92dff0f7757f61 upstream.

Some drivers implement only pause operation (no resuming). Example is
pl330 where pause is needed for getting residuum. pl330 does not support
resume operation, transfer must be stopped after pause.

However for slaves this is exposed always as "pause and resume" which
introduces subtle errors on Odroid U3 board (Exynos4412 with pl330).
After adding pause function to pl330 driver the audio playback
(utilizing DMA) gets choppy after some time (approximately 24 hours).

Fix this by exposing "cmd_pause" if and only if pause and resume are
implemented.

Signed-off-by: Krzysztof Kozlowski 
Reported-by: gabriel@unseen.is
Reported-by: Marek Szyprowski 
Fixes: 88987d2c7534 ("dmaengine: pl330: add DMA_PAUSE feature")
Acked-by: Maxime Ripard 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: pl330: Fix hang on dmaengine_terminate_all on certain boards

2015-06-23T00:03:27+00:00

commit 81cc6edc08705ac0146fe6ac14a0982a31ce6f3d upstream.

The pl330 device could hang infinitely on certain boards when DMA
channels are terminated.

It was caused by lack of runtime resume when executing
pl330_terminate_all() which calls the _stop() function. _stop() accesses
device register and can loop infinitely while checking for device state.

The hang was confirmed by Dinh Nguyen on Altera SOCFPGA Cyclone V
board during boot. It can be also triggered with:

$ echo 1 > /sys/module/dmatest/parameters/iterations
$ echo dma1chan0 > /sys/module/dmatest/parameters/channel
$ echo 1 > /sys/module/dmatest/parameters/run
$ sleep 1
$ cat /sys/module/dmatest/parameters/run

Reported-by: Dinh Nguyen 
Signed-off-by: Krzysztof Kozlowski 
Fixes: ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
Tested-by: Dinh Nguyen 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

Revert "dmaengine: Add a warning for drivers not using the generic slave caps retrieval"

2015-04-11T20:46:07+00:00

This reverts commit ecc19d17868be9c9f8f00ed928791533c420f3e0.

It added a new warning to try to encourage driver writers to set the
device capabities properly, but drivers haven't been updated and in the
meantime it just generaters a scary message that users cannot actually
do anything about.

Warnings like these are appropriate if you actually expect to fix the
code that causes them.  They are not appropriate for releases.

Requested-by: Peter Hurley 
Signed-off-by: Linus Torvalds

dmaengine: cppi41: add missing bitfields

2015-04-11T15:42:58+00:00

Add missing directions, residue_granularity,
srd_addr_widths and dst_addr_widths bitfields.

Without those we will see a kernel WARN()
when loading musb on am335x devices.

Signed-off-by: Felipe Balbi 
Signed-off-by: Vinod Koul

dmaengine: moxart-dma: Fix memory leak when stopping a running transfer

2015-03-30T17:47:08+00:00

The vd->node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Vinod Koul

dmaengine: bcm2835-dma: Fix memory leak when stopping a running transfer

2015-03-30T17:47:08+00:00

The vd->node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.

Signed-off-by: Peter Ujfalusi 
Acked-by: Stephen Warren 
Signed-off-by: Vinod Koul

dmaengine: omap-dma: Fix memory leak when terminating running transfer

2015-03-30T17:47:08+00:00

In omap_dma_start_desc the vdesc->node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.

Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.

Signed-off-by: Peter Ujfalusi 
CC: 
CC: 
Signed-off-by: Vinod Koul

dmaengine: edma: fix memory leak when terminating running transfers

2015-03-30T17:47:08+00:00

If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan->edesc was not freed.

This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
removes it from the desc_issued list), so the vchan_dma_desc_free_list()
called at the end of edma_terminate_all() didn't find it and didn't free it.

This bug was found on an AM1808 based hardware (very similar to da850evm,
however using the second MMC/SD controller), where intense operations on the SD
card wasted the device 128MB RAM within a couple of days.

Peter Ujfalusi:
The issue is even more severe since it affects cyclic (audio) transfers as
well. In this case starting/stopping audio will results memory leak.

Signed-off-by: Petr Kulhavy 
Signed-off-by: Peter Ujfalusi 
CC: 
CC: 
Signed-off-by: Vinod Koul