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
