kernel/linux.git/drivers/dma/sh, branch v4.19.39

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

2019-05-02T07:58:55+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-02T07:58:55+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: usb-dmac: Make DMAC system sleep callbacks explicit

2019-03-23T19:10:04+00:00

commit d9140a0da4a230a03426d175145989667758aa6a upstream. This commit fixes the issue that USB-DMAC hangs silently after system resumes on R-Car Gen3 hence renesas_usbhs will not work correctly when using USB-DMAC for bulk transfer e.g. ethernet or serial gadgets. The issue can be reproduced by these steps: 1. modprobe g_serial 2. Suspend and resume system. 3. connect a usb cable to host side 4. Transfer data from Host to Target 5. cat /dev/ttyGS0 (Target side) 6. echo "test" > /dev/ttyACM0 (Host side) The 'cat' will not result anything. However, system still can work normally. Currently, USB-DMAC driver does not have system sleep callbacks hence this driver relies on the PM core to force runtime suspend/resume to suspend and reinitialize USB-DMAC during system resume. After the commit 17218e0092f8 ("PM / genpd: Stop/start devices without pm_runtime_force_suspend/resume()"), PM core will not force runtime suspend/resume anymore so this issue happens. To solve this, make system suspend resume explicit by using pm_runtime_force_{suspend,resume}() as the system sleep callbacks. SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() is used to make sure USB-DMAC suspended after and initialized before renesas_usbhs." Signed-off-by: Phuong Nguyen Signed-off-by: Hiroyuki Yokoyama Cc: # v4.16+ [shimoda: revise the commit log and add Cc tag] Signed-off-by: Yoshihiro Shimoda Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

dmaengine: sh: rcar-dmac: Should not stop the DMAC by rcar_dmac_sync_tcr()

2018-07-31T04:27:27+00:00

rcar_dmac_chan_get_residue() should not stop the DMAC, because the commit 538603c6026c ("dmaengine: sh: rcar-dmac: avoid to write CHCR.TE to 1 if TCR is set to 0") had fixed unexpected re-transferring issue. But it had caused the next issue which might stop the cyclic mode transferring. Thus, for example R-Car sound might be stopped suddenly. According to the commit 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for residue"), the purpose of clearing CHCR.DE bit is flushing buffered data to calculate the exact residue. Such the "exact" residue had been required by sh-sci driver. sh-sci driver is calling dmaengine_pause() to stop transferring, and get "exact" residue. Otherwise, it might receive extra data during getting residue without pausing. In rx_timer_fn() of sh-sci driver: dmaengine_tx_status(); /* For checking roughly */ dmaengine_pause(); dmaengine_tx_status(); /* For getting residue */ dmaengine_terminate_all(); But, unfortunately the rcar-dmac driver didn't support dmaengine_pause() at that time. So, the sh-sci driver cannot get the "exact" residue without stopping the transferring, because rcar-dmac is buffering data inside. Because of these backgrounds, rcar-dmac had been cleared/set CHCR.DE bit in rcar_dmac_chan_get_residue() to synchronizing data and getting "exact" residue. However, rcar-dmac driver has rcar_dmac_chan_pause() now, and clearing CHCR.DE bit in rcar_dmac_chan_get_residue() doesn't need anymore. So, this patch removes the rcar_dmac_sync_tcr(). Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for residue") Signed-off-by: Yoshihiro Shimoda Tested-by: Hiroyuki Yokoyama Reviewed-by: Geert Uytterhoeven Signed-off-by: Vinod Koul

dmaengine: sh: rcar-dmac: Add dma_pause operation

2018-07-11T05:17:31+00:00

This patch adds dma_pause operation. This patch is based on Muhammad Hamza Farooq's patch. After this patch applied, an issue that the sh-sci driver with high baud rate might cause data lost disappeared because the DMAC is possible to transmit between [1] and [2] below, and then the residue of [1] is not true: In rx_timer_fn() of the sh-sci.c: dmaengine_pause(); ... dmaengine_tx_status(); /* [1] */ ... dmaengine_terminate_all(); /* [2] */ Signed-off-by: Yoshihiro Shimoda Signed-off-by: Vinod Koul

dmaengine: sh: rcar-dmac: add a new function to clear CHCR.DE with barrier

2018-07-11T05:17:30+00:00

This patch adds a new function rcar_dmac_clear_chcr_de() to simplify adding pause function later. Signed-off-by: Yoshihiro Shimoda Signed-off-by: Vinod Koul

dmaengine: sh: rcar-dmac: avoid to write CHCR.TE to 1 if TCR is set to 0

2018-07-10T15:19:46+00:00

