linux-stable.git/drivers/dma, branch linux-5.0.y

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

2019-05-31T13:45:17+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:45:01+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:44:58+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:44:53+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: bcm2835: Avoid GFP_KERNEL in device_prep_slave_sg

2019-05-16T17:40:24+00:00

[ Upstream commit f147384774a7b24dda4783a3dcd61af272757ea8 ]

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 
Signed-off-by: Sasha Levin

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

2019-05-02T08:02:47+00:00

commit 5bb5c3a3ac102158b799bf5eda871223aa5e9c25 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

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

2019-05-02T08:02:47+00:00

commit 6e7da74775348d96e2d7efaf3f91410e18c481ef upstream.

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 
Signed-off-by: Greg Kroah-Hartman

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

2019-05-02T08:02:47+00:00

commit 907bd68a2edc491849e2fdcfe52c4596627bca94 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

dmaengine: tegra: avoid overflow of byte tracking

2019-04-05T20:34:52+00:00

[ Upstream commit e486df39305864604b7e25f2a95d51039517ac57 ]

The dma_desc->bytes_transferred counter tracks the number of bytes
moved by the DMA channel. This is then used to calculate the information
passed back in the in the tegra_dma_tx_status callback, which is usually
fine.

When the DMA channel is configured as continous, then the bytes_transferred
counter will increase over time and eventually overflow to become negative
so the residue count will become invalid and the ALSA sound-dma code will
report invalid hardware pointer values to the application. This results in
some users becoming confused about the playout position and putting audio
data in the wrong place.

To fix this issue, always ensure the bytes_transferred field is modulo the
size of the request. We only do this for the case of the cyclic transfer
done ISR as anyone attempting to move 2GiB of DMA data in one transfer
is unlikely.

Note, we don't fix the issue that we should /never/ transfer a negative
number of bytes so we could make those fields unsigned.

Reviewed-by: Dmitry Osipenko 
Signed-off-by: Ben Dooks 
Acked-by: Jon Hunter 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: qcom_hidma: initialize tx flags in hidma_prep_dma_*

2019-04-05T20:34:50+00:00

[ Upstream commit 875aac8a46424e5b73a9ff7f40b83311b609e407 ]

In async_tx_test_ack(), it uses flags in struct dma_async_tx_descriptor
to check the ACK status. As hidma reuses the descriptor in a free list
when hidma_prep_dma_*(memcpy/memset) is called, the flag will keep ACKed
if the descriptor has been used before. This will cause a BUG_ON in
async_tx_quiesce().

  kernel BUG at crypto/async_tx/async_tx.c:282!
  Internal error: Oops - BUG: 0 1 SMP
  ...
  task: ffff8017dd3ec000 task.stack: ffff8017dd3e8000
  PC is at async_tx_quiesce+0x54/0x78 [async_tx]
  LR is at async_trigger_callback+0x98/0x110 [async_tx]

This patch initializes flags in dma_async_tx_descriptor by the flags
passed from the caller when hidma_prep_dma_*(memcpy/memset) is called.

Cc: Joey Zheng 
Reviewed-by: Sinan Kaya 
Signed-off-by: Shunyong Yang 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin