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

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

On Mon, Mar 16, 2026 at 04:37:28PM +0200, Péter Ujfalusi wrote:
> On 16/03/2026 16:27, Charles Keepax wrote:
> > On Mon, Mar 16, 2026 at 02:49:24PM +0200, Peter Ujfalusi wrote:
> > Hmm... yes, I have this feeling this was in here for a reason I
> > should probably have left a comment here. I somewhat agree it
> > looks a bit mad with fresh eyes. The variable is also only used
> > for tracking this pm_runtime_get so you can drop the jack_present
> > variable from the struct as well, if we take the patch forward.
> 
> That was my thinking as well, but then when the headset buttons did
> worked after the patch on an idle system (ARL laptop) then I thought
> that this might no longer be needed?

Hmm... are you sure that was working? Tried removing it (on
MTL here) and I see quite a few issues.

> Fwiw, I have been banging my head on why the DSP is not suspending ever
> on the laptop and the system is not hitting lower C state because of
> this when I had some spare time and studied the code and then removed
> the jack and boom, the DSP suspended right away :o

Apologies for that :-)

> Sure, but draining battery when the jack is connected is not a great
> added feature of a codec driver.
> The type-Cs are on the other side of the laptop, so taping the jack and
> power together is not a workable solution - to disconnect jack if power
> is removed ;)

I am not sure there are many other solutions. I will burn a few
cycles investigating here, but I suspect its going to come down
to a choice of two solutions:

 1) The one already in the code.
 2) Stop the host from reseting the codec.

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.

> Even then there is the issue of unbalance in runtime get on module
> removal when the jack is connected...

Yeah that is a good spot, if we stick with the current code I
will get that fixed up.

Thanks,
Charles