[v4,0/3] ASoC: grace time for DPCM cleanup

Message

Kuninori Morimoto May 23, 2024, 2:11 a.m. UTC

Hi Mark, Pierre-Louis, Jerome
Cc each ASoC driver maintainer

This is v4 of DPCM cleanup

As we discussed in [1], we don't need to use dpcm_playback/capture flag,
so we remove it. But we have been using it for 10 years, some driver might
get damage. The most likely case is that the device/driver can use both
playback/capture, but have only one flag, and not using xxx_only flag.
[1/3] patch indicates warning in such case.

These adds grace time for DPCM cleanup.
I'm not sure when dpcm_xxx will be removed, and Codec check bypass will be
error, but maybe v6.11 or v6.12 ?
Please check each driver by that time.

Previous patch-set try to check both CPU and Codec in DPCM, but we noticed
that there are some special DAI which we can't handle today [2]. So I will
escape it in this patch-set.

[1] https://lore.kernel.org/r/[e-mail]
[2] https://lore.kernel.org/all/[e-mail]/

Link: https://lore.kernel.org/r/[e-mail]
Link: https://lore.kernel.org/r/[e-mail]
Link: https://lore.kernel.org/r/[e-mail]

v3 -> v4
	- don't check Codec on DPCM
	- include Jerome's dpcm_xxx update patch

v2 -> v3
	- tidyup typo (reuqsts -> requests)
	- add Tested-by on git-log

v1 -> v2
	- tidyup Codec check warning output condition



Jerome Brunet (1):
  ASoC: amlogic: do not use dpcm_playback/capture flags

Kuninori Morimoto (2):
  ASoC: soc-pcm: Indicate warning if dpcm_playback/capture were used for availability limition
  ASoC: remove snd_soc_dai_link_set_capabilities()

 include/sound/soc-dai.h               |  1 -
 include/sound/soc.h                   |  1 +
 sound/soc/fsl/imx-card.c              |  3 --
 sound/soc/generic/audio-graph-card.c  |  2 -
 sound/soc/generic/audio-graph-card2.c |  2 -
 sound/soc/generic/simple-card.c       |  2 -
 sound/soc/meson/axg-card.c            | 11 +++--
 sound/soc/meson/gx-card.c             |  1 -
 sound/soc/meson/meson-card-utils.c    |  4 +-
 sound/soc/qcom/common.c               |  1 -
 sound/soc/soc-dai.c                   | 38 ----------------
 sound/soc/soc-pcm.c                   | 65 +++++++++++++++------------
 12 files changed, 45 insertions(+), 86 deletions(-)

Comments

Pierre-Louis Bossart May 23, 2024, 10:43 p.m. UTC | #1

Hi Morimoto-san,

> This is v4 of DPCM cleanup
> 
> As we discussed in [1], we don't need to use dpcm_playback/capture flag,
> so we remove it. But we have been using it for 10 years, some driver might
> get damage. The most likely case is that the device/driver can use both
> playback/capture, but have only one flag, and not using xxx_only flag.
> [1/3] patch indicates warning in such case.
> 
> These adds grace time for DPCM cleanup.
> I'm not sure when dpcm_xxx will be removed, and Codec check bypass will be
> error, but maybe v6.11 or v6.12 ?

We're already finding warnings on all Intel SoundWire platforms:

The DAIs are declared as supporting playback AND capture, but in
practice they can only support one direction at a time.

The direction is defined by the dailink when it includes specific DAIs.

So if you don't mind I'd prefer it if we shared a patch with you to be
included in a v5, to make sure at least the Intel platforms tested in CI
are all ok from Day1, otherwise we're going to get lots of noise
reported for no good reason.
Shouldn't take long.

Kuninori Morimoto May 23, 2024, 11:24 p.m. UTC | #2

Hi Pierre-Louis

> We're already finding warnings on all Intel SoundWire platforms:
> 
> The DAIs are declared as supporting playback AND capture, but in
> practice they can only support one direction at a time.
> 
> The direction is defined by the dailink when it includes specific DAIs.
> 
> So if you don't mind I'd prefer it if we shared a patch with you to be
> included in a v5, to make sure at least the Intel platforms tested in CI
> are all ok from Day1, otherwise we're going to get lots of noise
> reported for no good reason.
> Shouldn't take long.

Thank you for reporting. OK, no problem.
I will fixup pointed typo, and merge your patches into v5.

Thank you for your help !!

Best regards
---
Renesas Electronics
Ph.D. Kuninori Morimoto