SOF probe fails to invalid HDA codec mask of 0x7

[kv2019i]

An issue has been detected both by data gathered by @wenqingfu from WW42-43 CI failures, and from manual test round of #1155 by validation team (@ClarexZhou) where following kernel signature is found in dmesg:

[ 4.475548 < 0.000350>] sof-audio-pci 0000:00:1f.3: codec_mask = 0x7

This is a fatal problem for current driver. When the non-existant codec is probed, the action will fail and whole driver probe will be aborted. In known configurations, mask should be 0x5, with addresses #0 and #2 populated.

When this occurs, following happens:
[ 5.480386 < 0.409756>] sof-audio-pci 0000:00:1f.3: error: codec #1 probe error, ret: -5
[ 5.480390 < 0.000004>] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power off
[ 5.480561 < 0.000171>] sof-audio-pci 0000:00:1f.3: error: no matching ASoC machine driver found - aborting probe
[ 5.480564 < 0.000003>] sof-audio-pci 0000:00:1f.3: error: failed to get machine info -19
[ 5.480565 < 0.000001>] sof-audio-pci 0000:00:1f.3: error: sof_probe_work failed err: -19

Examples in CI (WW42-43 data):

• https://sof-ci.01.org/sofpr/PR1987/build3678/devicetest/ICL_RVP_HDA/verify-sof-firmware-load.sh/dmesg.txt
• https://sof-ci.01.org/linuxpr/PR1337/build2192/devicetest/ICL_RVP_HDA/verify-pcm-list.sh/dmesg.txt

[ranj063]

@kv2019i just wondering if the codec probe fails because it doesnt exist, can we not ignore the failure and continue with the rest?

Or is the problem that the codec mask is wrong in the first place?

[kv2019i]

@kv2019i just wondering if the codec probe fails because it doesnt exist, can we not ignore the failure and continue with the rest?

Or is the problem that the codec mask is wrong in the first place?

@ranj063 Was thinking the same that we probably should make the driver robust against this case, so it doesn't fail if a codec that is not required by the topology, fails on probe. OTOH, I think we should also try to figure out why a non-existent codec is reported (so in that sense it's good this fails now, so we get a clear indication from CI logs when this happens).

[plbossart]

i think we should first figure out why this mask is incorrect. IIRC each field this is linked to the SDI address

[plbossart]

@kv2019i does this problem still exist?

[ranj063]

@kv2019i does this problem still exist?

@plbossart I think it does. it showed up on one of the CI test results today on my PR but disappeared after I re-ran the test

[ranj063]

@kv2019i I am seeing this again today https://sof-ci.01.org/linuxpr/PR1481/build2449/devicetest/ICL_RVP_HDA/verify-sof-firmware-load.sh/dmesg.txt

[kv2019i]

@plbossart yes, agree with @ranj063 , this still pops up in CI like the case above. I haven't yet had time to look at this, but let's definitely keep this open.