public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: 刘博 <bo.liu@senarytech.com>
Cc: "'Takashi Iwai'" <tiwai@suse.de>, <perex@perex.cz>,
	<tiwai@suse.com>, <linux-sound@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ALSA: hda/conexant: Fix headset auto detect fail in cx8070 and SN6140
Date: Mon, 08 Jan 2024 09:42:38 +0100	[thread overview]
Message-ID: <87frz8i5c1.wl-tiwai@suse.de> (raw)
In-Reply-To: <002401da41e2$f159f5f0$d40de1d0$@senarytech.com>

On Mon, 08 Jan 2024 04:29:51 +0100,
刘博 wrote:
> 
> hi Takashi Iwai,
> 	Thank you very much for your patient guidance. Below is the reply to
> the question, please kindly correct it, thanks.
> 
> > +static void cx_fixup_headset_recog(struct hda_codec *codec) {
> > +	unsigned int mic_persent;
> > +
> > +	/* fix some headset type recognize fail issue, such as EDIFIER
> headset */
> > +	snd_hda_codec_write(codec, 0x1c, 0, 0x320, 0x010);
> > +	snd_hda_codec_write(codec, 0x1c, 0, 0x3b0, 0xe10);
> > +	snd_hda_codec_write(codec, 0x1c, 0, 0x4f0, 0x0eb);
> 
> Please use the defined verbs in sound/hda_verbs.h.
> The arguments (0x320, 0x010) are (AC_VERB_SET_AMP_GAIN_MUTE, 0x2010) etc.
> 
> Re: (0x1c, 0x320) is not amp gain register, but vendor defined register as
> rx control register. Use AC_VERB_SET_AMP_GAIN_MUTE will confused. It's
> similar to 0x4f0 and 0xca0.

Ah interesting.  But the verb is actually seen as
AC_VERB_SET_AMP_GAIN_MUTE -- although the resultant bits seem invalid.

HD-audio combines the verb and the value into 20 bits, e.g. (0x320,
0x10) is composed as 0x32010, and (0x3b0, 0xe10) is 0x3be10.
0x3xx is translated as SET_AMP_GAIN_MUTE, but in your case, 0x32010
leaves 0 to both the input/output bits (bits 14 and 15), which makes
it as invalid.

0x3be10 is another invalid verb, which sets SET_AMP_GAIN_MUTE with
OUTPUT, but it sets both LEFT and RIGHT, and passes a high index
(14).

And, what actually (0x4f0, 0x0eb) does?  It's composed as 0x4f0eb, and
in this case, it's a valid verb (SET_PROC_COEF + 0xf0eb).  But COEF is
vendor-specific, so it can be translated in everything the chip
wants.

So, if those verbs are vendor-specific ones, please define them and/or
give proper comments to explain what they do for each.


> Also, it's still not clear what if other nodes are used for headphone and
> mic pins -- or when either only headphone or only mic is present.
> A rare case, but we need to cover.
> 
> Re: in cx8070 and sn6140, only 0x16 and 0x19 can be used together as
> headset. Other nodes can be used separately as headphones or microphones,
> but not as headset, 
> so their configuration will not interfere with the type detection of
> headset.

OK, then explain this in comments, too (that we blindly assume those
pins).


> > +	/* fix reboot headset type recognize fail issue */
> > +	mic_persent = snd_hda_codec_read(codec, 0x19, 0,
> AC_VERB_GET_PIN_SENSE, 0x0);
> > +	if (mic_persent&0x80000000)
> 
> A coding style problem.  Similar issues seen in a few other places, too.
> Consult scripts/checkpatch.pl.
> 
> Re: was & need space? I have checked with scripts/checkpatch.pl before
> submitting the patch and there are no warnings or errors.

Yes.  Please put spaces around the operators.


> > +static void cx_process_headset_plugin(struct hda_codec *codec) {
> > +	unsigned int val;
> > +	unsigned int count = 0;
> > +
> > +	/* Wait headset detect done. */
> > +	do {
> > +		val = snd_hda_codec_read(codec, 0x1c, 0, 0xca0, 0x0);
> 
> Use the verb: AC_VERB_GET_PROC_COEF, 0xa000.
> At best, define the COEF values 0xa000 and 0xb000, and the corresponding
> value bits, too.
> 
> Re: (0x1c, 0xca0) is not COEF register, but vendor defined register as
> jacksense register.
> 
> > +static void cx_update_headset_mic_vref(struct hda_codec *codec, 
> > +unsigned int res) {
> > +	unsigned int phone_present, mic_persent, phone_tag, mic_tag;
> > +	struct conexant_spec *spec = codec->spec;
> > +
> > +	/* In cx8070 and sn6140, headset is fixed to use node 16 and node
> 19.
> 
> Is it really guaranteed?  IMO, we should check the pin configs beforehand at
> the parsing time.
> 
> Re: in cx8070 and sn6140, only 0x16 and 0x19 can be used together as
> headset. The node 16 can only be config to headphone or disable,
> The node 19 can only be config to microphone or disable. Only node 16 and
> node 19 both enable, the patch will process.

Then we still might need a check for the condition?


thanks,

Takashi

  reply	other threads:[~2024-01-08  8:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08  3:29 [PATCH] ALSA: hda/conexant: Fix headset auto detect fail in cx8070 and SN6140 刘博
2024-01-08  8:42 ` Takashi Iwai [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-01-08  9:46 刘博
2024-01-04 11:10 bo liu
2024-01-05 17:01 ` Takashi Iwai
2024-01-02  6:04 bo liu
2024-01-02 15:11 ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87frz8i5c1.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=bo.liu@senarytech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox