On Thu 09 May 2024 at 23:42, Kuninori Morimoto <kuninori.morimoto.gx@xxxxxxxxxxx> wrote: > Hi Jerome > > Thank you for your reply > >> >> If so, did you get below warning too ? >> >> "both playback/capture are available, but not using playback_only flag (%s)\n", >> >> >> >> I've checked. No such trace, no. > > OK, thanks > >> >> Card >> >> dpcm_playback = (0 or 1) >> >> dpcm_capture = (0 or 1) >> >> playback_only = (0 or 1) >> >> capture_only = (0 or 1) >> >> BE.CPU >> >> playback = (available, not available) >> >> capture = (available, not available) >> >> BE.Codec >> >> playback = (available, not available) >> >> capture = (available, not available) >> >> Expect >> >> playback = (available, not available) >> >> capture = (available, not available) >> >> I'm not too sure I undestand this. I'll try to illustrate the case >> raising the warning as precisely as possible bellow > > Thanks > > Because you got was > > (A) axg-sound-card sound: CPU capture is available but Codec capture is > not (be.dai-link-6) Please update Codec driver > > It is for BE. And validation check is for each rtd only, this means it checks > BE only, relationship with other rtd is not related here. > >> -------- >> |CPU BE| This is the TDM interface. Capable of both Playback and >> -------- Capture. Through routing it can be connected to Playback >> ^ and/or Capture FE CPUs. >> | >> V >> ------------- >> |BE Codec(s)| Possibly N codecs, supporting both direction, or a >> ------------- Single one, or one direction each. In this particular case >> | it is Playback only C2C. > > So, I think the warning happen here. > The validation check is checking this BE only. > > As I mentioned above, you use this BE through playback only FE and/or C2C, > but that relationship is not related to here. > > According to above explanation, this BE itself is available for both > playback and capture. And you didn't get below warning, I guess this BE > has both dpcm_playback/capture flag, and no xxx_only flag. > > "both playback/capture are available, but not using playback_only > flag (%s)\n", > Apparently so, but it should not. Before your patchset, axg-card.c (and gx-card.c) relied on snd_soc_dai_link_set_capabilities() to init dpcm_playback/capture flags. That was done following another semantic change on those flags: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/sound/soc/meson?h=v6.9-rc7&id=da3f23fde9d7b4a7e0ca9a9a096cec3104df1b82 - 1st problem: I see that following your removal of snd_soc_dai_link_set_capabilities(), the dpcm_playback/capture flags are no longer properly initialised in the amlogic card drivers. That will need fixing. Then, for TDM backends (like here), the tdm slots are checked and the direction is disabled if it has no slots: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/meson/axg-card.c?h=v6.9-rc7#n171 In theory, dpcm_capture should be 0 for this link which has no Rx slot: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi?h=v6.9-rc7#n218 ... Sooo, that is 2nd problem > Before my patch, the validation check is checks CPU-BE only, but it also > checks BE-Codec after my patch, and you got the warning (A). Yes I've got that. I was not expecting a failure on this case TBH. I was more looking for the infamous 2 codecs case, each with a single direction (which I did not check yet ...) > > So, I guess your BE-Codec simply missing capture channels_min settings. > Please double check it, or please tell me which codec driver this BE is > using. Here the codec: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/meson/g12a-tohdmitx.c?h=v6.9-rc7 > > static struct snd_soc_dai_driver xxx_dai = { > ... > .playback = { > ... > .channels_min = x, > ... > }, > .capture = { > ... > => .channels_min = x, > ... > }, This codec is not meant to have capture channels. I think DT description and the card driver settings (before the removal of snd_soc_dai_link_set_capabilities()) are correct. IMO, those check become too restrictive. We are adding a lot of code I'm not sure I understand what we stand by going so far in the consistency checks. Initially those dpcm_playback/capture flag could be used to just forcefully disable a link direction, regardless of the CPUs or codecs present on the link. It was just another setting and it was not required to be consistent with anything. It just declared whether the direction was allowed on the link, or not. It changed this commit, and the flags suddenly needed to be consistent with whatever was on link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/sound/soc?h=v6.9-rc7&id=b73287f0b074 I complained back then and I still don't think this change was good. If the flags needs to consistent with what is on the link, and we have the ability to check it, why let card drivers set it and then complain about it in ASoC checks ? Why not deal with it in the framework directly ? I think the simplest solution would to just go back to the initial meaning of these flags which was just the card driver declaring the direction allowed/disallowed on a link. Then ASoC can mix that information with whatever it finds with DAI drivers and figure out what is actually possible. It would give a clear and separate semantic meaning to those flags instead something redundant with the DAI driver info. What we have currently is not straight forward to set and check. It makes the code unnecessarily complicated and difficult to maintain. I think the difficulties with this patchset are a good illustration of that, unfortunately. > }, > >> But I noticed that we want to update below. I'm happy if it can solve your >> issue. >> >> - if (has_playback && !has_playback_both) >> + if (has_playback && !has_playback_both && !dai_link->capture_only) >> dev_warn(rtd->card->dev, ...) >> >> - if (has_capture && !has_capture_both) >> + if (has_capture && !has_capture_both && !dai_link->playback_only) >> dev_warn(rtd->card->dev, ...) >> >> Honestly I'm a bit lost in all these flag :/ > > Thanks, no problem, me too :9 > > Unfortunately and confusingly, there are many combination exist around here. My point exactly ;) > But because of your feedback, I noticed one missing pattern. Thanks > > > Thank you for your help !! Thanks a lot for all those reworks ! > > Best regards > --- > Renesas Electronics > Ph.D. Kuninori Morimoto -- Jerome
