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

["Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>]

On 17/03/2026 13:44, Charles Keepax wrote:
> On Tue, Mar 17, 2026 at 08:21:12AM +0200, Péter Ujfalusi wrote:
>> On 16/03/2026 18:40, Charles Keepax wrote:
>>> 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:
>>>  1) The one already in the code.
>>>  2) Stop the host from reseting the codec.
>>
>> The issue with 1 (how it is atm) is that it is done in a completely
>> wrong place. I think the cs42l43 can be used with other than Intel MTL,
>> let's say Qualcomm or AMD?
>> If there is a workaround needed for something on the platform, it has to
>> be done in the platform code.
> 
> There is probably a discussion to be had here, its far from clear
> to me this is the wrong place to do this. Generally the codec
> controls when the codec wants to mark itself as runtime active.
> For example on our phone devices where far more of the chip
> powered down in runtime suspend having a jack in would always
> keep the device powered up so the button detect could run,
> as the lowest power states disabled that.

I see, what about this:
if the inserted accessory is CS42L43_JACK_HEADSET (SND_JACK_HEADSET)
then do one more pm_runtime_get() to allow the button presses to be handled?
This would allow the laptop to hit lower power state if a headphone is
connected, headphones do not have buttons as they don't have mic ring.

The jack_plugged would be renamed as jack_is_headset or something and
drop the rpm on jack removal for headset ( and on module remove).

> It is also appears the specification doesn't prohibit issuing
> a bus reset when coming out of a mode 0 clock stop (which seems
> bonkers to me, given literally the only difference between that
> and a mode 1 clock stop is that the mode 1 clock stop resets the
> device). But without the specification prohibiting this then
> the device can't rely on the host not to do it, so doing this
> could be required on any platform.
> 
> I can however see the argument that it would be nice to only
> force the codec out of runtime suspend on platforms where this is
> necessary but its not obvious to me what the sensible mechanism
> would be.
> 
> Thanks,
> Charles

-- 
Péter