No soundcard detected with nomodeset kernel option Dell XPS 17 9720 SKU 0AFE

[halobarrlets]

If I boot without nomodeset kernel option then audio works properly but if I boot with nomodeset kernel option then no soundcard is detected.
Maybe firmware is waiting for HDMI from dGPU and fail if no HDMI is detected.
I'm using Debian unstable with latest kernel 6.5.0-rc6+ from https://github.com/thesofproject/linux and firmware-sof-signed 2.2.6-1.
dmesg-with-nomodeset.txt
dmesg-without-nomodeset.txt

[plbossart]

looks like a graphics issue to me

[  107.538619] sof-audio-pci-intel-tgl 0000:00:1f.3: couldn't bind with audio component
[  107.538683] sof-audio-pci-intel-tgl 0000:00:1f.3: init of i915 and HDMI codec failed

[  107.940305] sof-audio-pci-intel-tgl 0000:00:1f.3: error: can't connect DAI HDA0.OUT stream iDisp1
[  107.940310] sof-audio-pci-intel-tgl 0000:00:1f.3: error: failed to add widget id 0 type 27 name : HDA0.OUT stream iDisp1
[  107.940328] sof_sdw sof_sdw: ASoC: failed to load widget HDA0.OUT
[  107.940332] sof_sdw sof_sdw: ASoC: topology: could not load header: -22
[  107.940349] sof-audio-pci-intel-tgl 0000:00:1f.3: error: tplg component load failed -22
[  107.940362] sof-audio-pci-intel-tgl 0000:00:1f.3: error: failed to load DSP topology -22
[  107.940365] sof-audio-pci-intel-tgl 0000:00:1f.3: ASoC: error at snd_soc_component_probe on 0000:00:1f.3: -22
[  107.940392] sof_sdw sof_sdw: ASoC: failed to instantiate card -22

@kv2019i @ujfalusi any ideas?

[ujfalusi]

The nomodeset will make the i915 driver to not probe, only simpledrmfb will provide some sort of video output.
Interestingly this will make an SDW platform to fail to probe the audio because nothing have been found on the HDA bus:
modeset:

[   43.640669] sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 4

nomodeset:

[  107.548651] sof-audio-pci-intel-tgl 0000:00:1f.3: no hda codecs found!

Interestingly, because on a HDA platform:
modeset

[    3.867265] sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 5

nomodeset

[   66.733433] sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 1

and the card probes, we have HDMI PCMs present, but obviously they don't work.

Note also that the audio probing takes a long time to kick in both SDW and HDA platforms.

[ujfalusi]

The reason why the HDA platform manages to create the sound card is due to a 'bug' in sound/soc/codecs/hdac_hda.c:
#4509 (comment)

The hdac_hda.c creates the display DAIs unconditionally and it does that when the analog codec is probed (the HDMI never probes, it is not available on the HDA bus):

sof-up-xtreme:[root]:~# cat /sys/kernel/debug/asoc/components 
snd_sof.hda-probes.0
0000:00:1f.3
ehdaudio0D0
dmic-codec
snd-soc-dummy
snd-soc-dummy
sof-up-xtreme:[root]:~# cat /sys/kernel/debug/asoc/dais 
snd_sof.hda-probes.0
SSP0 Pin
SSP1 Pin
SSP2 Pin
SSP3 Pin
SSP4 Pin
SSP5 Pin
DMIC01 Pin
DMIC16k Pin
iDisp1 Pin
iDisp2 Pin
iDisp3 Pin
iDisp4 Pin
Analog CPU DAI
Digital CPU DAI
Alt Analog CPU DAI
HDMI1
HDMI2
HDMI3
HDA Analog
DeepBuffer
Analog Codec DAI
Digital Codec DAI
Alt Analog Codec DAI
intel-hdmi-hifi1
intel-hdmi-hifi2
intel-hdmi-hifi3
intel-hdmi-hifi4
dmic-hifi
snd-soc-dummy-dai

With ujfalusi@1fa9470 the HDA platform also fails to create the sound card:

