kernel/linux.git/drivers/dma/sh, branch linux-4.20.y

dmaengine: rcar-dmac: set scatter/gather max segment size

2018-10-07T14:34:14+00:00

Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a device_dma_parameters structure and filling in the max segment size. Signed-off-by: Wolfram Sang Signed-off-by: Vinod Koul

dmaengine: use SPDX identifier for Renesas drivers

2018-08-29T16:28:49+00:00

Signed-off-by: Wolfram Sang Reviewed-by: Simon Horman Signed-off-by: Vinod Koul

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

dmaengine: rcar-dmac: don't use DMAC error interrupt

2018-06-28T04:21:09+00:00

rcar-dmac has 2 types of interrupt, 1) error IRQ (for all), 2) IRQ for each channels. If error happens on some channels, the error IRQ will be handled by 1), and "all" channels will be restarted. But in this design, error handling itself will be problem for non error channel users. This patch removes 1) handler, and handles error IRQ on 2) Signed-off-by: Magnus Damm [Kuninori: updated patch to adjust DMACHCR/DMAOR] Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung Reviewed-by: Geert Uytterhoeven Signed-off-by: Vinod Koul