diff mbox series

[RFC] ASoC: sh: rcar: dma: : use proper DMAENGINE API for termination

Message ID 20210623100545.3926-1-wsa+renesas@sang-engineering.com (mailing list archive)
State Accepted
Commit d5bb69dc54ec1e09f3fd626fdb9c340c0511dbd5
Headers show
Series [RFC] ASoC: sh: rcar: dma: : use proper DMAENGINE API for termination | expand

Commit Message

Wolfram Sang June 23, 2021, 10:05 a.m. UTC
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(-)

Comments

Mark Brown July 12, 2021, 10:46 a.m. UTC | #1
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
Yoshihiro Shimoda Oct. 4, 2021, 1:04 a.m. UTC | #2
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
Wolfram Sang Oct. 4, 2021, 9:46 a.m. UTC | #3
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
diff mbox series

Patch

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;
 }