dmaengine_terminate_all() is deprecated in favor of explicitly saying if
it should be sync or async. Here, we want dmaengine_terminate_sync()
because there is no other synchronization code in the driver to handle
an async case.
Signed-off-by: Wolfram Sang <[email protected]>
---
Morimoto-san, can you please double check if this works. I don't know
this driver very well. Thank you!
sound/soc/sh/rcar/dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sh/rcar/dma.c b/sound/soc/sh/rcar/dma.c
index 95aa26d62e4f..d1b46057df9e 100644
--- a/sound/soc/sh/rcar/dma.c
+++ b/sound/soc/sh/rcar/dma.c
@@ -101,7 +101,7 @@ static int rsnd_dmaen_stop(struct rsnd_mod *mod,
struct rsnd_dmaen *dmaen = rsnd_dma_to_dmaen(dma);
if (dmaen->chan)
- dmaengine_terminate_all(dmaen->chan);
+ dmaengine_terminate_sync(dmaen->chan);
return 0;
}
--
2.30.2
On Wed, 23 Jun 2021 12:05:45 +0200, Wolfram Sang wrote:
> dmaengine_terminate_all() is deprecated in favor of explicitly saying if
> it should be sync or async. Here, we want dmaengine_terminate_sync()
> because there is no other synchronization code in the driver to handle
> an async case.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: sh: rcar: dma: : use proper DMAENGINE API for termination
commit: d5bb69dc54ec1e09f3fd626fdb9c340c0511dbd5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
Hi Wolfram-san,
> From: Wolfram Sang, Sent: Wednesday, June 23, 2021 7:06 PM
>
> dmaengine_terminate_all() is deprecated in favor of explicitly saying if
> it should be sync or async. Here, we want dmaengine_terminate_sync()
> because there is no other synchronization code in the driver to handle
> an async case.
>
> Signed-off-by: Wolfram Sang <[email protected]>
> ---
>
> Morimoto-san, can you please double check if this works. I don't know
> this driver very well. Thank you!
>
> sound/soc/sh/rcar/dma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/sh/rcar/dma.c b/sound/soc/sh/rcar/dma.c
> index 95aa26d62e4f..d1b46057df9e 100644
> --- a/sound/soc/sh/rcar/dma.c
> +++ b/sound/soc/sh/rcar/dma.c
> @@ -101,7 +101,7 @@ static int rsnd_dmaen_stop(struct rsnd_mod *mod,
> struct rsnd_dmaen *dmaen = rsnd_dma_to_dmaen(dma);
>
> if (dmaen->chan)
> - dmaengine_terminate_all(dmaen->chan);
> + dmaengine_terminate_sync(dmaen->chan);
>
> return 0;
> }
I'm afraid but, our test team detected an issue [1] on v5.15-rc2 with m3ulcb and ebusu.
# Our test team doesn't test this on salvator-xs yet...
I asked Morimoto-san locally, and he guess that using dmaengine_terminate_async() instead
of dmaengine_terminate_sync() could be resolved. But, what do you think?
Best regards,
Yoshihiro Shimoda
----
[1]
root@m3ulcb:~# amixer set 'DVC Out Mute' off
Simple mixer control 'DVC Out Mute',0
Capabilities: pswitch
Playback channels: Front Left - Front Right
Mono:
Front Left: Playback [off]
F on v5.15-rc2ront Right: Playback [off]
root@m3ulcb:~#
root@m3ulcb:~# amixer set 'DVC In Mute' off
Simple mixer control 'DVC In Mute',0
Capabilities: pswitch
Playback channels: Front Left - Front Right
Mono:
Front Left: Playback [off]
Front Right: Playback [off]
root@m3ulcb:~#
root@m3ulcb:~# amixer set "DVC Out" 20%
Simple mixer control 'DVC Out',0
Capabilities: pvolume
Playback channels: Front Left - Front Right
Limits: Playback 0 - 8388607
Mono:
Front Left: Playback 1677722 [20%]
Front Right: Playback 1677722 [20%]
root@m3ulcb:~#
root@m3ulcb:~# amixer set "DVC In" 50%
Simple mixer control 'DVC In',0
Capabilities: cvolume
Capture channels: Front Left - Front Right
Limits: Capture 0 - 8388607
Front Left: Capture 4194304 [50%]
Front Right: Capture 4194304 [50%]
root@m3ulcb:~#
root@m3ulcb:~# amixer set "Digital Playback Volume1" 85%
Simple mixer control 'Digital Playback Volume1',0
Capabilities: volume
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: 0 - 255
Front Left: 217 [85%]
Front Right: 217 [85%]
root@m3ulcb:~#
root@m3ulcb:~# aplay ~/audio.wav
Playing WAVE '/home/root/audio.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
[ 161.583393] BUG: scheduling while atomic: irq/128-ec70000/238/0x00000003
[ 161.590358] 2 locks held by irq/128-ec70000/238:
[ 161.595053] #0: ffff000442670508 (&group->lock){....}-{2:2}, at: _snd_pcm_stream_lock_irqsave+0x34/0x40
[ 161.604723] #1: ffff000442e3aea0 (&priv->lock#3){....}-{2:2}, at: rsnd_soc_dai_trigger+0x64/0x7c8
[ 161.613853] irq event stamp: 48292
[ 161.617310] hardirqs last enabled at (48291): [<ffff800010ca1d5c>] _raw_spin_unlock_irq+0x3c/0x88
[ 161.626418] hardirqs last disabled at (48292): [<ffff800010ca1968>] _raw_spin_lock_irqsave+0xb0/0xc0
[ 161.635699] softirqs last enabled at (47268): [<ffff800010010464>] _stext+0x464/0x5d8
[ 161.643746] softirqs last disabled at (47263): [<ffff80001008f738>] irq_exit+0x198/0x1b8
[ 161.651975] CPU: 0 PID: 238 Comm: irq/128-ec70000 Not tainted 5.15.0-rc2-arm64-renesas #1
[ 161.660287] Hardware name: Renesas M3ULCB Kingfisher board based on r8a77961 (DT)
[ 161.667888] Call trace:
[ 161.670376] dump_backtrace+0x0/0x188
[ 161.674103] show_stack+0x14/0x20
[ 161.677474] dump_stack_lvl+0x88/0xb0
[ 161.681201] dump_stack+0x14/0x2c
[ 161.684571] __schedule_bug+0x7c/0x90
[ 161.688298] __schedule+0x8bc/0x960
[ 161.691848] schedule+0x6c/0xf8
[ 161.695043] synchronize_irq+0x74/0xa8
[ 161.698858] rcar_dmac_device_synchronize+0x10/0x18
[ 161.703820] rsnd_dmaen_stop+0x40/0x50
[ 161.707633] rsnd_soc_dai_trigger+0x640/0x7c8
[ 161.712061] soc_dai_trigger+0x3c/0x80
[ 161.715875] snd_soc_pcm_dai_trigger+0xc0/0x168
[ 161.720481] soc_pcm_trigger+0x144/0x1b8
[ 161.724472] snd_pcm_do_stop+0x64/0x80
[ 161.728284] snd_pcm_action_single+0x44/0x98
[ 161.732625] snd_pcm_drain_done+0x20/0x28
[ 161.736701] snd_pcm_update_state+0xf4/0x128
[ 161.741043] snd_pcm_update_hw_ptr0+0x22c/0x3b0
[ 161.745649] snd_pcm_period_elapsed_under_stream_lock+0x64/0x88
[ 161.751665] snd_pcm_period_elapsed+0x24/0x40
[ 161.756092] rsnd_dai_period_elapsed+0x10/0x18
[ 161.760611] __rsnd_dmaen_complete+0x30/0x40
[ 161.764953] rsnd_mod_interrupt+0x90/0xe0
[ 161.769029] rsnd_dmaen_complete+0x14/0x20
[ 161.773194] rcar_dmac_isr_channel_thread+0x188/0x198
[ 161.778328] irq_thread_fn+0x28/0x88
[ 161.781963] irq_thread+0x158/0x1c8
[ 161.785510] kthread+0x14c/0x158
[ 161.788794] ret_from_fork+0x10/0x20
[ 199.053832] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 199.060273] rcu: 2-...0: (0 ticks this GP) idle=891/1/0x4000000000000000 softirq=3570/3570 fqs=3093
[ 199.070267] (detected by 0, t=6505 jiffies, g=8077, q=6)
[ 199.075940] Task dump for CPU 2:
[ 199.079339] task:aplay state:R running task stack: 0 pid: 513 ppid: 502 flags:0x00000202
[ 199.089753] Call trace:
[ 199.092333] __switch_to+0x12c/0x180
[ 199.096113] 0x3ec50aaa435c9700
[ 199.099421] snd_pcm_stream_lock_irq+0x30/0x38
Hi Shimoda-san, Morimoto-san,
Thanks for the report and to the testing team!
> I'm afraid but, our test team detected an issue [1] on v5.15-rc2 with m3ulcb and ebusu.
> # Our test team doesn't test this on salvator-xs yet...
> I asked Morimoto-san locally, and he guess that using dmaengine_terminate_async() instead
> of dmaengine_terminate_sync() could be resolved. But, what do you think?
I agree. As I wrote in the original mail, I wasn't too sure about this
change because I don't know the driver well. While I didn't find code
handling an async case, the driver still too complex so that might have
missed some details. This is why the patch was marked RFC. So, I totally
agree to drop this patch and handle the issue the async way. Is it
possible that Morimoto-san takes care of it? I'd think this makes sense
because he knows potential race conditions better than me. If it is not
possible, I will try to have a look.
All the best,
Wolfram