• Kuninori Morimoto's avatar
    ASoC: soc-pcm: Indicate warning if dpcm_playback/capture were used for availability limition · fd69dfe6
    Kuninori Morimoto authored
    I have been wondering why DPCM needs special flag (= dpcm_playback/capture)
    to use it. Below is the history why it was added to ASoC.
    
    (A) In beginning, there was no dpcm_xxx flag on ASoC.
        It checks channels_min for DPCM, same as current non-DPCM.
        Let's name it as "validation check" here.
    
    	if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
    		if (cpu_dai->driver->playback.channels_min)
    			playback = 1;
    		if (cpu_dai->driver->capture.channels_min)
    			capture = 1;
    
    (B) commit 1e9de42f ("ASoC: dpcm: Explicitly set BE DAI link supported
        stream directions") force to use dpcm_xxx flag on DPCM. According to
        this commit log, this is because "Some BE dummy DAI doesn't set
        channels_min for playback/capture". But we don't know which DAI is it,
        and not know why it can't/don't have channels_min. Let's name it as
        "no_chan_DAI" here. According to the code and git-log, it is used as
        DCPM-BE and is CPU DAI. I think the correct solution was set
        channels_min on "no_chan_DAI" side, not update ASoC framework side. But
        everything is under smoke today.
    
    	if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
    		playback = rtd->dai_link->dpcm_playback;
    		capture  = rtd->dai_link->dpcm_capture;
    
    (C) commit 9b5db059 ("ASoC: soc-pcm: dpcm: Only allow playback/capture
        if supported") checks channels_min (= validation check) again. Because
        DPCM availability was handled by dpcm_xxx flag at that time, but some
        Sound Card set it even though it wasn't available. Clearly there's
        a contradiction here. I think correct solution was update Sound Card
        side instead of ASoC framework. Sound Card side will be updated to
        handle this issue later (commit 25612477 ("ASoC: soc-dai: set
        dai_link dpcm_ flags with a helper"))
    
    	if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
    		...
    		playback = rtd->dai_link->dpcm_playback &&
    			   snd_soc_dai_stream_valid(cpu_dai, ...);
    		capture = rtd->dai_link->dpcm_capture &&
    			   snd_soc_dai_stream_valid(cpu_dai, ...);
    
    This (C) patch should have broken "no_chan_DAI" which doesn't have
    channels_min, but there was no such report during this 4 years.
    Possibilities case are as follows
    	- No one is using "no_chan_DAI"
    	- "no_chan_DAI" is no longer exist : was removed ?
    	- "no_chan_DAI" is no longer exist : has channels_min ?
    
    Because of these history, this dpcm_xxx is unneeded flag today. But because
    we have been used it for 10 years since (B), it may have been used
    differently. For example some DAI available both playback/capture, but it
    set dpcm_playback flag only, in this case dpcm_xxx flag is used as
    availability limitation. We can use playback_only flag instead in this
    case, but it is very difficult to find such DAI today.
    
    Let's add grace time to remove dpcm_playback/capture flag.
    
    This patch don't use dpcm_xxx flag anymore, and indicates warning to use
    xxx_only flag if both playback/capture were available but using only
    one of dpcm_xxx flag, and not using xxx_only flag.
    
    Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Tested-by: default avatarJerome Brunet <jbrunet@baylibre.com>
    Link: https://patch.msgid.link/87seuyaahn.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
    fd69dfe6
soc.h 54.8 KB