Hi Jerome
Thank you for your feedback
> DPCM
> [CPU/xxxx]-[xxxx/Codec]
> ^^^^ (A)
(snip)
> DPCM
> [CPU/xxxx]-[xxxx/Codec]
> ^^^^^^^^^ ^^^^^^^^^^ (B)
(snip)
> > if ((dai_link->no_pcm) &&
> ^ Actually my comment applies to all links, DPCM backend or not
(snip)
> A codec that does not support playback and does not support capture does
> not support much, does it ? ;)
Unfortunately, some codec which is used on DPCM BE doesn't have
.channels_min = 1 settings which is used on snd_soc_dai_stream_valid().
At least Intel is using it. For both Playback/Capture.
But it *was* no problem, because (A) part was not checked before.
Because of this background, [01/15] patch is using dummy Codec
to avoid (B) check.
[15/15] patch will indicate WARNING for such codec driver
instead of just avoiding.
At least, below are the drivers. It is mentioned in git-log.
sound/soc/codecs/hda.c
sound/pci/hda/patch_hdmi.c
dai_link->no_pcm only is OK I think, because it needs to keep
compatibility and try to indicates warning for (A) and/or (B) part.
If such things happen on FE side, it is just error, not warning.
> (!cpu_play_t && !codec_capture_t)) {
>
> Then at first glance, maybe ... CPU and codec seem to exclude each other but
> that will only work as long as DCPM is limited to a single CPU per link.
Hmm ?? I'm confusing
Did you copy-and-paste miss ??
I have never indicate this pair
+ I have indicated before
- I have not
+ ( cpu_capture_t && !codec_capture_t) // in [15/15] patch
+ (!codec_play_t && !codec_capture_t) // in previous mail
- (!cpu_play_t && !codec_capture_t)
and I'm sorry but I can't understand what you want to tell me.
Do you mean Multi-CPU case ?
If you can indicate Image or code, it can more help me.
Thank you for your help !!
Best regards
---
Renesas Electronics
Ph.D. Kuninori Morimoto
