On 5/19/24 18:31, Kuninori Morimoto wrote:
Current DCPM is checking CPU side availability only, but it should also check Codec availability. But because of long DPCM operation history, it is possible that the some Codec driver check have been bypassed.
It should be error, but let's add grace time to update driver.
This patch indicates warning in above case. Each applicable driver need to update during this grace time.
...
/** REMOVE ME** Current DPCM is checking CPU side only, but both CPU and Codec should be* checked. Indicate warning if there was CPU / Codec mismatch.* To keep compatibility, warning only for now.*/if ((dai_link->dpcm_playback || dai_link->playback_only) &&!has_playback_both)dev_warn(rtd->card->dev,"System requests playback, but not available (%s)."" Please update Codec driver\n",dai_link->stream_name);if ((dai_link->dpcm_capture || dai_link->capture_only) &&!has_capture_both)dev_warn(rtd->card->dev,"System requests capture, but not available (%s)."" Please update Codec driver\n",dai_link->stream_name);
I mentioned in my previous feedback that this isn't quite right. There are cases where the CPU dai reports capabilities that the codec DAI does not support - e.g. when the AEC reference is generated in firmware on the host DSP.
And sure enough we get that warning in the first test:
https://sof-ci.01.org/linuxpr/PR5005/build3040/devicetest/index.html?model=G...
May 20 13:35:38 jf-glk-bob-da7219-1 kernel: sof_da7219 glk_da7219_def: System requests capture, but not available (SSP1-Codec). Please update Codec driver
For those systems, trying to match CPU and codec dais is not going to work. Either we skip this verification or we have an escape mechanism to avoid triggering errors.