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

[Akihiko Odaki]

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