RE: [PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect

["Stefan Binding \(Opensource\)" <sbinding@opensource.cirrus.com>]

Hi,

> -----Original Message-----
> From: Stefan Binding <sbinding@opensource.cirrus.com>
> Sent: Wednesday, July 15, 2026 4:16 PM
> To: Steven Kendall <skend@chromium.org>
> Cc: Jaroslav Kysela <perex@perex.cz>; Takashi Iwai <tiwai@suse.com>; linux-
> sound@vger.kernel.org; linux-kernel@vger.kernel.org;
> patches@opensource.cirrus.com
> Subject: Re: [PATCH] ALSA: hda/cs8409: Fix for Dell Cirrus audio jack detect
> 
> Hi,
> 
> On 14/07/2026 20:26, Steven Kendall wrote:
> >> The original design on the driver relies on 2 different interrupts, one for Jack
> Detect, and one for Type Detect.
> >> I am concerned that these changes either prevent the interrupts from being
> enabled at the right time, or enable them at the wrong time, and possibly
> simultaneously.
> > Thanks for the info. I had trouble getting these interrupts to fire on
> > this machine. Have any advice for getting unsol events to fire? I
> > tried a few things but wasn't able to trigger any and resorted to
> > polling.
> 
> The interrupts not firing is very interesting. To give some background information
> on how the driver is intended to work:
> 
> There are 2 types of interrupts that the CS42L42 is configured to fire in this driver.
> The first is for Jack Plug/Unplug detection (which is enabled by the call to
> cs42l42_enable_jack_detect()), and the second is for Jack Type detection
> (enabled by the call to cs42l42_run_jack_detect()). The call to the second function
> disabled the interrupt of the first.
> 
> The intended flow for the driver is that when the system is initialised and
> resumed, the Jack Plug/Unplug interrupt is enabled, and thus if a jack is plugged
> or unplugged the interrupt fires, and upon plug, the driver then runs Jack Type
> detection.
> Eventually this calls snd_hda_jack_unsol_event() which informs the HDA core.
> 
> The Plug/Unplug interrupt will only fire on Plug/Unplug, whereas the Type
> Detection interrupt will always fire, regardless if where a jack is inserted.
> 
> This is why, after initialisation, the driver calls cs42l42_run_jack_detect(), to
> check the jack state after boot (since the plug interrupt could not have occurred).
> 
> Similarly, we also do the same upon resume. We could never get the codec wake
> to work properly, so whilst the driver is suspended, the codec is asleep, and the
> plug/unplug interrupt will not fire, and therefore will not wake the system. If you
> are expecting to see interrupts occurring whilst suspended, you will not see any.
> Instead, when audio starts and the driver is resumed, type detection is run
> immediately, which switches the Jack at that time.
> 
> On Ubuntu, the driver is resumed when you go the Sound settings menu, so you
> can see the interrupts firing when you insert or remove the jack.
> I am unsure if ChromeOS does the same. Alternatively, playing audio will resume
> the driver and the interrupts should fire upon jack plug/unplug.
> Inserting or removing the jack whilst suspended will not result in any interrupts
> until the driver is resumed (either by playback or by opening the setting menu in
> Ubuntu).
> 
> Thanks,
> 
> Stefan
> 
> >
> >> I believe we may have one of these laptops ourselves, so we might be able to
> have a look ourselves, though it may take a few weeks for us to do this.
> >> Can you tell us which OS you are using to test this? This was originally tested
> on Ubuntu, but I think this is ChromeOS you are testing on?
> > That would be great! A few weeks wouldn't be an issue for us. I've
> > tested this on Chrome OS (Chrome OS Flex, specifically) but I also
> > noticed some odd behavior on Ubuntu even though everything more or
> > less worked there. Alsa wasn't reading the jack state as
> > plugged/unplugged until audio played. I'm not sure if that's by
> > design. I wasn't sure if Ubuntu had some additional kernel patches I
> > couldn't find; I was using their LTS HWE branch and when deployed on
> > Chrome OS I didn't see any change in behavior.
> >

We have retested the hardware using Ubuntu 26.04, and everything works as expected.
The behaviour you describe where ALSA doesn’t detect plug/unplug until playback is
expected on this hardware, due to the way the CS8409 works.

As for ChromeOS Flex, do you have any instructions for us to try and install this to be able
for us to test this? Is there a particular image or version we should use?

Thanks,
Stefan