sof-up-xtreme:[root]:~# cat /sys/kernel/debug/asoc/components 
snd_sof.hda-probes.0
0000:00:1f.3
ehdaudio0D0
dmic-codec
snd-soc-dummy
snd-soc-dummy
sof-up-xtreme:[root]:~# cat /sys/kernel/debug/asoc/dais 
snd_sof.hda-probes.0
SSP0 Pin
SSP1 Pin
SSP2 Pin
SSP3 Pin
SSP4 Pin
SSP5 Pin
DMIC01 Pin
DMIC16k Pin
iDisp1 Pin
iDisp2 Pin
iDisp3 Pin
iDisp4 Pin
Analog CPU DAI
Digital CPU DAI
Alt Analog CPU DAI
Analog Codec DAI
Digital Codec DAI
Alt Analog Codec DAI
dmic-hifi
snd-soc-dummy-dai

[ujfalusi]

I'm not sure how to fix this, if it needs to be fixed at all. The tplg contains the HDMI link, it has to be present, I would guess if we would have a no-hdmi flavor of the topologies then we could select those somehow in case the i915 is not available?

[kv2019i]

@ujfalusi @bardliao I think we should handle this like in HDA mach driver. Have the nodes in topology, but mach driver ignores them if display codec is not detected at runtime. This is a corner case, but still something that can be hit (e.g. nomodeset, or systems with runtime options to switch between internal and external GPU).

[ujfalusi]

@kv2019i, right, but that bug in the hdac_hda must be fixed, creating the HDMI dai when the analog codec is probing is not correct, creating it again and again for each probed HDA codec is a bug.

[bardliao]

We could use a postfix in topology name for the devices that no HDMI is available. For example, sof-adl-rt711-l0-rt1316-l12-rt714-l3-no-hdmi.tplg. What do you think? @plbossart @kv2019i

[ujfalusi]

but we don't have the means to deal with the postfixing and it is not clear what to do if the i915 is not available at the time we probe that audio, but it is probing later (deferred probing).
The only solution might be to move the display audio out as a sof-client to have a separate sound card if the display stack is available.

[kv2019i]

@bardliao we can use the same topology (like HDA generic) does. if i915 is not available at probe, the HDMI links will be connected to dummy codec instead. If i915 is enabled later, the audio driver needs to be reloaded (or we move later to the separate HDMI client solution).

[ujfalusi]

@kv2019i, that would 'solve' the deferred probing hassle and we can just get rid of the probe workqueue? Is this really a solution?
The topology require specific DAI to be present, so we need to mangle that if the i915/xe is not yet loaded and present dummy display audio PCMs?
Can this be done in a sane way?

If the i915/xe driver loads later then SOF then SOF should defer and be probed after the i915/xe, right?
If we modify the card to use dummy codec when i915/xe is not available at probe time and later the display probes then what? User has to remove the audio modules and load them again. Is that something that we can expect a user will happily do?

User preventing the display driver to probe (nomodeset, module deny list, etc) is entirely different case, right?
If the machine have dGPU and user wants to disable the iGPU, that is something different again and it is kind of valid thing which we don't support atm.

If the user does this then probably we should have a module parameter to SOF to ignore the display PCMs? no-display-audio?
I mean, the user on purpose disabled the display stack, it is not far fetched that he/she is capable of adding another module option.

[halobarrlets]

There is also a specific use case with hardware isolation in VM:
https://www.qubes-os.org/news/2020/03/18/gui-domain/#audio-domain
In this case only PCI audio device will be passthrough to the VM and without GPU it'll fail like this:

snd_hda_intel 0000:00:05.0: DSP detected with PCI class/subclass/prog-if info 0x040100
snd_hda_intel 0000:00:05.0: NHLT table not found
snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec
snd_hda_intel 0000:00:05.0: Cannot probe codecs, giving up

[plbossart]

We could use a postfix in topology name for the devices that no HDMI is available. For example, sof-adl-rt711-l0-rt1316-l12-rt714-l3-no-hdmi.tplg. What do you think? @plbossart @kv2019i

Absolutely no. It's painful enough to have to maintain the 70-odd SoundWire topologies, I don't want to add one more degree of freedom. We really need to have a mechanism where parts of the topology are disabled by the machine driver, this is the 'hardware' layer I've been talking about for more than 2 years. The topology should not assume that a resource is always present or assigned exactly to the same pin/FIFO.

