Re: [PATCH] ASoC: cs42l43-jack: Remove manual pm_runtime get/put from tip_sense_work

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Tue, Mar 17, 2026 at 11:36:10AM +0200, Péter Ujfalusi wrote:
> On 17/03/2026 11:11, Péter Ujfalusi wrote:
> > On 17/03/2026 08:21, Péter Ujfalusi wrote:
> >>> Fundamentally reseting a device right before checking what state
> >>> it was in is always going to be hard, so would be awesome if you
> >>> could have a look at how much of a problem removing that bus
> >>> reset would be.
> >>
> >> I'm still not sure if I get the whole picture, but by the hints it looks
> >> like that on systems with cs42l43 we cannot suspend the DSP since the
> >> codec cannot be suspended?

At least currently yeah, the problem is better phrased from the
codec side you can't reset the codec whilst some IRQs are
pending and then expect those IRQs to report correctly. The
device has no problem with the clock stop, its the reset that
causes issues.

> >> What is the difference between detecting the jack insert compared to
> >> detecting the jack removal and/or the HS button detection?
> >> Under the hood it is the same soundwire wake event then do what needs to
> >> be done to read the cause of the event, right?
> >> So, why it is OK to suspend the DSP when the jack is not inserted and it
> >> is not OK if it is inserted?

There are differences here, firstly between buttons and the jack
insert/removal, jack presence is a much more static event. This
means whilst all the state is lost on the reset, the codec can
easily rebuild that state. Buttons are more ephemeral, if it takes
too long to rebuild state the button will no longer be pressed.

Regarding differences between insert/remove, this mostly comes
down to the device issuing a jack removal IRQ on boot. As you see
below:

> > when the codec and DSP suspends when audio is idle:
> > snd_soc_cs42l43:cs42l43_stop_button_detect: cs42l43-codec cs42l43-codec:
> > Stop button detect
> > ...
> > snd_soc_cs42l43:cs42l43_start_button_detect: cs42l43-codec
> > cs42l43-codec: Start button detect
> > ...
> > snd_soc_cs42l43:cs42l43_button_press: cs42l43-codec cs42l43-codec:
> > Button ignored due to bias sense
> > ...
> > snd_soc_cs42l43:cs42l43_button_release: cs42l43-codec cs42l43-codec:
> > Button release IRQ
> 
> Event: time 1773739475.147018, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 0
> Event: time 1773739475.147018, type 5 (EV_SW), code 4 (SW_MICROPHONE_INSERT), value 0
> Event: time 1773739475.147018, type 5 (EV_SW), code 7 (SW_JACK_PHYSICAL_INSERT), value 0
> Event: time 1773739475.147018, -------------- SYN_REPORT ------------
> Event: time 1773739476.220776, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
> Event: time 1773739476.220776, type 5 (EV_SW), code 4 (SW_MICROPHONE_INSERT), value 1
> Event: time 1773739476.220776, type 5 (EV_SW), code 7 (SW_JACK_PHYSICAL_INSERT), value 1
> Event: time 1773739476.220776, -------------- SYN_REPORT ------------

This tends to means the reset will cause a full redetect of the
jack. Which is also quite undesirable, and will almost certainly
take too long to see the button. Not to mention doing the detect
whilst buttons are pressed is far from ideal, as it changes the
impedances seen.

I think I was occasionally seeing the jack detection get stuck as
well, although I would imagine that is just a driver issue
related to us not having fully thought through this flow
including the reset.

> > and the first button press is ignored  - which wakes the DSP, soundwire
> > and codec up
> > 
> > So yes, there seams to be an issue with the headset button handling here.
> 
> To note: on another MTL laptop with codec from different vendor I see the same thing.
> On LNL laptop (different codec) this works correctly.

I would not be surprised to see other vendors have some issues
here, I think it mostly comes down to what the device does with a
SoundWire bus reset, if the device treats it as a full reset,
which is heavily implied it should be by the spec, then problems
are very likely without special consideration.

Our newer devices are more friendly in handling this, but alas
cs42l43 is not. I will keep poking/thinking a bit, but I suspect
at least getting the first button detect out of a clock stop to
work reliably might not be feasible if we keep the bus reset.

Thanks,
Charles