Re: [PATCH] ASoC: rt5682: Add jack kcontrol

[Akihiko Odaki <akihiko.odaki@gmail.com>]

On 2022/04/08 1:37, Mark Brown wrote:
> j
> On Fri, Apr 08, 2022 at 01:11:22AM +0900, Akihiko Odaki wrote:
>> On 2022/04/08 1:00, Mark Brown wrote:
> 
>>> That bit is very common but there's still machine specific aspects - is
>>> the required hardware wired up, if it is wired up how exactly are things
>>> wired (separate microphone jack, headset jack, one of many jacks?).  A
>>> lot of the machine driver part of things is about labeling things so
>>> that it can be displayed in a way that's easy to connect to the physical
>>> system.  Generally the machine driver would define a jack and then
>>> connect the CODEC to it.
> 
>> Whether the required hardware wired is told from the user of the codec via
>> jack's type specified with snd_soc_card_jack_new(). The other details live
>> in the codec.
> 
> So I'm confused about what problem this patch is intended to fix.  It
> really sounds like there's some issue with the driver not using standard
> interfaces that you're trying to work around but the changelog is not at
> all clear.  The "doesn't use DAPM" bit is a bit of a warning sign, it
> sounds like the audio signals to and from the CODEC aren't being
> connected to the jack properly.
> 
> Look at how other devices with jack detection hardware handle this and
> follow a similar pattern.

The situation actually seems quite a mess. You can find many drivers not 
using DAPM pins by searching for snd_soc_card_jack_new() calls with 
num_pins argument is 0. ams-delta-audio is exceptional as it adds DAPM 
pins later with snd_soc_jack_add_pins().

They do not have kcontrols for the jacks. The only exception is 
skl_hda_dsp_generic which calls snd_jack_add_new_kctl() as my patch 
does. Looking at other devices is probably not helpful to find an 
alternative in this case.

Regards,
Akihiko Odaki