[bardliao]

There is no HDMI support on MTL RVP for now.

Signed-off-by: Bard Liao yung-chuan.liao@linux.intel.com

[bardliao]

I am not sure if this PR is the right solution. Or we should enable HDMI on SDW mode on MTL RVP?

[kv2019i]

@bardliao Can't we use same solution we've used for all past platforms and have HDMI in topologies, but it's just not always used (handle with dummy codec). This will anyways be needed for product tplgs as well, as the integrated graphics solution may be disabled/not-used on some products.

[bardliao]

@bardliao Can't we use same solution we've used for all past platforms and have HDMI in topologies, but it's just not always used (handle with dummy codec). This will anyways be needed for product tplgs as well, as the integrated graphics solution may be disabled/not-used on some products.

@kv2019i This PR is to remove the HDMI from MTL SoundWire RVP topology. The issue is that somehow HDMI is not enabled on MTL SDW RVP and HDMI is not supported by MTL SDW topology until #6787

[kv2019i]

@bardliao wrote:

@kv2019i This PR is to remove the HDMI from MTL SoundWire RVP topology. The issue is that somehow HDMI is not enabled on MTL SDW RVP and HDMI is not supported by MTL SDW topology until #6787

But we also have HDMI failure on ADL:
https://sof-ci.01.org/sofpr/PR6946/build3345/devicetest/index.html?model=ADLP_RVP_SDW_IPC4ZPH&testcase=verify-kernel-boot-log

[ 7.768601] kernel: snd_soc_sof_sdw:sof_card_dai_links_create: sof_sdw sof_sdw: sdw 2, ssp 0, dmic 2, hdmi 4
[...]
[ 7.772592] kernel: sof_sdw sof_sdw: ASoC: physical link iDisp1 (id 5) not exist
[ 7.772619] kernel: sof_sdw sof_sdw: ASoC: topology: could not load header: -22

... and that surely has HDMI. So something's not adding up. The sof_sdw.c mach driver is checking the codec mask, and if HDMI is not available (e.g. IGFX disabled), then snd-soc-dummy is used instead.

If you remove HDMI from the topology, that will break if sof_sdw.c finds a HDMI codec. I think we should do the opposite, always have the HDMI nodes unless it is a hardware that will never have HDMI.

[bardliao]

@bardliao wrote:

@kv2019i This PR is to remove the HDMI from MTL SoundWire RVP topology. The issue is that somehow HDMI is not enabled on MTL SDW RVP and HDMI is not supported by MTL SDW topology until #6787

But we also have HDMI failure on ADL: https://sof-ci.01.org/sofpr/PR6946/build3345/devicetest/index.html?model=ADLP_RVP_SDW_IPC4ZPH&testcase=verify-kernel-boot-log

[ 7.768601] kernel: snd_soc_sof_sdw:sof_card_dai_links_create: sof_sdw sof_sdw: sdw 2, ssp 0, dmic 2, hdmi 4 [...] [ 7.772592] kernel: sof_sdw sof_sdw: ASoC: physical link iDisp1 (id 5) not exist [ 7.772619] kernel: sof_sdw sof_sdw: ASoC: topology: could not load header: -22

That's exactly why I add

"cavs-sdw\;sof-adl-rt711-4ch\;DEEPBUFFER_FW_DMA_MS=100,NUM_DMICS=4,DMIC0_ID=2,\
DMIC1_ID=3,PDM1_MIC_A_ENABLE=1,PDM1_MIC_B_ENABLE=1,HDMI1_ID=4,HDMI2_ID=5,\
HDMI3_ID=6"

in 217ca35
We still see the issue because the DUT use cavs-sdw.tplg and rename it to sof-adl-rt711-4ch.tplg.
We should use sof-adl-rt711-4ch.tplg directly.

... and that surely has HDMI. So something's not adding up. The sof_sdw.c mach driver is checking the codec mask, and if HDMI is not available (e.g. IGFX disabled), then snd-soc-dummy is used instead.

Currently, sof_sdw will not create HDMI dai_links. But, yes using snd-soc-dummy is a good idea. I will do it after CNY.

If you remove HDMI from the topology, that will break if sof_sdw.c finds a HDMI codec. I think we should do the opposite, always have the HDMI nodes unless it is a hardware that will never have HDMI.

No, it will not break. The topology can be a subset of dai_links. I.e. Having HDMI on machine driver and not on topology is allowed.

[kv2019i]

I'm ok with this change as a development step that helps to keep CI healthy. For product tplg, the HDMI needs to be included.

There are some issues in CI still, so not approving until we understand the cause. So will these be fixed by #6957 or do we need change in DUT configuration in CI (to not copy/rename tplgs but copy them as is, FYI to @marc-hb ).

[bardliao]

I'm ok with this change as a development step that helps to keep CI healthy. For product tplg, the HDMI needs to be included.

There are some issues in CI still, so not approving until we understand the cause. So will these be fixed by #6957 or do we need change in DUT configuration in CI (to not copy/rename tplgs but copy them as is, FYI to @marc-hb ).

@kv2019i The change is only for MTL RVP. We don't have topology for MTL SDW products yet.

[kv2019i]

#6957 now merged. Let's check CI again for this one.

[kv2019i]

SOFCI TEST

[kv2019i]

CI looks clean now. A few issues, but not related to this PR.

[marc-hb]

I think you mean https://sof-ci.01.org/sofpr/PR6946/build3413/devicetest/index.html

For comparison, unrelated https://sof-ci.01.org/sofpr/PR6960/build3411/devicetest/index.html is still failing ADLP_RVP_SDW_IPC4ZPH

EDIT2: and a bit later https://sof-ci.01.org/sofpr/PR6959/build3416/devicetest/index.html is now passing, maybe because sof_use_tplg_nhlt was changed? #6957 (comment)

[ranj063]

@bardliao @kv2019i are we still going to do "Currently, sof_sdw will not create HDMI dai_links. But, yes using snd-soc-dummy is a good idea. I will do it after CNY."? and will that fix the issue targetted here? If so, can we please comment that in the cmakelists?

[bardliao]

@bardliao @kv2019i are we still going to do "Currently, sof_sdw will not create HDMI dai_links. But, yes using snd-soc-dummy is a good idea. I will do it after CNY."? and will that fix the issue targetted here? If so, can we please comment that in the cmakelists?

Yes, I will comment that in the Cmakelists

[bardliao]

@bardliao @kv2019i are we still going to do "Currently, sof_sdw will not create HDMI dai_links. But, yes using snd-soc-dummy is a good idea. I will do it after CNY."? and will that fix the issue targetted here? If so, can we please comment that in the cmakelists?

Updated