linux-stable.git/drivers/dma, branch v5.1.7

dmaengine: tegra210-adma: use devm_clk_*() helpers

2019-05-31T13:43:49+00:00

[ Upstream commit f6ed6491d565c336a360471e0c29228e34f4380e ]

adma driver is using pm_clk_*() interface for managing clock resources.
With this it is observed that clocks remain ON always. This happens on
Tegra devices which use BPMP co-processor to manage clock resources,
where clocks are enabled during prepare phase. This is necessary because
clocks to BPMP are always blocking. When pm_clk_*() interface is used on
such Tegra devices, clock prepare count is not balanced till remove call
happens for the driver and hence clocks are seen ON always. Thus this
patch replaces pm_clk_*() with devm_clk_*() framework.

Suggested-by: Mohan Kumar D 
Reviewed-by: Jonathan Hunter 
Signed-off-by: Sameer Pujar 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: at_xdmac: remove BUG_ON macro in tasklet

2019-05-31T13:43:27+00:00

[ Upstream commit e2c114c06da2d9ffad5b16690abf008d6696f689 ]

Even if this case shouldn't happen when controller is properly programmed,
it's still better to avoid dumping a kernel Oops for this.
As the sequence may happen only for debugging purposes, log the error and
just finish the tasklet call.

Signed-off-by: Nicolas Ferre 
Acked-by: Ludovic Desroches 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: pl330: _stop: clear interrupt status

2019-05-31T13:43:22+00:00

[ Upstream commit 2da254cc7908105a60a6bb219d18e8dced03dcb9 ]

This patch kill instructs the DMAC to immediately terminate
execution of a thread. and then clear the interrupt status,
at last, stop generating interrupts for DMA_SEV. to guarantee
the next dma start is clean. otherwise, one interrupt maybe leave
to next start and make some mistake.

we can reporduce the problem as follows:

DMASEV: modify the event-interrupt resource, and if the INTEN sets
function as interrupt, the DMAC will set irq HIGH to
generate interrupt. write INTCLR to clear interrupt.

	DMA EXECUTING INSTRUCTS		DMA TERMINATE
		|				|
		|				|
	       ...			      _stop
		|				|
		|			spin_lock_irqsave
	     DMASEV				|
		|				|
		|			    mask INTEN
		|				|
		|			     DMAKILL
		|				|
		|			spin_unlock_irqrestore

in above case, a interrupt was left, and if we unmask INTEN, the DMAC
will set irq HIGH to generate interrupt.

to fix this, do as follows:

	DMA EXECUTING INSTRUCTS		DMA TERMINATE
		|				|
		|				|
	       ...			      _stop
		|				|
		|			spin_lock_irqsave
	     DMASEV				|
		|				|
		|			     DMAKILL
		|				|
		|			   clear INTCLR
		|			    mask INTEN
		|				|
		|			spin_unlock_irqrestore

Signed-off-by: Sugar Zhang 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: tegra210-dma: free dma controller in remove()

2019-05-31T13:43:15+00:00

[ Upstream commit f030e419501cb95e961e9ed35c493b5d46a04eca ]