[ujfalusi]

@plbossart, how do we know if the resource (HDMI/DP) is genuinely missing or it is just going to be loaded later?

[plbossart]

Things will fail either way @ujfalusi

I think it's a corner case honestly. We've supported Dell devices on 5 generations of SoundWire devices and it's the first time this issue came up. What is the reason to use 'nomodeset' in the first place?

[ujfalusi]

There is also a specific use case with hardware isolation in VM: https://www.qubes-os.org/news/2020/03/18/gui-domain/#audio-domain In this case only PCI audio device will be passthrough to the VM and without GPU it'll fail like this:

snd_hda_intel 0000:00:05.0: DSP detected with PCI class/subclass/prog-if info 0x040100
snd_hda_intel 0000:00:05.0: NHLT table not found
snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec
snd_hda_intel 0000:00:05.0: Cannot probe codecs, giving up

I see, so the OS in the VM will use the audio directly?
The OS in VM should not treat the audio identically as it is running on bare metal, I think.
We should be picking different topology (since i915 is not available inside of the VM) and machine driver, probably some quirk is needed to be able to handle this sort of use?

[kv2019i]

@ujfalusi The deferred probe patch is a new complication. But let's assume current sof-dev (and mainline kernel) code. We can have the following case:

• i915 support is compiled in
• the system has a Intel graphics device present (visible in lspci)
• i915 driver is not functional due to out-of-band configuration (user has blacklisted the driver, some scenarios where external GPU is used instead on a system that also has IGFX visible to OS, or i915 just doesn't work for the hardware)

With current code and HDA machine driver, the failed display codec enumeration is logged, but audio probe continues. The availability of display codec is passed to machine driver, and the machine driver (the HDA generic) will connected the HDMI/DP DAIs to the dummy codec driver (if functional i915 driver is not available).

With the deferred probe patch (now in review on alsa-devel), to get audio in such cases user would have to set a specific module parameter to let audio probe without waiting for i915/xe driver. But also in this case, we should have capability to pass information about whether display codec is there or not, from the controller driver to machine driver. We do not want to clone all topologies we have to cover for this case (which still can happen!).

[ujfalusi]

Things will fail either way @ujfalusi

Well, if we should be defer probing because i915/xe is probed later than we absolutely should do that and not 'assume' that there is no display driver at all, so drop the HDMI PCMs, this is like 99.99% of the users, the 0.01% might run with disabled i915/xe.

[kv2019i]

@ujfalusi wrote.

Well, if we should be defer probing because i915/xe is probed later than we absolutely should do that and not 'assume' that there is no display driver at all, so drop the HDMI PCMs, this is like 99.99% of the users, the 0.01% might run with disabled i915/xe.

That's exactly why we have the code to load i915 in audio driver and we have the 60sec timeout. With the new deferred probe, the 0.01% of users need to use a kernel module option as we no longer can know whether to load i915 or the new xe driver.

But we do need the ability in mach drivers to support patching out HDMI support with dummy codecs if for some reason i915/xe driver was not available. This has worked well with HDA, and I can't see why we can't follow same approach for SDW.

[halobarrlets]

@plbossart

Things will fail either way @ujfalusi

I think it's a corner case honestly. We've supported Dell devices on 5 generations of SoundWire devices and it's the first time this issue came up. What is the reason to use 'nomodeset' in the first place?

I had a problem with graphics driver but I didn't look into why exactly it happened.
I had Debian 11 installed without non-free firmware and kernel 6.0 and then I've updated it to Debian unstable with kernels 6.1, 6.4, 6.5 as I needed to test audio with never kernels.
With kernel 6.0 I could boot just fine without graphics problems.
But with kernel 6.1/6.4/6.5 boot hangs after this message:
i915 000:00:02.0: [drm] VT-d active for gfx access
With nomodeset option I could boot normally but audio didn't work.
Then I just reinstalled system using Debian 12 image with non-free firmware installed by default and I didn't have this problem with newer kernels.
So my guess is that this problem was most probably because of NVIDIA open-source driver or maybe some old configuration from Debian 11 that didn't work with newer kernels and new hardware.

So the nomodeset option may be required for those who have new hardware but don't want to use proprietary non-free graphics firmware.

[ujfalusi]

@halobarrlets, can you try this diff:

diff --git a/sound/soc/intel/boards/sof_sdw.c b/sound/soc/intel/boards/sof_sdw.c
index c96fdde78076..55163bedde3e 100644
--- a/sound/soc/intel/boards/sof_sdw.c
+++ b/sound/soc/intel/boards/sof_sdw.c
@@ -1596,14 +1596,13 @@ static int sof_card_dai_links_create(struct snd_soc_card *card)
 		ssp_num = hweight_long(ssp_mask);
 	}
 
