Hi Pierre-Louis Cc Mark
Your explanation seems to contradict the sentence above "This availability check should be available not only for DPCM, but for all connections."
Can we actually do this 'availability check' for non-DPCM connections.
How about this ?
If either playback or capture assertion flag was presented, not presented direction will be disabled by ASoC even if it was available.
Did you mean
" The playback (resp. capture) direction will be disabled by ASoC if the playback_assertion (resp. capture) flag is false - even if this direction was available at the DAI level "
(0, 0) : Both are not must item. available direction is used as-is. But it will be error if nothing was available.
That new wording makes me even more confused. What does 'available' refer to and at which level is this?
This seems also to contradict the definitions above, "available direction is used as-is" is not aligned with "not presented direction will be disabled by ASoC even if it was available".
It is complicated by the attempt to merge dpcm_xxx and xxx_only flags. And I noticed that my one of other attemption was not indicated.
Let's cleanup what does this patch-set want to do
I still wondering why dpcm_xxx flag itself is needed.
(A) Before, it checks channels_min for DPCM, same as current non-DPCM. This is very clear for me. Let's name this as "validation check"
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 1e9de42f4324b91ce2e9da0939cab8fc6ae93893 ("Explicitly set BE DAI link supported stream directions") force use to dpcm_xxx flag
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) { playback = rtd->dai_link->dpcm_playback; capture = rtd->dai_link->dpcm_capture;
(C) 9b5db059366ae2087e07892b5fc108f81f4ec189 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported") checks channels_min (= validation check) again
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) { cpu_dai = asoc_rtd_to_cpu(rtd, 0); ... playback = rtd->dai_link->dpcm_playback && snd_soc_dai_stream_valid(cpu_dai, SNDRV_PCM_STREAM_PLAYBACK); capture = rtd->dai_link->dpcm_capture && snd_soc_dai_stream_valid(cpu_dai, SNDRV_PCM_STREAM_CAPTURE);
(D) b73287f0b0745961b14e5ebcce92cc8ed24d4d52 ("ASoC: soc-pcm: dpcm: fix playback/capture checks") expanded it to multi connection.
So, I would say nothing has changed, but become more complicated. Or if (B) added dpcm_xxx as "option flag", it was understandable for me. like this
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) { playback = (cpu_dai->driver->playback.channels_min > 0) || rtd->dai_link->dpcm_playback; capture = (cpu_dai->driver->capture.channels_min > 0) || rtd->dai_link->dpcm_capture;
So my opinion is this dpcm_xxx is unnecessary flag that only complicate matters. I guess almost all Card don't need this flag, this means "validation check" only is veryenough, same as current non-DPCM.
But because of these history, dpcm_xxx flag have been used as "passage permit" or "gate way". It doesn't try to "validation check" if dpcm_xxx flag was not set. This is the reason why I try to merge dpcm_xxx and xxx_only flag. These are doing the same things with dirrerent flags, IMO.
OTOH, some Card want to detect error if expected direction (playback/capture) was not valid. I guess this is your commitment (?).
So, let's keep xxx_only flag as-is, and use dpcm_xxx as "available_check". I'm not sure what is the good naming, but for example "playback_available_check" flag means "owner is expecting playback is valid/available, and want to receive error if not".
I'm not sure how many owner want this flag, thus I think "option flag" is very enough (= not mandatory, as I mentioned in the patch-set).
If we makes these checks generalize, For DPCM, (for example new DPCM) it can remove/ignore "available_check" flag if it don't need, same as current non-DPCM. And for non-DPCM, it can use "available_check" if needed, same as current DPCM.
What do you think ? what is your opinion ?
Thank you for your help !!
Best regards --- Renesas Electronics Ph.D. Kuninori Morimoto