This patch fixes an issue that unexpected retransfering happens if TCR is set to 0 before rcar_dmac_sync_tcr() writes DE bit to the CHCR register. For example, sh-sci driver can reproduce this issue like below: In rx_timer_fn(): /* CHCR DE bit may be set to 1 */ dmaengine_tx_status() rcar_dmac_tx_status() rcar_dmac_chan_get_residue() rcar_dmac_sync_tcr() /* TCR is possible to be set to 0 */ According to the description of commit 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for residue"), "this buffered data will be transferred if CHCR::DE bit was cleared". So, this patch doesn't need to check TCRB register. Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for residue") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Vinod Koul

dmaengine: rcar-dmac: clear channel register when error

2018-07-09T16:52:32+00:00

We need to clear channel register in error case as recovery. The channel is already stopped in such case, thus we don't need to call rcar_dmac_chan_halt() before clearing. rcar_dmac_chan_halt() will clear and confirm DE bit. But it will be failed because channel is already stopped in error case. In other words, we shouldn't call it then. Reported-by: Hiroki Negishi Signed-off-by: Kuninori Morimoto Reviewed-by: Hiroki Negishi Reviewed-by: Simon Horman Signed-off-by: Vinod Koul

dmaengine: rcar-dmac: Disable interrupts while stopping channels

2018-07-09T16:50:53+00:00

During system reboot or halt, with lockdep enabled: ================================ WARNING: inconsistent lock state 4.18.0-rc1-salvator-x-00002-g9203dbec90a68103 #41 Tainted: G W -------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. reboot/2779 [HC0[0]:SC0[0]:HE1:SE1] takes: 0000000098ae4ad3 (&(&rchan->lock)->rlock){?.-.}, at: rcar_dmac_shutdown+0x58/0x6c {IN-HARDIRQ-W} state was registered at: lock_acquire+0x208/0x238 _raw_spin_lock+0x40/0x54 rcar_dmac_isr_channel+0x28/0x200 __handle_irq_event_percpu+0x1c0/0x3c8 handle_irq_event_percpu+0x34/0x88 handle_irq_event+0x48/0x78 handle_fasteoi_irq+0xc4/0x12c generic_handle_irq+0x18/0x2c __handle_domain_irq+0xa8/0xac gic_handle_irq+0x78/0xbc el1_irq+0xec/0x1c0 arch_cpu_idle+0xe8/0x1bc default_idle_call+0x2c/0x30 do_idle+0x144/0x234 cpu_startup_entry+0x20/0x24 rest_init+0x27c/0x290 start_kernel+0x430/0x45c irq event stamp: 12177 hardirqs last enabled at (12177): [] _raw_spin_unlock_irq+0x2c/0x4c hardirqs last disabled at (12176): [] _raw_spin_lock_irq+0x1c/0x60 softirqs last enabled at (11948): [] __do_softirq+0x160/0x4ec softirqs last disabled at (11935): [] irq_exit+0xa0/0xfc other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&rchan->lock)->rlock); lock(&(&rchan->lock)->rlock); *** DEADLOCK *** 3 locks held by reboot/2779: #0: 00000000bfabfa74 (reboot_mutex){+.+.}, at: sys_reboot+0xdc/0x208 #1: 00000000c75d8c3a (&dev->mutex){....}, at: device_shutdown+0xc8/0x1c4 #2: 00000000ebec58ec (&dev->mutex){....}, at: device_shutdown+0xd8/0x1c4 stack backtrace: CPU: 6 PID: 2779 Comm: reboot Tainted: G W 4.18.0-rc1-salvator-x-00002-g9203dbec90a68103 #41 Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT) Call trace: dump_backtrace+0x0/0x148 show_stack+0x14/0x1c dump_stack+0xb0/0xf0 print_usage_bug.part.26+0x1c4/0x27c mark_lock+0x38c/0x610 __lock_acquire+0x3fc/0x14d4 lock_acquire+0x208/0x238 _raw_spin_lock+0x40/0x54 rcar_dmac_shutdown+0x58/0x6c platform_drv_shutdown+0x20/0x2c device_shutdown+0x160/0x1c4 kernel_restart_prepare+0x34/0x3c kernel_restart+0x14/0x5c sys_reboot+0x160/0x208 el0_svc_naked+0x30/0x34 rcar_dmac_stop_all_chan() takes the channel lock while stopping a channel, but does not disable interrupts, leading to a deadlock when a DMAC interrupt comes in. Before, the same code block was called from an interrupt handler, hence taking the spinlock was sufficient. Fix this by disabling local interrupts while taking the spinlock. Fixes: 9203dbec90a68103 ("dmaengine: rcar-dmac: don't use DMAC error interrupt") Signed-off-by: Geert Uytterhoeven Signed-off-by: Vinod Koul

dmaengine: rcar-dmac: convert to SPDX identifiers

2018-07-06T06:02:33+00:00

This patch is using C++ comment style for SPDX line only, because driver author want it. Signed-off-by: Kuninori Morimoto Reviewed-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Signed-off-by: Vinod Koul