-	if (mach_params->codec_mask & IDISP_CODEC_MASK) {
+	if (mach_params->codec_mask & IDISP_CODEC_MASK)
 		ctx->idisp_codec = true;
 
-		if (sof_sdw_quirk & SOF_SDW_TGL_HDMI)
-			hdmi_num = SOF_TGL_HDMI_COUNT;
-		else
-			hdmi_num = SOF_PRE_TGL_HDMI_COUNT;
-	}
+	if (sof_sdw_quirk & SOF_SDW_TGL_HDMI)
+		hdmi_num = SOF_TGL_HDMI_COUNT;
+	else
+		hdmi_num = SOF_PRE_TGL_HDMI_COUNT;
 
 	/* enable dmic01 & dmic16k */
 	if (sof_sdw_quirk & SOF_SDW_PCH_DMIC || mach_params->dmic_num)

it makes the card to appear on my device when booting with nomodeset

[halobarrlets]

@ujfalusi
Yes, with this patch the audio works with nomodeset option:
dmesg-nomodeset-patch.txt

[ujfalusi]

this is a good starting point but we should be looking at a module parameter.
There is a huge delay which is not acceptable in real use:

[   71.510992] memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=1061 'pulseaudio'
[  109.586503] sof-audio-pci-intel-tgl 0000:00:1f.3: couldn't bind with audio component

It would be also great if we could yank the display PCMs altogether if a module parameter is present and telling t hat ignore the display side.

[halobarrlets]

@ujfalusi I've tested first with just aplay as pulseaudio was disabled so I had to start it manually and then test the pulseaudio later. I'll enable pulseaudio and attach the boot log with it enabled.

UPD:
Here it is:
dmesg-nomodeset-patch-with-pulseaudio.txt

[kv2019i]

@ujfalusi We have this to disable display codec:

options snd_sof_intel_hda codec_mask=0x1

... this won't skip the 60sec delay. For that, Maarten's series (still in review on alsa-devel) will get rid of the timeout and add an new option to ignore. In sof-dev we have this #4537 , but that will be obsolete with Maarten's series.

So plenty of options available.
UPDATE: but the SDW mach driver interface indeed does need a fix to handle this

[halobarrlets]

@kv2019i

@ujfalusi We have this to disable display codec:

options snd_sof_intel_hda codec_mask=0x1

... this won't skip the 60sec delay. For that, Maarten's series (still in review on alsa-devel) will get rid of the timeout and add an new option to ignore. In sof-dev we have this #4537 , but that will be obsolete with Maarten's series.

So plenty of options available. UPDATE: but the SDW mach driver interface indeed does need a fix to handle this

There is no separate HDMI codec to be masked, I have only one codec available on this laptop:

!!HDA-Intel Codec information
!!---------------------------
--startcollapse--

Codec: Intel Alderlake-P HDMI
Address: 2

alsa-info.txt

[ujfalusi]

@halobarrlets, codec_mask=0x1 will disable the HDMI codec since it will only allow the codec at address 0, since you don't have that then there will be no HDA codecs probed, but that would likely cause other issues.

[ujfalusi]

@halobarrlets, #4639 should fix the issue, it would be great if you could test it.

It is essentially the same patch I have pasted in #4594 (comment)

[halobarrlets]

@ujfalusi, I've tested your PR and can confirm that it fixes this issue with nomodeset.

dmesg logs for reference:
dmesg-with-nomodeset.txt
dmesg-without-nomodeset.txt