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

[Stefan Binding <sbinding@opensource.cirrus.com>]

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.
>