> Because Japanese will dive into long vacation since next week, > I want to post mail before that. I will back at 7th May. Enjoy! >>>> (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; >>> >>> The reason for this (B) addition is very clear from the commit message >>> >>> " >>> Some BE DAIs can be "dummy" (when the DSP is controlling the DAI) and as >>> such wont have set a minimum number of playback or capture channels >>> required for BE DAI registration (to establish supported stream directions). >>> " >> >> I'm still not yet 100% understand around this "dummy" DAI, but is it >> *not* soc-utils.c :: dummy_dai, but some original dummy DAI is used >> somewhere ? >> >> I know ${LINUX}/sound/soc/codecs/hda.c :: card_binder_dai is one of >> the DAI which is used but doesn't have channels_min. >> I think it is used as BE "Codec", but code is checking "CPU" side. >> >> Do you know what does this "BE dummy DAI" specifically means here? > > (A) : checked CPU capabilities > (B) : uses dpcm_xxx flag > (C) : checks both dpcm_xxx and capabilities > ... > > In my understanding, in summary, this dpcm_xxx flag was added to rescue > dummy DAI which is used on DCPM BE as CPU at (B), because some of them > might not have channels_min (This "dummy DAI" is not same as soc-utils's > dummy DAI). Let's name it as "no_chan_DAI" here. > In this patch, it was added as "mandatory flag", not "option flag", > thus all DPCM needed to use this dpcm_xxx flag. > > After that (C) was added, but it was contradiction, because > it checks both dpcm_xxx and channels_min. > If my understanding was correct, original "no_chan_DAI" was supposed to > stop working, because it doesn't have channels_min. But there is no > such report after (C), during this 4 years. > We don't know which DAI is the "no_chan_DAI" (?) > > Possibilities are as follows > - No one is using "no_chan_DAI" > - "no_chan_DAI" is no longer exist : it was removed ? > - "no_chan_DAI" is no longer exist : it has channels_min ? > > If my expectation was correct, we don't need dpcm_xxx anymore. I agree with your analysis. We don't have a clear memory/understanding of which "no_chan_DAI" platforms (B) was supposed to handle, and why no one reported them as broken by (C). > But because we have been used dpcm_xxx for 10 years since (B), > I understand to feel anxious to suddenly remove dpcm_xxx. Indeed we err on the side of paranoia with such changes! > I think it should be removed anyway, but want to have grace time ? > If so, the idea is that we can use it as "option flag" instead of > "mandatory flag" for a while, like below > > 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; > > * maybe we want to indicate message like "place re-check the flag and > remove it" via dev_info() if dpcm_xxx flag was used ? > > I think +2 kernel version or so is enough for grace time ? > After that, we can remove dpcm_xxx flag. I am good with that plan, but I'll need to investigate first why we had a failure with one of the Chromebooks on this v3 patchset. That may give us some insights on "special" uses of those flags. > When we consider it very detail, above code can't 100% keep compatibility > if the user have been used this dpcm_xxx flag to limit availability, > for example in case of DAI can use both playback/capture, but it had > dpcm_playback flag only. But it can use playback_only flag, instead. > But it is very difficult to find such DAI. Each user need to check. > > I personally think that remove dpcm_xxx directly is no ploblem, but what > do you think ? I'm happy to hear any opinion, and happy to create > grace time code if someone want, but if there was no comment during > Japanese long vacation, I will create patch to remove dpcm_xxx directly. > > > BTW, I would like to know detail things around this topic. I'm happy if > someone knows it. > > * Why dummy DAI doesn't/can't have channels_min ? > > * Why it checks CPU side channels_min only when DPCM ? > I think it should check both CPU and Codec. > I could understand if it checks FE:CPU and BE:Codec (it is assuming > other side was dummy), but both (FE/BE) check CPU side only...