Hi Pierre-Louis, Mark
Thank you for clarifying the issue.
allow me to give you another counter example, beyond the AEC reference I mentioned earlier. It's not uncommon for CPU DAIs to have loopback capabilities, which are used for tests on boards where the codec has no capture capabilities. I think it's a feature that needs to be allowed, not a 'wrong setting'.
This helped me to understand the situation.
For now we're kind of stuck, what I would suggest is just to remove the extra check that both CPU and codec dai can support a direction, and move on with the other cleanups suggested by Morimoto-san.
Oh, I agree - my point is that as things stand the framework really can't cope with what needs expressing so we need these things that don't look quite right.
I think same situation can be happen not only DPCM, but normal connection, too ? And my personally want to have validation check as much as possible, and automatically validation without Card/rtd flags.
In case of ignoring Codec check on DPCM, it allows unexpected direction, I think. For example if it is not using dummy DAI, and in case of CPU can playback/capture, Codec can playback, and user expect playback only, in this case unexpected "capture" will be available. He need to add playback_only flag, but it is not good for me.
Can we avoid validation check if DAI has some kind of new flag, like ignore_pair ?
pseudo code is like this
if (valid(cpu, PLAYBACK)) has_cpu_playback = 1;
if (valid(cpu, CAPTURE)) has_cpu_capture = 1;
if (valid(codec, PLAYBACK)) has_codec_playback = 1;
if (valid(codec, CAPTURE)) has_codec_capture = 1;
if (cpu->ignore_pair) { has_codec_playback = 1; has_codec_capture = 1; }
if (codec->ignore_pair) { has_cpu_playback = 1; has_cpu_capture = 1; }
Or more detail ignore_pair_playback, ignore_pair_capture
Thank you for your help !!
Best regards --- Renesas Electronics Ph.D. Kuninori Morimoto