* snd jack report and unsolicited event ad1988
@ 2011-05-05 7:05 Raymond Yau
2011-05-05 9:50 ` Takashi Iwai
0 siblings, 1 reply; 5+ messages in thread
From: Raymond Yau @ 2011-05-05 7:05 UTC (permalink / raw)
To: Takashi Iwai, ALSA Development Mailing List
2011/4/28 Takashi Iwai <tiwai@suse.de>
> At Thu, 28 Apr 2011 21:10:23 +0800,
> Raymond Yau wrote:
> >
>
> > Still unable to enable the unsolicited event for jack sense even if I add
> > the unsol_event and verb for the audio jacks at rear panel since I don't
> > have the HDA compilant front audio panel
> >
> > SoundMax automatically popup immediately when jack is plug into the rear
> > panel at other OS, so the hardware is capable of jack sense at rear panel
> >
> > AFG Function Id: 0x1 (unsol 0)
> >
> > Is there any trick to enable/debug the unsolicited event ?
> > seem unsol event is disabled in the HDA controller
>
> No, there shouldn't be big differences. Otherwise it won't work on
> any other machines.
>
> There might be other way to trigger the jack detection, e.g. GPIO
> unsolicited event, depending on the codec chip. I don't remember how
> is AD1988, though...
>
>
> OK, after a few experiments, unsolicited events seem to work for those rear
panel jacks
1) for the unsolicited event , different tags have to be assigned for six
different jacks
This mean that the driver need to define FRONT_MIC_EVENT, REAR_MIC_EVENT,
LINE_IN_EVENT in addition to HP_EVENT
Can snd_jack_report used to report the mic event of two pink jacks (front
panel and rear panel) of the desktop to the user space program?
2) when the jack is plug in or out. , snd_hda_jack_detect() work with
no_trigger_sense=1 to detect jack presence but the driver get several
unsolicited responses with no_trigger_sense=0
3) snd_hda_pin_sense() need trigger sense to get the Impedance
it usually get the value of 0x7FFF,FFFF and need to wait for a while to get
the sense measurement
(all1’s) indicates that a valid sense reading is not available, or the sense
measurement is busy if it has been recently triggered
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: snd jack report and unsolicited event ad1988 2011-05-05 7:05 snd jack report and unsolicited event ad1988 Raymond Yau @ 2011-05-05 9:50 ` Takashi Iwai 2011-05-09 3:56 ` Raymond Yau 0 siblings, 1 reply; 5+ messages in thread From: Takashi Iwai @ 2011-05-05 9:50 UTC (permalink / raw) To: Raymond Yau; +Cc: ALSA Development Mailing List At Thu, 5 May 2011 15:05:41 +0800, Raymond Yau wrote: > > 2011/4/28 Takashi Iwai <tiwai@suse.de> > > > At Thu, 28 Apr 2011 21:10:23 +0800, > > Raymond Yau wrote: > > > > > > > > Still unable to enable the unsolicited event for jack sense even if I add > > > the unsol_event and verb for the audio jacks at rear panel since I don't > > > have the HDA compilant front audio panel > > > > > > SoundMax automatically popup immediately when jack is plug into the rear > > > panel at other OS, so the hardware is capable of jack sense at rear panel > > > > > > AFG Function Id: 0x1 (unsol 0) > > > > > > Is there any trick to enable/debug the unsolicited event ? > > > seem unsol event is disabled in the HDA controller > > > > No, there shouldn't be big differences. Otherwise it won't work on > > any other machines. > > > > There might be other way to trigger the jack detection, e.g. GPIO > > unsolicited event, depending on the codec chip. I don't remember how > > is AD1988, though... > > > > > > OK, after a few experiments, unsolicited events seem to work for those rear > panel jacks > > 1) for the unsolicited event , different tags have to be assigned for six > different jacks > > This mean that the driver need to define FRONT_MIC_EVENT, REAR_MIC_EVENT, > LINE_IN_EVENT in addition to HP_EVENT Does it mean that the codec can't accept the same id tag for multiple pins? > Can snd_jack_report used to report the mic event of two pink jacks (front > panel and rear panel) of the desktop to the user space program? I assumed so, but someone needs to confirm. Assigning different tags is easy and safe, so even if it worked, we can go forward for individual tags. > 2) when the jack is plug in or out. , snd_hda_jack_detect() work with > no_trigger_sense=1 to detect jack presence but the driver get several > unsolicited responses with no_trigger_sense=0 > > 3) snd_hda_pin_sense() need trigger sense to get the Impedance > it usually get the value of 0x7FFF,FFFF and need to wait for a while to get > the sense measurement > > (all1’s) indicates that a valid sense reading is not available, or the sense > measurement is busy if it has been recently triggered So, adding some delay like below makes it working? thanks, Takashi --- diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index c63f376..211d136 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -1593,9 +1593,12 @@ u32 snd_hda_pin_sense(struct hda_codec *codec, hda_nid_t nid) if (!codec->no_trigger_sense) { pincap = snd_hda_query_pin_caps(codec, nid); - if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */ + if (pincap & AC_PINCAP_TRIG_REQ) { /* need trigger? */ snd_hda_codec_read(codec, nid, 0, AC_VERB_SET_PIN_SENSE, 0); + if (codec->trigger_delay > 0) + mdelay(codec->trigger_delay); + } } return snd_hda_codec_read(codec, nid, 0, AC_VERB_GET_PIN_SENSE, 0); diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index 59c9730..a46aae4 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -865,6 +865,8 @@ struct hda_codec { unsigned long power_jiffies; #endif + int trigger_delay; /* msecs delay after trigger-sense */ + /* codec-specific additional proc output */ void (*proc_widget_hook)(struct snd_info_buffer *buffer, struct hda_codec *codec, hda_nid_t nid); diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c index 981c631..3818b87 100644 --- a/sound/pci/hda/patch_analog.c +++ b/sound/pci/hda/patch_analog.c @@ -3317,7 +3317,8 @@ static int patch_ad1988(struct hda_codec *codec) #endif spec->vmaster_nid = 0x04; - codec->no_trigger_sense = 1; + /* codec->no_trigger_sense = 1; */ + codec->trigger_delay = 5; codec->no_sticky_stream = 1; return 0; _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: snd jack report and unsolicited event ad1988 2011-05-05 9:50 ` Takashi Iwai @ 2011-05-09 3:56 ` Raymond Yau 2011-05-09 12:09 ` Takashi Iwai 0 siblings, 1 reply; 5+ messages in thread From: Raymond Yau @ 2011-05-09 3:56 UTC (permalink / raw) To: Takashi Iwai, ALSA Development Mailing List 2011/5/5 Takashi Iwai <tiwai@suse.de> >> This mean that the driver need to define FRONT_MIC_EVENT, REAR_MIC_EVENT, >> LINE_IN_EVENT in addition to HP_EVENT >Does it mean that the codec can't accept the same id tag for multiple >pins? No, the event can be received by the event handler but there is no way to know the event is related to which jack >> Can snd_jack_report used to report the mic event of two pink jacks (front >> panel and rear panel) of the desktop to the user space program? > I assumed so, but someone needs to confirm. > Assigning different tags is easy and safe, so even if it worked, we > can go forward for individual tags. So the point is whether the user space program need to know 1) the event is related to the plug in or out of the front mic jack / rear mic jack 2) whether earphone or speaker is plugged into correct/wrong jacks by measured impedance . So, adding some delay like below makes it working? > if (!codec->no_trigger_sense) { > pincap = snd_hda_query_pin_caps(codec, nid); > - if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */ > + if (pincap & AC_PINCAP_TRIG_REQ) { /* need trigger? */ > snd_hda_codec_read(codec, nid, 0, > AC_VERB_SET_PIN_SENSE, 0); > + if (codec->trigger_delay > 0) > + mdelay(codec->trigger_delay); > + } > } > return snd_hda_codec_read(codec, nid, 0, > AC_VERB_GET_PIN_SENSE, 0); > Noise appear when delay is add at here Have to wait until someone find a safe way to get the impedance without any side effect spec->vmaster_nid = 0x04; > > - codec->no_trigger_sense = 1; > + /* codec->no_trigger_sense = 1; */ > + codec->trigger_delay = 5; > codec->no_sticky_stream = 1; > > return 0; > So no need to change if the objective of snd_hda_jack_detect() is to get presence detect bit As mentioned in 729d55ba972348234759f8e40abf8d e020f0d505 use tigger at pin-sensing seem generate a lot of responses Is there any way to stop the measurement ? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: snd jack report and unsolicited event ad1988 2011-05-09 3:56 ` Raymond Yau @ 2011-05-09 12:09 ` Takashi Iwai 2011-05-18 2:10 ` Raymond Yau 0 siblings, 1 reply; 5+ messages in thread From: Takashi Iwai @ 2011-05-09 12:09 UTC (permalink / raw) To: Raymond Yau; +Cc: ALSA Development Mailing List At Mon, 9 May 2011 11:56:11 +0800, Raymond Yau wrote: > > 2011/5/5 Takashi Iwai <tiwai@suse.de> > > >> This mean that the driver need to define FRONT_MIC_EVENT, REAR_MIC_EVENT, > >> LINE_IN_EVENT in addition to HP_EVENT > > >Does it mean that the codec can't accept the same id tag for multiple > >pins? > > No, the event can be received by the event handler but there is no way to > know the event is related to which jack Yeah, sure, if you want to distinguish each pin, you have to assign different ids. But it's independent from my question. Your statement sounded as if the multiple pins aren't allowed to have the same tag on AD codec. But, it seems that it's OK, judging from your follow up. > >> Can snd_jack_report used to report the mic event of two pink jacks > (front > >> panel and rear panel) of the desktop to the user space program? > > > I assumed so, but someone needs to confirm. > > Assigning different tags is easy and safe, so even if it worked, we > > can go forward for individual tags. > > So the point is whether the user space program need to know > > 1) the event is related to the plug in or out of the front mic jack / rear > mic jack > 2) whether earphone or speaker is plugged into correct/wrong jacks by > measured impedance . In some time future, yes, a program like PulseAudio would like to know and behave reactively to the plug state. But, in that case, the whole driver design should be changed -- the kernel driver should do as little as possible regarding the jack task switching. > > So, adding some delay like below makes it working? > > > > if (!codec->no_trigger_sense) { > > pincap = snd_hda_query_pin_caps(codec, nid); > > - if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */ > > + if (pincap & AC_PINCAP_TRIG_REQ) { /* need trigger? */ > > snd_hda_codec_read(codec, nid, 0, > > AC_VERB_SET_PIN_SENSE, 0); > > + if (codec->trigger_delay > 0) > > + mdelay(codec->trigger_delay); > > + } > > } > > return snd_hda_codec_read(codec, nid, 0, > > AC_VERB_GET_PIN_SENSE, 0); > > > > Noise appear when delay is add at here In which situation? From unplugged to plugged? > Have to wait until someone find a safe way to get the impedance without any > side effect Looks so. > spec->vmaster_nid = 0x04; > > > > - codec->no_trigger_sense = 1; > > + /* codec->no_trigger_sense = 1; */ > > + codec->trigger_delay = 5; > > codec->no_sticky_stream = 1; > > > > return 0; > > > > > So no need to change if the objective of snd_hda_jack_detect() is to get > presence detect bit > > As mentioned in 729d55ba972348234759f8e40abf8d > e020f0d505 > > use tigger at pin-sensing seem generate a lot of responses When the unsol events are triggered, more exactly? If these are issued at once, the events can be filtered out by checking some flag or checking some timeout, etc. If an event is still triggered at 100ms after the actual plugging, it's a bit problem... Takashi ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: snd jack report and unsolicited event ad1988 2011-05-09 12:09 ` Takashi Iwai @ 2011-05-18 2:10 ` Raymond Yau 0 siblings, 0 replies; 5+ messages in thread From: Raymond Yau @ 2011-05-18 2:10 UTC (permalink / raw) To: Takashi Iwai, ALSA Development Mailing List 2011/5/9 Takashi Iwai <tiwai@suse.de>: > At Mon, 9 May 2011 11:56:11 +0800, > Raymond Yau wrote: >> >> 2011/5/5 Takashi Iwai <tiwai@suse.de> >> >> >> This mean that the driver need to define FRONT_MIC_EVENT, REAR_MIC_EVENT, >> >> LINE_IN_EVENT in addition to HP_EVENT >> >> >Does it mean that the codec can't accept the same id tag for multiple >> >pins? >> >> No, the event can be received by the event handler but there is no way to >> know the event is related to which jack > > Yeah, sure, if you want to distinguish each pin, you have to assign > different ids. But it's independent from my question. > > Your statement sounded as if the multiple pins aren't allowed to have > the same tag on AD codec. But, it seems that it's OK, judging from > your follow up. > If you assign the same tag, you have to perform snd_jack_detect() on multiple pin complex and the driver won't know exactly which jack is plugged in/out unless it store the previous state of 8 jacks > >> >> Can snd_jack_report used to report the mic event of two pink jacks >> (front >> >> panel and rear panel) of the desktop to the user space program? >> >> > I assumed so, but someone needs to confirm. >> > Assigning different tags is easy and safe, so even if it worked, we >> > can go forward for individual tags. >> >> So the point is whether the user space program need to know >> >> 1) the event is related to the plug in or out of the front mic jack / rear >> mic jack >> 2) whether earphone or speaker is plugged into correct/wrong jacks by >> measured impedance . > > In some time future, yes, a program like PulseAudio would like to know > and behave reactively to the plug state. But, in that case, the whole > driver design should be changed -- the kernel driver should do as > little as possible regarding the jack task switching. > Do snd_jack_report allow the driver to add two jacks input for front mic and rear mic ? >> >> So, adding some delay like below makes it working? >> > >> >> if (!codec->no_trigger_sense) { >> > pincap = snd_hda_query_pin_caps(codec, nid); >> > - if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */ >> > + if (pincap & AC_PINCAP_TRIG_REQ) { /* need trigger? */ >> > snd_hda_codec_read(codec, nid, 0, >> > AC_VERB_SET_PIN_SENSE, 0); >> > + if (codec->trigger_delay > 0) >> > + mdelay(codec->trigger_delay); >> > + } >> > } >> > return snd_hda_codec_read(codec, nid, 0, >> > AC_VERB_GET_PIN_SENSE, 0); >> > >> >> Noise appear when delay is add at here > > In which situation? From unplugged to plugged? > >> Have to wait until someone find a safe way to get the impedance without any >> side effect > > Looks so. The noise appear until system shutdown > >> spec->vmaster_nid = 0x04; >> > >> > - codec->no_trigger_sense = 1; >> > + /* codec->no_trigger_sense = 1; */ >> > + codec->trigger_delay = 5; >> > codec->no_sticky_stream = 1; >> > >> > return 0; >> > >> >> >> So no need to change if the objective of snd_hda_jack_detect() is to get >> presence detect bit >> >> As mentioned in 729d55ba972348234759f8e40abf8d >> e020f0d505 >> >> use tigger at pin-sensing seem generate a lot of responses > > When the unsol events are triggered, more exactly? > If these are issued at once, the events can be filtered out by > checking some flag or checking some timeout, etc. If an event is > still triggered at 100ms after the actual plugging, it's a bit > problem... > my unsol event handler just perform jack detect according to the tag and print the result to system log only and still don't have any mute/unmute statement It seem that the following command also trigger a repsonse to unsol_event handler ./hda-verb /dev/snd/hwC1D0 0x12 SET_PIN_SENSE 0 nid = 0x12, verb = 0x709, param = 0x0 value = 0x0 dmesg unsol event res 48000000 tag 12 pincap 1014010 : 12 no jack detected Color = Green Line Out at Ext Rear ./hda-verb /dev/snd/hwC1D0 0x16 SET_PIN_SENSE 0 nid = 0x16, verb = 0x709, param = 0x0 value = 0x0 dmesg unsol event res 58000000 tag 16 pincap 1011012 : 16 sense 1e Color = Black Line Out at Ext Rear ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-05-18 2:10 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-05-05 7:05 snd jack report and unsolicited event ad1988 Raymond Yau 2011-05-05 9:50 ` Takashi Iwai 2011-05-09 3:56 ` Raymond Yau 2011-05-09 12:09 ` Takashi Iwai 2011-05-18 2:10 ` Raymond Yau
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).