Kai Vehmanen

Ack @iuliana-prodan , SOF drivers should still be doable. We did the initial IPC4 work with SOF driver interface and only later moved to native drivers, so both have worked....

We have #4443 still open, not sure this is the same. It seems we get stuck with i915. The display codec is visible on the bus: dmesg_ERR.txt: ``` [ 5.331766]...

Thanks @kovalev0 . Hmm, so this actually looks to be ok: ``` окт 27 15:03:12 mimic7subtle kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) окт 27 15:03:12 mimic7subtle kernel: i915...

Needs more investigation. The codec driver can return -EBUSY if there are no free slots. It's possible something has changed in uptream that would trigger this.

P2 so not gating SOF2.8, pushing out to v2.9.

@Vamshigopal @plbossart But with runtime-pm enabled, snd-hda-intel is a good reference (CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1). With audio controller+codec in runtime suspend, we should wake-up on jack-detect (but not if system is suspended)

I tested with today's sof-dev on a generic HDA system and jack detection works 10/10 with both legacy driver and SOF. Let's try to get snd-hda-intel driver going to suspend...

FYI @RanderWang @ranj063 @ujfalusi @plbossart -- the deepbuffer PCM has some unexpected behaviour towards the user-space. Not necessarily a problem for apps that can handle this, but e.g. this won't...

@andyross Is this still an issue or was this specific to https://github.com/thesofproject/sof/issues/8638 (given the fix for that was in the end on LInux kernel side) ? I agree this is...

Ack, that scenario should work. In in fact, I can confirm we have regularly such cases where the DSP panics in a CI run, and the Linux kernel does recover....