Following kernel panic is seen during DMA driver unload->load sequence
==========================================================================
Unable to handle kernel paging request at virtual address ffffff8001198880
Internal error: Oops: 86000007 [#1] PREEMPT SMP
CPU: 0 PID: 5907 Comm: HwBinder:4123_1 Tainted: G C 4.9.128-tegra-g065839f
Hardware name: galen (DT)
task: ffffffc3590d1a80 task.stack: ffffffc3d0678000
PC is at 0xffffff8001198880
LR is at of_dma_request_slave_channel+0xd8/0x1f8
pc : [] lr : [] pstate: 60400045
sp : ffffffc3d067b710
x29: ffffffc3d067b710 x28: 000000000000002f
x27: ffffff800949e000 x26: ffffff800949e750
x25: ffffff800949e000 x24: ffffffbefe817d84
x23: ffffff8009f77cb0 x22: 0000000000000028
x21: ffffffc3ffda49c8 x20: 0000000000000029
x19: 0000000000000001 x18: ffffffffffffffff
x17: 0000000000000000 x16: ffffff80082b66a0
x15: ffffff8009e78250 x14: 000000000000000a
x13: 0000000000000038 x12: 0101010101010101
x11: 0000000000000030 x10: 0101010101010101
x9 : fffffffffffffffc x8 : 7f7f7f7f7f7f7f7f
x7 : 62ff726b6b64622c x6 : 0000000000008064
x5 : 6400000000000000 x4 : ffffffbefe817c44
x3 : ffffffc3ffda3e08 x2 : ffffff8001198880
x1 : ffffffc3d48323c0 x0 : ffffffc3d067b788

Process HwBinder:4123_1 (pid: 5907, stack limit = 0xffffffc3d0678028)
Call trace:
[] 0xffffff8001198880
[] dma_request_chan+0x50/0x1f0
[] dma_request_slave_channel+0x28/0x40
[] tegra_alt_pcm_open+0x114/0x170
[] soc_pcm_open+0x10c/0x878
[] snd_pcm_open_substream+0xc0/0x170
[] snd_pcm_open+0xc4/0x240
[] snd_pcm_playback_open+0x58/0x80
[] snd_open+0xb4/0x178
[] chrdev_open+0xb8/0x1d0
[] do_dentry_open+0x214/0x318
[] vfs_open+0x58/0x88
[] do_last+0x450/0xde0
[] path_openat+0xa8/0x368
[] do_filp_open+0x8c/0x110
[] do_sys_open+0x164/0x220
[] compat_SyS_openat+0x3c/0x50
[] el0_svc_naked+0x34/0x38
---[ end trace 67e6d544e65b5145 ]---
Kernel panic - not syncing: Fatal exception
==========================================================================

In device probe(), of_dma_controller_register() registers DMA controller.
But when driver is removed, this is not freed. During driver reload this
results in data abort and kernel panic. Add of_dma_controller_free() in
driver remove path to fix the issue.

Fixes: f46b195799b5 ("dmaengine: tegra-adma: Add support for Tegra210 ADMA")
Signed-off-by: Sameer Pujar 
Reviewed-by: Jon Hunter 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: imx-sdma: Only check ratio on parts that support 1:1

2019-05-25T16:16:48+00:00

commit 941acd566b1807b291bbdca31cc5158e26ffcf83 upstream.

On imx8mq B0 chip, AHB/SDMA clock ratio 2:1 can't be supported,
since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach
to 500Mhz, so use 1:1 instead.

To limit this change to the imx8mq for now this patch also adds an
im8mq-sdma compatible string.

Signed-off-by: Angus Ainslie (Purism) 
Acked-by: Robin Gong 
Signed-off-by: Vinod Koul 
Cc: Richard Leitner 
Signed-off-by: Greg Kroah-Hartman

dmaengine: mediatek-cqdma: fix wrong register usage in mtk_cqdma_start

2019-04-26T11:56:38+00:00

This patch fixes wrong register usage in the mtk_cqdma_start. The
destination register should be MTK_CQDMA_DST2 instead.

Fixes: b1f01e48df5a ("dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC")
Signed-off-by: Shun-Chih Yu 
Cc: stable@vger.kernel.org
Signed-off-by: Vinod Koul

dmaengine: sh: rcar-dmac: Fix glitch in dmaengine_tx_status

2019-04-23T05:15:34+00:00

The tx_status poll in the rcar_dmac driver reads the status register
which indicates which chunk is busy (DMACHCRB). Afterwards the point
inside the chunk is read from DMATCRB. It is possible that the chunk
has changed between the two reads. The result is a non-monotonous
increase of the residue. Fix this by introducing a 'safe read' logic.

Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for residue")
Signed-off-by: Achim Dahlhoff 
Signed-off-by: Dirk Behme 
Reviewed-by: Yoshihiro Shimoda 
Cc:  # v4.16+
Signed-off-by: Vinod Koul

dmaengine: sh: rcar-dmac: With cyclic DMA residue 0 is valid

2019-04-23T05:15:26+00:00

Having a cyclic DMA, a residue 0 is not an indication of a completed
DMA. In case of cyclic DMA make sure that dma_set_residue() is called
and with this a residue of 0 is forwarded correctly to the caller.

Fixes: 3544d2878817 ("dmaengine: rcar-dmac: use result of updated get_residue in tx_status")
Signed-off-by: Dirk Behme 
Signed-off-by: Achim Dahlhoff 
Signed-off-by: Hiroyuki Yokoyama 
Signed-off-by: Yao Lihua 
Reviewed-by: Yoshihiro Shimoda 
Reviewed-by: Laurent Pinchart 
Cc:  # v4.8+
Signed-off-by: Vinod Koul

dmaengine: bcm2835: Avoid GFP_KERNEL in device_prep_slave_sg

2019-04-23T05:13:54+00:00

The commit af19b7ce76ba ("mmc: bcm2835: Avoid possible races on
data requests") introduces a possible circular locking dependency,
which is triggered by swapping to the sdhost interface.

So instead of reintroduce the race condition again, we could also
avoid this situation by using GFP_NOWAIT for the allocation of the
DMA buffer descriptors.

Reported-by: Aaro Koskinen 
Signed-off-by: Stefan Wahren 
Fixes: af19b7ce76ba ("mmc: bcm2835: Avoid possible races on data requests")
Link: http://lists.infradead.org/pipermail/linux-rpi-kernel/2019-March/008615.html
Signed-off-by: Vinod Koul

dmaengine: stm32-mdma: Revert "dmaengine: stm32-mdma: Add a check on read_u32_array"

2019-03-25T16:26:54+00:00

This reverts commit 906b40b246b0 ("dmaengine: stm32-mdma: Add a check on
read_u32_array")

As stated by bindings "st,ahb-addr-masks" is optional.
The statement inserted by this commit makes this property
mandatory and prevents MDMA to be probed in case property not present.

Signed-off-by: Pierre-Yves MORDRET 
Signed-off-by: Vinod Koul