[PATCH RFC] ASoC: sh: rcar: dma: : use proper DMAENGINE API for termination
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 wsa+renesas@sang-engineering.com ---
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; }
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 wsa+renesas@sang-engineering.com
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
participants (3)
-
Mark Brown -
Wolfram Sang -
Yoshihiro Shimoda