[LNL] multiple cases failing to HDMI playback on SDW configurations with gpu_bind disabled #5098
Comments
kv2019i
added
bug
|
FYI @lyakh |
|
Observed in today's daily run https://sof-ci.ostc.intel.com/#/result/planresultdetail/43591?model=LNLM_SDW_AIOC&testcase=check-playback-all-formats on jf-lnlm-rvp-sdw-1 Other LNL configurations are indeed not affected. |
|
Could this be caused by some device-specific configuration? It did not happen on EDIT: failed on
|
|
This issue still reproducible on latest. Currntly we have WA "NO_HDMI_MODE=true" is set on device enviroment so we are not seeing issue in CI results. |
|
Only affecting LNL, TGL/MTL HDMI is working fine? |
|
@ujfalusi this is not observed on MTL. I will check on TGL and update |
|
I think @ujfalusi @bardliao @plbossart there's a problem in sof_sdw mach driver handling the case where display driver is not available and no HDMI PCms are available: But topology has (as it should) the HDMI nodes: |
|
I don't understand how the display driver became unavailable? |
|
we have this in the configuration: https://sof-ci.ostc.intel.com/#/result/planresultdetail/43591?model=LNLM_SDW_AIOC&testcase=verify-kernel-boot-log why is this value cleared? static int gpu_bind = -1;
module_param(gpu_bind, int, 0644);
MODULE_PARM_DESC(gpu_bind, "Whether to bind sound component to GPU "
"(1=always, 0=never, -1=on nomodeset(default))");looks like a stale CI configuration to me, if we want to test HDMI this should not be cleared. |
|
@plbossart wrote:
It wasn't available in sof-dev yet for this platform (not marked as stable yet in kernel --> this can be overridden in the device configuration -> let me go and check this particular device). UPDATE: edit, we still have commit 003bd60 in sof-dev and we can't remove until we pull in stable version of the xe support or we change the test device configurations to apply a force probe. |
@kv2019i, we should have dummy links for the HDMI PCMs to probe. They will not work, but they need to be there to be able to load the topology. |
|
We do have dummy links, the problem is not the probe: for (i = 0; i < hdmi_num; i++) {
char *name = devm_kasprintf(dev, GFP_KERNEL, "iDisp%d", i + 1);
char *cpu_dai_name = devm_kasprintf(dev, GFP_KERNEL, "iDisp%d Pin", i + 1);
char *codec_name, *codec_dai_name;
if (intel_ctx->hdmi.idisp_codec) {
codec_name = "ehdaudio0D2";
codec_dai_name = devm_kasprintf(dev, GFP_KERNEL,
"intel-hdmi-hifi%d", i + 1);
} else {
codec_name = "snd-soc-dummy";
codec_dai_name = "snd-soc-dummy-dai";
}
ret = asoc_sdw_init_simple_dai_link(dev, *dai_links, be_id, name,
1, 0, // HDMI only supports playback
cpu_dai_name, platform_component->name,
ARRAY_SIZE(platform_component),
codec_name, codec_dai_name,
i == 0 ? sof_sdw_hdmi_init : NULL, NULL);
if (ret)
return ret;
(*dai_links)++;
}It's the error on hw_params that needs to be root-caused. |
|
the debug log is misleading dev_dbg(dev, "sdw %d, ssp %d, dmic %d, hdmi %d, bt: %d\n",
sdw_be_num, ssp_num, dmic_num,
intel_ctx->hdmi.idisp_codec ? hdmi_num : 0, bt_num);hdmi_num is 4 on TGL and 3 on all other devices, so we do create 3+ links. |
|
The HDMI PCM never worked when there were no HDMI hardware, it has been like this with HDA devices also. The hw_params fails because of the missing real DAI. |
|
That's not true @ujfalusi , this has been working but has been broken at some point. It seems some of the changes to HDA DAI ops now return -EINVAL when dummy codec driver is connected. This DID work in the past. UPDATE: I can confirm this is broken on TGL as well if HDMI is disable via codec_mask. This did work in the past, will bisect to see where this got broken. |
|
@kv2019i, I'm not sure about past, but now it is not working on tgl either: |
|
I'm sure about the past :) -- but this is not just for debug, this is actual product config for HDA where there is Intel GPU is disabled for reason or another. Granted most of these laptops use the non-SOF driver, but there are actual product configs with dmic (=SOF) and some other GPU, so this dummy codec construct must work! |
|
@kv2019i, I trust your memory. It did not worked on 18.09.2023: #4594 (comment) Can this be the reason: #4659 ? |
kv2019i
changed the title
kv2019i
added
P2
|
No, it's not #4659 -- this is probably older. I'll lower the priority now as this is not hit at card probe and normal applications will not open the HDMI if no monitor is detected (and no monitor ever will on these devices). So the remaining open is Pulseaudio/Pipewire habit of opening the PCMs and doing a hw_params query. Maybe -EINVAL is ok for this case as well (and my memory really malfunctions here). If so, we can close this. |
|
Tested with upstream 6.8 kernel and pipewire 0.3.79 (versions used in 24.04LTS) and the -EINVAL errors at pipewire start are handled correctly and rest of audio functionalty is ok. So I'll close this as works-as-expected ad we can track the test device configuration issues elsewhere. |
Some interaction with recently merged kernel and FW PRs has caused a high rate failure to occur in PR testing:
https://sof-ci.01.org/sofpr/PR9116/build6350/devicetest/index.html
The gpu_bind should be disabled in sof-dev kernel, so not sure why HDMI playback is attempted.
Related PRs merged recently:
As this is seen in PR testing marking as P1.
The text was updated successfully, but these errors were encountered: