| Message ID | 6FAB7C47BCF00940BB0999A99BE3547A18420E8B@RTITMBSV02.realtek.com.tw (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | hp_pin was NULL value | expand |
On Wed, 09 Jan 2019 10:31:33 +0100, Kailang wrote: > > Hi Takashi, > > Could I move the alc294_hp_init(codec) to below line. > Because hp_pin = spec->gen.autocfg.hp_pins[0] was null value when alc294_hp_init(codec) at original line. > Or move alc269_parse_auto_config() upward. It looks OK to me. But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. thanks, Takashi
>>But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. Yes, it only call at probing. Just need to call it at boot time. -----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: Wednesday, January 9, 2019 5:43 PM To: Kailang <kailang@realtek.com> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: Re: hp_pin was NULL value On Wed, 09 Jan 2019 10:31:33 +0100, Kailang wrote: > > Hi Takashi, > > Could I move the alc294_hp_init(codec) to below line. > Because hp_pin = spec->gen.autocfg.hp_pins[0] was null value when alc294_hp_init(codec) at original line. > Or move alc269_parse_auto_config() upward. It looks OK to me. But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. thanks, Takashi ------Please consider the environment before printing this e-mail.
On Wed, 09 Jan 2019 10:45:25 +0100, Kailang wrote: > > >>But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. > Yes, it only call at probing. Just need to call it at boot time. > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Wednesday, January 9, 2019 5:43 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Wed, 09 Jan 2019 10:31:33 +0100, > Kailang wrote: > > > > Hi Takashi, > > > > Could I move the alc294_hp_init(codec) to below line. > > Because hp_pin = spec->gen.autocfg.hp_pins[0] was null value when alc294_hp_init(codec) at original line. > > Or move alc269_parse_auto_config() upward. > > It looks OK to me. But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. Hrm, but it modifies many COEFs, and are these all preserved with suspend? For example, there is also hibernation (S4), which is a switch from the boot without the audio driver initialization. Then we'll resume from the uninitialized state. I guess other COEF changes in that area should be moved as the additional init hook as well. Actually, if we do call this at resume, the change would be easier, a patch like below. thanks, Takashi --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7404,6 +7404,20 @@ static void alc294_hp_init(struct hda_codec *codec) msleep(50); } +static void alc294_init(struct hda_codec *codec) +{ + /* UAJ MIC Vref control by verb */ + alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); + alc294_hp_init(codec); +} + +static void alc700_init(struct hda_codec *codec) +{ + /* Combo jack auto trigger control */ + alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); + alc294_hp_init(codec); +} + /* */ static int patch_alc269(struct hda_codec *codec) @@ -7528,8 +7542,7 @@ static int patch_alc269(struct hda_codec *codec) case 0x10ec0294: spec->codec_variant = ALC269_TYPE_ALC294; spec->gen.mixer_nid = 0; /* ALC2x4 does not have any loopback mixer path */ - alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); /* UAJ MIC Vref control by verb */ - alc294_hp_init(codec); + spec->init_hook = alc294_init; break; case 0x10ec0300: spec->codec_variant = ALC269_TYPE_ALC300; @@ -7540,8 +7553,7 @@ static int patch_alc269(struct hda_codec *codec) case 0x10ec0703: spec->codec_variant = ALC269_TYPE_ALC700; spec->gen.mixer_nid = 0; /* ALC700 does not have any loopback mixer path */ - alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); /* Combo jack auto trigger control */ - alc294_hp_init(codec); + spec->init_hook = alc700_init; break; }
On Wed, 09 Jan 2019 12:19:14 +0100, Kailang wrote: > > Hi Takashi, > > But spec->init_hook will call at resume back. > alc294_hp_init() function just need to call at one time. As already mentioned, even if it has to be called only once and does something for the hardware, it'll be missing if the machine goes hibernate (S4) and resume. In S4, the machine boots from scratch and switches immediately to the saved image that calls resume callback. What's worse for us is that this switch happens usually in initrd, i.e. before the sound driver gets loaded. So, the machine goes to resume without processing alc294_hp_init(). IOW, even if it's needed only once, you'll have to call it at resume unless it has a significant drawback. (Strictly speaking, we may use thaw PM callback, but the HD-audio codec driver doesn't use it, so there is only resume callback for now.) > And it need to call it before call spec->init_hook. But ALC294 (and ALC700) have no init_hook, so far? > ALC225 also need to call similar procedure. I will post it later. OK, thanks. Takashi > > BR, > Kailang > ________________________________________ > 從: Takashi Iwai [tiwai@suse.de] > 寄件日期: 2019年1月9日 下午 05:56 > 至: Kailang > 副本: (alsa-devel@alsa-project.org) > 主旨: Re: hp_pin was NULL value > > On Wed, 09 Jan 2019 10:45:25 +0100, > Kailang wrote: > > > > >>But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. > > Yes, it only call at probing. Just need to call it at boot time. > > > > -----Original Message----- > > From: Takashi Iwai <tiwai@suse.de> > > Sent: Wednesday, January 9, 2019 5:43 PM > > To: Kailang <kailang@realtek.com> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: Re: hp_pin was NULL value > > > > On Wed, 09 Jan 2019 10:31:33 +0100, > > Kailang wrote: > > > > > > Hi Takashi, > > > > > > Could I move the alc294_hp_init(codec) to below line. > > > Because hp_pin = spec->gen.autocfg.hp_pins[0] was null value when alc294_hp_init(codec) at original line. > > > Or move alc269_parse_auto_config() upward. > > > > It looks OK to me. But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. > > Hrm, but it modifies many COEFs, and are these all preserved with > suspend? For example, there is also hibernation (S4), which is a > switch from the boot without the audio driver initialization. Then > we'll resume from the uninitialized state. I guess other COEF changes > in that area should be moved as the additional init hook as well. > > Actually, if we do call this at resume, the change would be easier, a > patch like below. > > > thanks, > > Takashi > > --- a/sound/pci/hda/patch_realtek.c > +++ b/sound/pci/hda/patch_realtek.c > @@ -7404,6 +7404,20 @@ static void alc294_hp_init(struct hda_codec *codec) > msleep(50); > } > > +static void alc294_init(struct hda_codec *codec) > +{ > + /* UAJ MIC Vref control by verb */ > + alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); > + alc294_hp_init(codec); > +} > + > +static void alc700_init(struct hda_codec *codec) > +{ > + /* Combo jack auto trigger control */ > + alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); > + alc294_hp_init(codec); > +} > + > /* > */ > static int patch_alc269(struct hda_codec *codec) > @@ -7528,8 +7542,7 @@ static int patch_alc269(struct hda_codec *codec) > case 0x10ec0294: > spec->codec_variant = ALC269_TYPE_ALC294; > spec->gen.mixer_nid = 0; /* ALC2x4 does not have any loopback mixer path */ > - alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); /* UAJ MIC Vref control by verb */ > - alc294_hp_init(codec); > + spec->init_hook = alc294_init; > break; > case 0x10ec0300: > spec->codec_variant = ALC269_TYPE_ALC300; > @@ -7540,8 +7553,7 @@ static int patch_alc269(struct hda_codec *codec) > case 0x10ec0703: > spec->codec_variant = ALC269_TYPE_ALC700; > spec->gen.mixer_nid = 0; /* ALC700 does not have any loopback mixer path */ > - alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); /* Combo jack auto trigger control */ > - alc294_hp_init(codec); > + spec->init_hook = alc700_init; > break; > > } > > > ------Please consider the environment before printing this e-mail.
On Wed, 09 Jan 2019 13:32:51 +0100, Kailang wrote: > > > Hi Takashi, > > > OK! I will test it. > So, if ALC225 need to do this. I will assigned it to alc225_init(). Right? > > >>But ALC294 (and ALC700) have no init_hook, so far? > > spec->init_hook = alc_default_init; > It has default init_hook. I use this to do standard headphone depop function. Ah, OK. Then we need a call chain from alc294_init(), static void alc294_init() { coef(); alc294_hp_init(); alc_default_init(); } thanks, Takashi > > BR, > Kailang > ________________________________________ > 從: Takashi Iwai [tiwai@suse.de] > 寄件日期: 2019年1月9日 下午 07:29 > 至: Kailang > 副本: (alsa-devel@alsa-project.org) > 主旨: Re: hp_pin was NULL value > > On Wed, 09 Jan 2019 12:19:14 +0100, > Kailang wrote: > > > > Hi Takashi, > > > > But spec->init_hook will call at resume back. > > alc294_hp_init() function just need to call at one time. > > As already mentioned, even if it has to be called only once and does > something for the hardware, it'll be missing if the machine goes > hibernate (S4) and resume. In S4, the machine boots from scratch and > switches immediately to the saved image that calls resume callback. > What's worse for us is that this switch happens usually in initrd, > i.e. before the sound driver gets loaded. So, the machine goes to > resume without processing alc294_hp_init(). > > IOW, even if it's needed only once, you'll have to call it at resume > unless it has a significant drawback. > > (Strictly speaking, we may use thaw PM callback, but the HD-audio > codec driver doesn't use it, so there is only resume callback for > now.) > > > And it need to call it before call spec->init_hook. > > But ALC294 (and ALC700) have no init_hook, so far? > > > ALC225 also need to call similar procedure. I will post it later. > > OK, thanks. > > > Takashi > > > > > BR, > > Kailang > > ________________________________________ > > 從: Takashi Iwai [tiwai@suse.de] > > 寄件日期: 2019年1月9日 下午 05:56 > > 至: Kailang > > 副本: (alsa-devel@alsa-project.org) > > 主旨: Re: hp_pin was NULL value > > > > On Wed, 09 Jan 2019 10:45:25 +0100, > > Kailang wrote: > > > > > > >>But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. > > > Yes, it only call at probing. Just need to call it at boot time. > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai@suse.de> > > > Sent: Wednesday, January 9, 2019 5:43 PM > > > To: Kailang <kailang@realtek.com> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: Re: hp_pin was NULL value > > > > > > On Wed, 09 Jan 2019 10:31:33 +0100, > > > Kailang wrote: > > > > > > > > Hi Takashi, > > > > > > > > Could I move the alc294_hp_init(codec) to below line. > > > > Because hp_pin = spec->gen.autocfg.hp_pins[0] was null value when alc294_hp_init(codec) at original line. > > > > Or move alc269_parse_auto_config() upward. > > > > > > It looks OK to me. But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. > > > > Hrm, but it modifies many COEFs, and are these all preserved with > > suspend? For example, there is also hibernation (S4), which is a > > switch from the boot without the audio driver initialization. Then > > we'll resume from the uninitialized state. I guess other COEF changes > > in that area should be moved as the additional init hook as well. > > > > Actually, if we do call this at resume, the change would be easier, a > > patch like below. > > > > > > thanks, > > > > Takashi > > > > --- a/sound/pci/hda/patch_realtek.c > > +++ b/sound/pci/hda/patch_realtek.c > > @@ -7404,6 +7404,20 @@ static void alc294_hp_init(struct hda_codec *codec) > > msleep(50); > > } > > > > +static void alc294_init(struct hda_codec *codec) > > +{ > > + /* UAJ MIC Vref control by verb */ > > + alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); > > + alc294_hp_init(codec); > > +} > > + > > +static void alc700_init(struct hda_codec *codec) > > +{ > > + /* Combo jack auto trigger control */ > > + alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); > > + alc294_hp_init(codec); > > +} > > + > > /* > > */ > > static int patch_alc269(struct hda_codec *codec) > > @@ -7528,8 +7542,7 @@ static int patch_alc269(struct hda_codec *codec) > > case 0x10ec0294: > > spec->codec_variant = ALC269_TYPE_ALC294; > > spec->gen.mixer_nid = 0; /* ALC2x4 does not have any loopback mixer path */ > > - alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); /* UAJ MIC Vref control by verb */ > > - alc294_hp_init(codec); > > + spec->init_hook = alc294_init; > > break; > > case 0x10ec0300: > > spec->codec_variant = ALC269_TYPE_ALC300; > > @@ -7540,8 +7553,7 @@ static int patch_alc269(struct hda_codec *codec) > > case 0x10ec0703: > > spec->codec_variant = ALC269_TYPE_ALC700; > > spec->gen.mixer_nid = 0; /* ALC700 does not have any loopback mixer path */ > > - alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); /* Combo jack auto trigger control */ > > - alc294_hp_init(codec); > > + spec->init_hook = alc700_init; > > break; > > > > } > > > > > > ------Please consider the environment before printing this e-mail.
Hi Takashi, I simulate test your prefer function. I put alc225_hp_init() in alc225_init(). If system boot ready, I write 1 to power_save of /sys/module/.... The print message as below. It called two times until boot ready. If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). [ 21.497524] alc225_init hp_pin=0x21 [ 21.497526] alc225_hp_init-s hp=0x21 [ 22.140076] alc225_hp_init-e hp=0x21 [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. [ 22.186846] alc225_shutup hp_pin=0x21 [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 [ 22.205104] alc225_init hp_pin=0x21 [ 22.205108] alc225_hp_init-s hp=0x21 [ 22.852123] alc225_hp_init-e hp=0x21 [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. ############ Boot ready ############## [ 116.832084] alc225_shutup hp_pin=0x21 ==> echo 1 to power_save [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] alc225_hp_init-e hp=0x21 Many thanks. BR, Kailang -----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: Wednesday, January 9, 2019 9:01 PM To: Kailang <kailang@realtek.com> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: Re: hp_pin was NULL value On Wed, 09 Jan 2019 13:32:51 +0100, Kailang wrote: > > > Hi Takashi, > > > OK! I will test it. > So, if ALC225 need to do this. I will assigned it to alc225_init(). Right? > > >>But ALC294 (and ALC700) have no init_hook, so far? > > spec->init_hook = alc_default_init; > It has default init_hook. I use this to do standard headphone depop function. Ah, OK. Then we need a call chain from alc294_init(), static void alc294_init() { coef(); alc294_hp_init(); alc_default_init(); } thanks, Takashi > > BR, > Kailang > ________________________________________ > 從: Takashi Iwai [tiwai@suse.de] > 寄件日期: 2019年1月9日 下午 07:29 > 至: Kailang > 副本: (alsa-devel@alsa-project.org) > 主旨: Re: hp_pin was NULL value > > On Wed, 09 Jan 2019 12:19:14 +0100, > Kailang wrote: > > > > Hi Takashi, > > > > But spec->init_hook will call at resume back. > > alc294_hp_init() function just need to call at one time. > > As already mentioned, even if it has to be called only once and does > something for the hardware, it'll be missing if the machine goes > hibernate (S4) and resume. In S4, the machine boots from scratch and > switches immediately to the saved image that calls resume callback. > What's worse for us is that this switch happens usually in initrd, > i.e. before the sound driver gets loaded. So, the machine goes to > resume without processing alc294_hp_init(). > > IOW, even if it's needed only once, you'll have to call it at resume > unless it has a significant drawback. > > (Strictly speaking, we may use thaw PM callback, but the HD-audio > codec driver doesn't use it, so there is only resume callback for > now.) > > > And it need to call it before call spec->init_hook. > > But ALC294 (and ALC700) have no init_hook, so far? > > > ALC225 also need to call similar procedure. I will post it later. > > OK, thanks. > > > Takashi > > > > > BR, > > Kailang > > ________________________________________ > > 從: Takashi Iwai [tiwai@suse.de] > > 寄件日期: 2019年1月9日 下午 05:56 > > 至: Kailang > > 副本: (alsa-devel@alsa-project.org) > > 主旨: Re: hp_pin was NULL value > > > > On Wed, 09 Jan 2019 10:45:25 +0100, > > Kailang wrote: > > > > > > >>But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. > > > Yes, it only call at probing. Just need to call it at boot time. > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai@suse.de> > > > Sent: Wednesday, January 9, 2019 5:43 PM > > > To: Kailang <kailang@realtek.com> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: Re: hp_pin was NULL value > > > > > > On Wed, 09 Jan 2019 10:31:33 +0100, Kailang wrote: > > > > > > > > Hi Takashi, > > > > > > > > Could I move the alc294_hp_init(codec) to below line. > > > > Because hp_pin = spec->gen.autocfg.hp_pins[0] was null value when alc294_hp_init(codec) at original line. > > > > Or move alc269_parse_auto_config() upward. > > > > > > It looks OK to me. But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. > > > > Hrm, but it modifies many COEFs, and are these all preserved with > > suspend? For example, there is also hibernation (S4), which is a > > switch from the boot without the audio driver initialization. Then > > we'll resume from the uninitialized state. I guess other COEF > > changes in that area should be moved as the additional init hook as well. > > > > Actually, if we do call this at resume, the change would be easier, > > a patch like below. > > > > > > thanks, > > > > Takashi > > > > --- a/sound/pci/hda/patch_realtek.c > > +++ b/sound/pci/hda/patch_realtek.c > > @@ -7404,6 +7404,20 @@ static void alc294_hp_init(struct hda_codec *codec) > > msleep(50); > > } > > > > +static void alc294_init(struct hda_codec *codec) { > > + /* UAJ MIC Vref control by verb */ > > + alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); > > + alc294_hp_init(codec); > > +} > > + > > +static void alc700_init(struct hda_codec *codec) { > > + /* Combo jack auto trigger control */ > > + alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); > > + alc294_hp_init(codec); > > +} > > + > > /* > > */ > > static int patch_alc269(struct hda_codec *codec) @@ -7528,8 +7542,7 > > @@ static int patch_alc269(struct hda_codec *codec) > > case 0x10ec0294: > > spec->codec_variant = ALC269_TYPE_ALC294; > > spec->gen.mixer_nid = 0; /* ALC2x4 does not have any loopback mixer path */ > > - alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); /* UAJ MIC Vref control by verb */ > > - alc294_hp_init(codec); > > + spec->init_hook = alc294_init; > > break; > > case 0x10ec0300: > > spec->codec_variant = ALC269_TYPE_ALC300; @@ -7540,8 > > +7553,7 @@ static int patch_alc269(struct hda_codec *codec) > > case 0x10ec0703: > > spec->codec_variant = ALC269_TYPE_ALC700; > > spec->gen.mixer_nid = 0; /* ALC700 does not have any loopback mixer path */ > > - alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); /* Combo jack auto trigger control */ > > - alc294_hp_init(codec); > > + spec->init_hook = alc700_init; > > break; > > > > } > > > > > > ------Please consider the environment before printing this e-mail.
Hi Takashi, Could you receive this email? BR, Kailang -----Original Message----- From: Kailang Sent: Thursday, January 10, 2019 11:14 AM To: 'Takashi Iwai' <tiwai@suse.de> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: RE: hp_pin was NULL value Hi Takashi, I simulate test your prefer function. I put alc225_hp_init() in alc225_init(). If system boot ready, I write 1 to power_save of /sys/module/.... The print message as below. It called two times until boot ready. If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). [ 21.497524] alc225_init hp_pin=0x21 [ 21.497526] alc225_hp_init-s hp=0x21 [ 22.140076] alc225_hp_init-e hp=0x21 [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. [ 22.186846] alc225_shutup hp_pin=0x21 [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 [ 22.205104] alc225_init hp_pin=0x21 [ 22.205108] alc225_hp_init-s hp=0x21 [ 22.852123] alc225_hp_init-e hp=0x21 [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. ############ Boot ready ############## [ 116.832084] alc225_shutup hp_pin=0x21 ==> echo 1 to power_save [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] alc225_hp_init-e hp=0x21 Many thanks. BR, Kailang -----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: Wednesday, January 9, 2019 9:01 PM To: Kailang <kailang@realtek.com> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: Re: hp_pin was NULL value On Wed, 09 Jan 2019 13:32:51 +0100, Kailang wrote: > > > Hi Takashi, > > > OK! I will test it. > So, if ALC225 need to do this. I will assigned it to alc225_init(). Right? > > >>But ALC294 (and ALC700) have no init_hook, so far? > > spec->init_hook = alc_default_init; > It has default init_hook. I use this to do standard headphone depop function. Ah, OK. Then we need a call chain from alc294_init(), static void alc294_init() { coef(); alc294_hp_init(); alc_default_init(); } thanks, Takashi > > BR, > Kailang > ________________________________________ > 從: Takashi Iwai [tiwai@suse.de] > 寄件日期: 2019年1月9日 下午 07:29 > 至: Kailang > 副本: (alsa-devel@alsa-project.org) > 主旨: Re: hp_pin was NULL value > > On Wed, 09 Jan 2019 12:19:14 +0100, > Kailang wrote: > > > > Hi Takashi, > > > > But spec->init_hook will call at resume back. > > alc294_hp_init() function just need to call at one time. > > As already mentioned, even if it has to be called only once and does > something for the hardware, it'll be missing if the machine goes > hibernate (S4) and resume. In S4, the machine boots from scratch and > switches immediately to the saved image that calls resume callback. > What's worse for us is that this switch happens usually in initrd, > i.e. before the sound driver gets loaded. So, the machine goes to > resume without processing alc294_hp_init(). > > IOW, even if it's needed only once, you'll have to call it at resume > unless it has a significant drawback. > > (Strictly speaking, we may use thaw PM callback, but the HD-audio > codec driver doesn't use it, so there is only resume callback for > now.) > > > And it need to call it before call spec->init_hook. > > But ALC294 (and ALC700) have no init_hook, so far? > > > ALC225 also need to call similar procedure. I will post it later. > > OK, thanks. > > > Takashi > > > > > BR, > > Kailang > > ________________________________________ > > 從: Takashi Iwai [tiwai@suse.de] > > 寄件日期: 2019年1月9日 下午 05:56 > > 至: Kailang > > 副本: (alsa-devel@alsa-project.org) > > 主旨: Re: hp_pin was NULL value > > > > On Wed, 09 Jan 2019 10:45:25 +0100, > > Kailang wrote: > > > > > > >>But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. > > > Yes, it only call at probing. Just need to call it at boot time. > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai@suse.de> > > > Sent: Wednesday, January 9, 2019 5:43 PM > > > To: Kailang <kailang@realtek.com> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: Re: hp_pin was NULL value > > > > > > On Wed, 09 Jan 2019 10:31:33 +0100, Kailang wrote: > > > > > > > > Hi Takashi, > > > > > > > > Could I move the alc294_hp_init(codec) to below line. > > > > Because hp_pin = spec->gen.autocfg.hp_pins[0] was null value when alc294_hp_init(codec) at original line. > > > > Or move alc269_parse_auto_config() upward. > > > > > > It looks OK to me. But this made me wonder whether we don't need to call this function at resume as well? Currently it's called only at probing. > > > > Hrm, but it modifies many COEFs, and are these all preserved with > > suspend? For example, there is also hibernation (S4), which is a > > switch from the boot without the audio driver initialization. Then > > we'll resume from the uninitialized state. I guess other COEF > > changes in that area should be moved as the additional init hook as well. > > > > Actually, if we do call this at resume, the change would be easier, > > a patch like below. > > > > > > thanks, > > > > Takashi > > > > --- a/sound/pci/hda/patch_realtek.c > > +++ b/sound/pci/hda/patch_realtek.c > > @@ -7404,6 +7404,20 @@ static void alc294_hp_init(struct hda_codec *codec) > > msleep(50); > > } > > > > +static void alc294_init(struct hda_codec *codec) { > > + /* UAJ MIC Vref control by verb */ > > + alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); > > + alc294_hp_init(codec); > > +} > > + > > +static void alc700_init(struct hda_codec *codec) { > > + /* Combo jack auto trigger control */ > > + alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); > > + alc294_hp_init(codec); > > +} > > + > > /* > > */ > > static int patch_alc269(struct hda_codec *codec) @@ -7528,8 +7542,7 > > @@ static int patch_alc269(struct hda_codec *codec) > > case 0x10ec0294: > > spec->codec_variant = ALC269_TYPE_ALC294; > > spec->gen.mixer_nid = 0; /* ALC2x4 does not have any loopback mixer path */ > > - alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); /* UAJ MIC Vref control by verb */ > > - alc294_hp_init(codec); > > + spec->init_hook = alc294_init; > > break; > > case 0x10ec0300: > > spec->codec_variant = ALC269_TYPE_ALC300; @@ -7540,8 > > +7553,7 @@ static int patch_alc269(struct hda_codec *codec) > > case 0x10ec0703: > > spec->codec_variant = ALC269_TYPE_ALC700; > > spec->gen.mixer_nid = 0; /* ALC700 does not have any loopback mixer path */ > > - alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); /* Combo jack auto trigger control */ > > - alc294_hp_init(codec); > > + spec->init_hook = alc700_init; > > break; > > > > } > > > > > > ------Please consider the environment before printing this e-mail.
On Tue, 15 Jan 2019 03:31:33 +0100, Kailang wrote: > > Hi Takashi, > > Could you receive this email? > > BR, > Kailang > > -----Original Message----- > From: Kailang > Sent: Thursday, January 10, 2019 11:14 AM > To: 'Takashi Iwai' <tiwai@suse.de> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: RE: hp_pin was NULL value > > Hi Takashi, > > I simulate test your prefer function. > I put alc225_hp_init() in alc225_init(). > If system boot ready, I write 1 to power_save of /sys/module/.... > The print message as below. It called two times until boot ready. > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > [ 21.497524] alc225_init hp_pin=0x21 > [ 21.497526] alc225_hp_init-s hp=0x21 > [ 22.140076] alc225_hp_init-e hp=0x21 > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > [ 22.186846] alc225_shutup hp_pin=0x21 > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > [ 22.205104] alc225_init hp_pin=0x21 > [ 22.205108] alc225_hp_init-s hp=0x21 > [ 22.852123] alc225_hp_init-e hp=0x21 > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > ############ Boot ready ############## > [ 116.832084] alc225_shutup hp_pin=0x21 ==> echo 1 to power_save > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > [ 120.002586] alc225_hp_init-s hp=0x21 > [ 120.644128] alc225_hp_init-e hp=0x21 It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? thanks, Takashi
No, it not expected. It will enter two times after boot ready. I think it could add a flag in alc225_hp_init(). To make sure it only excute one time. How do you think about? -----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: Tuesday, January 15, 2019 2:37 PM To: Kailang <kailang@realtek.com> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: Re: hp_pin was NULL value On Tue, 15 Jan 2019 03:31:33 +0100, Kailang wrote: > > Hi Takashi, > > Could you receive this email? > > BR, > Kailang > > -----Original Message----- > From: Kailang > Sent: Thursday, January 10, 2019 11:14 AM > To: 'Takashi Iwai' <tiwai@suse.de> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: RE: hp_pin was NULL value > > Hi Takashi, > > I simulate test your prefer function. > I put alc225_hp_init() in alc225_init(). > If system boot ready, I write 1 to power_save of /sys/module/.... > The print message as below. It called two times until boot ready. > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > [ 21.497524] alc225_init hp_pin=0x21 > [ 21.497526] alc225_hp_init-s hp=0x21 > [ 22.140076] alc225_hp_init-e hp=0x21 > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > [ 22.186846] alc225_shutup hp_pin=0x21 > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > [ 22.205104] alc225_init hp_pin=0x21 > [ 22.205108] alc225_hp_init-s hp=0x21 > [ 22.852123] alc225_hp_init-e hp=0x21 > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > ############ Boot ready ############## [ 116.832084] alc225_shutup > hp_pin=0x21 ==> echo 1 to power_save > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > alc225_hp_init-e hp=0x21 It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? thanks, Takashi ------Please consider the environment before printing this e-mail.
On Tue, 15 Jan 2019 08:43:40 +0100, Kailang wrote: > > > No, it not expected. > It will enter two times after boot ready. > I think it could add a flag in alc225_hp_init(). > To make sure it only excute one time. How do you think about? Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume(). And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation. thanks, Takashi > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Tuesday, January 15, 2019 2:37 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Tue, 15 Jan 2019 03:31:33 +0100, > Kailang wrote: > > > > Hi Takashi, > > > > Could you receive this email? > > > > BR, > > Kailang > > > > -----Original Message----- > > From: Kailang > > Sent: Thursday, January 10, 2019 11:14 AM > > To: 'Takashi Iwai' <tiwai@suse.de> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: RE: hp_pin was NULL value > > > > Hi Takashi, > > > > I simulate test your prefer function. > > I put alc225_hp_init() in alc225_init(). > > If system boot ready, I write 1 to power_save of /sys/module/.... > > The print message as below. It called two times until boot ready. > > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > > > [ 21.497524] alc225_init hp_pin=0x21 > > [ 21.497526] alc225_hp_init-s hp=0x21 > > [ 22.140076] alc225_hp_init-e hp=0x21 > > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > [ 22.186846] alc225_shutup hp_pin=0x21 > > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > > [ 22.205104] alc225_init hp_pin=0x21 > > [ 22.205108] alc225_hp_init-s hp=0x21 > > [ 22.852123] alc225_hp_init-e hp=0x21 > > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > ############ Boot ready ############## [ 116.832084] alc225_shutup > > hp_pin=0x21 ==> echo 1 to power_save > > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > > alc225_hp_init-e hp=0x21 > > It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? > > > thanks, > > Takashi > > ------Please consider the environment before printing this e-mail. >
Hi Takashi,
Sorry!! Maybe I don't understand what you mean.
Please see below.
--- patch_realtek.c.orig 2019-01-11 16:28:43.745957854 +0800
+++ patch_realtek.c 2019-01-15 16:09:56.017873567 +0800
@@ -3221,12 +3221,29 @@ static void alc256_shutup(struct hda_cod
snd_hda_shutup_pins(codec);
}
+static void alc225_hp_init(struct hda_codec *codec)
+{
+ struct alc_spec *spec = codec->spec;
+ hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0];
+ int i, val;
+ int coef38, coef0d, coef36;
+ printk("%s-start hp=0x%x\n",__func__,hp_pin);
+ if (!hp_pin)
+ return;
+
+ alc_update_coef_idx(codec, 0x4a, 1<<15, 1<<15);
+ msleep(50);
+ alc_update_coef_idx(codec, 0x4a, 1<<15, 0);
+ printk("%s-end hp=0x%x\n",__func__,hp_pin);
+}
+
static void alc225_init(struct hda_codec *codec)
{
struct alc_spec *spec = codec->spec;
hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0];
bool hp1_pin_sense, hp2_pin_sense;
+ alc225_hp_init(codec);
if (!hp_pin)
return;
@@ -3262,6 +3279,7 @@ static void alc225_init(struct hda_codec
alc_update_coef_idx(codec, 0x4a, 3 << 10, 0);
alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */
+ printk("%s hp=0x%x\n",__func__,hp_pin);
}
-----Original Message-----
From: Takashi Iwai <tiwai@suse.de>
Sent: Tuesday, January 15, 2019 3:54 PM
To: Kailang <kailang@realtek.com>
Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org>
Subject: Re: hp_pin was NULL value
On Tue, 15 Jan 2019 08:43:40 +0100,
Kailang wrote:
>
>
> No, it not expected.
> It will enter two times after boot ready.
> I think it could add a flag in alc225_hp_init().
> To make sure it only excute one time. How do you think about?
Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume().
And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation.
thanks,
Takashi
>
> -----Original Message-----
> From: Takashi Iwai <tiwai@suse.de>
> Sent: Tuesday, January 15, 2019 2:37 PM
> To: Kailang <kailang@realtek.com>
> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org>
> Subject: Re: hp_pin was NULL value
>
> On Tue, 15 Jan 2019 03:31:33 +0100,
> Kailang wrote:
> >
> > Hi Takashi,
> >
> > Could you receive this email?
> >
> > BR,
> > Kailang
> >
> > -----Original Message-----
> > From: Kailang
> > Sent: Thursday, January 10, 2019 11:14 AM
> > To: 'Takashi Iwai' <tiwai@suse.de>
> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org>
> > Subject: RE: hp_pin was NULL value
> >
> > Hi Takashi,
> >
> > I simulate test your prefer function.
> > I put alc225_hp_init() in alc225_init().
> > If system boot ready, I write 1 to power_save of /sys/module/....
> > The print message as below. It called two times until boot ready.
> > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init().
> >
> > [ 21.497524] alc225_init hp_pin=0x21
> > [ 21.497526] alc225_hp_init-s hp=0x21
> > [ 22.140076] alc225_hp_init-e hp=0x21
> > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode.
> > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode.
> > [ 22.186846] alc225_shutup hp_pin=0x21
> > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5
> > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6
> > [ 22.205104] alc225_init hp_pin=0x21
> > [ 22.205108] alc225_hp_init-s hp=0x21
> > [ 22.852123] alc225_hp_init-e hp=0x21
> > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode.
> > ############ Boot ready ############## [ 116.832084] alc225_shutup
> > hp_pin=0x21 ==> echo 1 to power_save
> > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound
> > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128]
> > alc225_hp_init-e hp=0x21
>
> It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no?
>
>
> thanks,
>
> Takashi
>
> ------Please consider the environment before printing this e-mail.
>
On Tue, 15 Jan 2019 09:17:24 +0100, Kailang wrote: > > > Hi Takashi, > > Sorry!! Maybe I don't understand what you mean. > Please see below. > > --- patch_realtek.c.orig 2019-01-11 16:28:43.745957854 +0800 > +++ patch_realtek.c 2019-01-15 16:09:56.017873567 +0800 > @@ -3221,12 +3221,29 @@ static void alc256_shutup(struct hda_cod > snd_hda_shutup_pins(codec); > } > > +static void alc225_hp_init(struct hda_codec *codec) > +{ > + struct alc_spec *spec = codec->spec; > + hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > + int i, val; > + int coef38, coef0d, coef36; > + printk("%s-start hp=0x%x\n",__func__,hp_pin); > + if (!hp_pin) > + return; > + > + alc_update_coef_idx(codec, 0x4a, 1<<15, 1<<15); > + msleep(50); > + alc_update_coef_idx(codec, 0x4a, 1<<15, 0); > + printk("%s-end hp=0x%x\n",__func__,hp_pin); > +} > + > static void alc225_init(struct hda_codec *codec) > { > struct alc_spec *spec = codec->spec; > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > bool hp1_pin_sense, hp2_pin_sense; > > + alc225_hp_init(codec); > if (!hp_pin) > return; > > @@ -3262,6 +3279,7 @@ static void alc225_init(struct hda_codec > > alc_update_coef_idx(codec, 0x4a, 3 << 10, 0); > alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */ > + printk("%s hp=0x%x\n",__func__,hp_pin); > } ... and I don't understand what's your problem. Is it about that alc255_hp_init() gets called at resume in addition to the boot time? If so, this is the intended behavior. thanks, Takashi > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Tuesday, January 15, 2019 3:54 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Tue, 15 Jan 2019 08:43:40 +0100, > Kailang wrote: > > > > > > No, it not expected. > > It will enter two times after boot ready. > > I think it could add a flag in alc225_hp_init(). > > To make sure it only excute one time. How do you think about? > > Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume(). > > And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation. > > > thanks, > > Takashi > > > > > -----Original Message----- > > From: Takashi Iwai <tiwai@suse.de> > > Sent: Tuesday, January 15, 2019 2:37 PM > > To: Kailang <kailang@realtek.com> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: Re: hp_pin was NULL value > > > > On Tue, 15 Jan 2019 03:31:33 +0100, > > Kailang wrote: > > > > > > Hi Takashi, > > > > > > Could you receive this email? > > > > > > BR, > > > Kailang > > > > > > -----Original Message----- > > > From: Kailang > > > Sent: Thursday, January 10, 2019 11:14 AM > > > To: 'Takashi Iwai' <tiwai@suse.de> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: RE: hp_pin was NULL value > > > > > > Hi Takashi, > > > > > > I simulate test your prefer function. > > > I put alc225_hp_init() in alc225_init(). > > > If system boot ready, I write 1 to power_save of /sys/module/.... > > > The print message as below. It called two times until boot ready. > > > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > > > > > [ 21.497524] alc225_init hp_pin=0x21 > > > [ 21.497526] alc225_hp_init-s hp=0x21 > > > [ 22.140076] alc225_hp_init-e hp=0x21 > > > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > [ 22.186846] alc225_shutup hp_pin=0x21 > > > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > > > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > > > [ 22.205104] alc225_init hp_pin=0x21 > > > [ 22.205108] alc225_hp_init-s hp=0x21 > > > [ 22.852123] alc225_hp_init-e hp=0x21 > > > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > ############ Boot ready ############## [ 116.832084] alc225_shutup > > > hp_pin=0x21 ==> echo 1 to power_save > > > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > > > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > > > alc225_hp_init-e hp=0x21 > > > > It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? > > > > > > thanks, > > > > Takashi > > > > ------Please consider the environment before printing this e-mail. > > >
>>>Is it about that alc225_hp_init() gets called at resume in addition to the boot time? alc225_hp_init() ==> it only need to call one time at boot time. This HP initial code doesn't need to call at resume. If system boot, HP initial code just need to call it at boot time. S3 state was not need to call this function. Sorry!! Maybe I describe it confuse you. -----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: Tuesday, January 15, 2019 4:58 PM To: Kailang <kailang@realtek.com> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: Re: hp_pin was NULL value On Tue, 15 Jan 2019 09:17:24 +0100, Kailang wrote: > > > Hi Takashi, > > Sorry!! Maybe I don't understand what you mean. > Please see below. > > --- patch_realtek.c.orig 2019-01-11 16:28:43.745957854 +0800 > +++ patch_realtek.c 2019-01-15 16:09:56.017873567 +0800 > @@ -3221,12 +3221,29 @@ static void alc256_shutup(struct hda_cod > snd_hda_shutup_pins(codec); > } > > +static void alc225_hp_init(struct hda_codec *codec) { > + struct alc_spec *spec = codec->spec; > + hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > + int i, val; > + int coef38, coef0d, coef36; > + printk("%s-start hp=0x%x\n",__func__,hp_pin); > + if (!hp_pin) > + return; > + > + alc_update_coef_idx(codec, 0x4a, 1<<15, 1<<15); > + msleep(50); > + alc_update_coef_idx(codec, 0x4a, 1<<15, 0); > + printk("%s-end hp=0x%x\n",__func__,hp_pin); } > + > static void alc225_init(struct hda_codec *codec) { > struct alc_spec *spec = codec->spec; > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > bool hp1_pin_sense, hp2_pin_sense; > > + alc225_hp_init(codec); > if (!hp_pin) > return; > > @@ -3262,6 +3279,7 @@ static void alc225_init(struct hda_codec > > alc_update_coef_idx(codec, 0x4a, 3 << 10, 0); > alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight > power */ > + printk("%s hp=0x%x\n",__func__,hp_pin); > } ... and I don't understand what's your problem. Is it about that alc255_hp_init() gets called at resume in addition to the boot time? If so, this is the intended behavior. thanks, Takashi > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Tuesday, January 15, 2019 3:54 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Tue, 15 Jan 2019 08:43:40 +0100, > Kailang wrote: > > > > > > No, it not expected. > > It will enter two times after boot ready. > > I think it could add a flag in alc225_hp_init(). > > To make sure it only excute one time. How do you think about? > > Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume(). > > And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation. > > > thanks, > > Takashi > > > > > -----Original Message----- > > From: Takashi Iwai <tiwai@suse.de> > > Sent: Tuesday, January 15, 2019 2:37 PM > > To: Kailang <kailang@realtek.com> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: Re: hp_pin was NULL value > > > > On Tue, 15 Jan 2019 03:31:33 +0100, > > Kailang wrote: > > > > > > Hi Takashi, > > > > > > Could you receive this email? > > > > > > BR, > > > Kailang > > > > > > -----Original Message----- > > > From: Kailang > > > Sent: Thursday, January 10, 2019 11:14 AM > > > To: 'Takashi Iwai' <tiwai@suse.de> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: RE: hp_pin was NULL value > > > > > > Hi Takashi, > > > > > > I simulate test your prefer function. > > > I put alc225_hp_init() in alc225_init(). > > > If system boot ready, I write 1 to power_save of /sys/module/.... > > > The print message as below. It called two times until boot ready. > > > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > > > > > [ 21.497524] alc225_init hp_pin=0x21 > > > [ 21.497526] alc225_hp_init-s hp=0x21 > > > [ 22.140076] alc225_hp_init-e hp=0x21 > > > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > [ 22.186846] alc225_shutup hp_pin=0x21 > > > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > > > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > > > [ 22.205104] alc225_init hp_pin=0x21 > > > [ 22.205108] alc225_hp_init-s hp=0x21 > > > [ 22.852123] alc225_hp_init-e hp=0x21 > > > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > ############ Boot ready ############## [ 116.832084] > > > alc225_shutup > > > hp_pin=0x21 ==> echo 1 to power_save > > > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > > > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > > > alc225_hp_init-e hp=0x21 > > > > It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? > > > > > > thanks, > > > > Takashi > > > > ------Please consider the environment before printing this e-mail. > > >
On Tue, 15 Jan 2019 10:06:58 +0100, Kailang wrote: > > >>>Is it about that alc225_hp_init() gets called at resume in addition to the boot time? > > alc225_hp_init() ==> it only need to call one time at boot time. > This HP initial code doesn't need to call at resume. > If system boot, HP initial code just need to call it at boot time. > S3 state was not need to call this function. But S4 resume must call this function: that's my point. So the question is whether calling alc225_hp_init() at S3 resume is significantly harmful or not. If not, we can move it there. If it's harmful, we need to distinguish S3 and S4, and introduce either some flag or a new callback, which will be a much more work than simply patching the codec code. thanks, Takashi > Sorry!! Maybe I describe it confuse you. > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Tuesday, January 15, 2019 4:58 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Tue, 15 Jan 2019 09:17:24 +0100, > Kailang wrote: > > > > > > Hi Takashi, > > > > Sorry!! Maybe I don't understand what you mean. > > Please see below. > > > > --- patch_realtek.c.orig 2019-01-11 16:28:43.745957854 +0800 > > +++ patch_realtek.c 2019-01-15 16:09:56.017873567 +0800 > > @@ -3221,12 +3221,29 @@ static void alc256_shutup(struct hda_cod > > snd_hda_shutup_pins(codec); > > } > > > > +static void alc225_hp_init(struct hda_codec *codec) { > > + struct alc_spec *spec = codec->spec; > > + hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > + int i, val; > > + int coef38, coef0d, coef36; > > + printk("%s-start hp=0x%x\n",__func__,hp_pin); > > + if (!hp_pin) > > + return; > > + > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 1<<15); > > + msleep(50); > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 0); > > + printk("%s-end hp=0x%x\n",__func__,hp_pin); } > > + > > static void alc225_init(struct hda_codec *codec) { > > struct alc_spec *spec = codec->spec; > > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > bool hp1_pin_sense, hp2_pin_sense; > > > > + alc225_hp_init(codec); > > if (!hp_pin) > > return; > > > > @@ -3262,6 +3279,7 @@ static void alc225_init(struct hda_codec > > > > alc_update_coef_idx(codec, 0x4a, 3 << 10, 0); > > alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight > > power */ > > + printk("%s hp=0x%x\n",__func__,hp_pin); > > } > > ... and I don't understand what's your problem. > > Is it about that alc255_hp_init() gets called at resume in addition to the boot time? If so, this is the intended behavior. > > > thanks, > > Takashi > > > > > -----Original Message----- > > From: Takashi Iwai <tiwai@suse.de> > > Sent: Tuesday, January 15, 2019 3:54 PM > > To: Kailang <kailang@realtek.com> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: Re: hp_pin was NULL value > > > > On Tue, 15 Jan 2019 08:43:40 +0100, > > Kailang wrote: > > > > > > > > > No, it not expected. > > > It will enter two times after boot ready. > > > I think it could add a flag in alc225_hp_init(). > > > To make sure it only excute one time. How do you think about? > > > > Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume(). > > > > And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation. > > > > > > thanks, > > > > Takashi > > > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai@suse.de> > > > Sent: Tuesday, January 15, 2019 2:37 PM > > > To: Kailang <kailang@realtek.com> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: Re: hp_pin was NULL value > > > > > > On Tue, 15 Jan 2019 03:31:33 +0100, > > > Kailang wrote: > > > > > > > > Hi Takashi, > > > > > > > > Could you receive this email? > > > > > > > > BR, > > > > Kailang > > > > > > > > -----Original Message----- > > > > From: Kailang > > > > Sent: Thursday, January 10, 2019 11:14 AM > > > > To: 'Takashi Iwai' <tiwai@suse.de> > > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > > Subject: RE: hp_pin was NULL value > > > > > > > > Hi Takashi, > > > > > > > > I simulate test your prefer function. > > > > I put alc225_hp_init() in alc225_init(). > > > > If system boot ready, I write 1 to power_save of /sys/module/.... > > > > The print message as below. It called two times until boot ready. > > > > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > > > > > > > [ 21.497524] alc225_init hp_pin=0x21 > > > > [ 21.497526] alc225_hp_init-s hp=0x21 > > > > [ 22.140076] alc225_hp_init-e hp=0x21 > > > > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > [ 22.186846] alc225_shutup hp_pin=0x21 > > > > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > > > > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > > > > [ 22.205104] alc225_init hp_pin=0x21 > > > > [ 22.205108] alc225_hp_init-s hp=0x21 > > > > [ 22.852123] alc225_hp_init-e hp=0x21 > > > > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > ############ Boot ready ############## [ 116.832084] > > > > alc225_shutup > > > > hp_pin=0x21 ==> echo 1 to power_save > > > > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > > > > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > > > > alc225_hp_init-e hp=0x21 > > > > > > It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? > > > > > > > > > thanks, > > > > > > Takashi > > > > > > ------Please consider the environment before printing this e-mail. > > > > > >
Our Windows code just called it at boot time only. SD's programing guide point just need to call one time. So, I don't know it's harmful or not. I will check with our AE and SD. I could also test it with S3 resume state. Many Thanks. Please wait. -----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: Tuesday, January 15, 2019 5:17 PM To: Kailang <kailang@realtek.com> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: Re: hp_pin was NULL value On Tue, 15 Jan 2019 10:06:58 +0100, Kailang wrote: > > >>>Is it about that alc225_hp_init() gets called at resume in addition to the boot time? > > alc225_hp_init() ==> it only need to call one time at boot time. > This HP initial code doesn't need to call at resume. > If system boot, HP initial code just need to call it at boot time. > S3 state was not need to call this function. But S4 resume must call this function: that's my point. So the question is whether calling alc225_hp_init() at S3 resume is significantly harmful or not. If not, we can move it there. If it's harmful, we need to distinguish S3 and S4, and introduce either some flag or a new callback, which will be a much more work than simply patching the codec code. thanks, Takashi > Sorry!! Maybe I describe it confuse you. > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Tuesday, January 15, 2019 4:58 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Tue, 15 Jan 2019 09:17:24 +0100, > Kailang wrote: > > > > > > Hi Takashi, > > > > Sorry!! Maybe I don't understand what you mean. > > Please see below. > > > > --- patch_realtek.c.orig 2019-01-11 16:28:43.745957854 +0800 > > +++ patch_realtek.c 2019-01-15 16:09:56.017873567 +0800 > > @@ -3221,12 +3221,29 @@ static void alc256_shutup(struct hda_cod > > snd_hda_shutup_pins(codec); > > } > > > > +static void alc225_hp_init(struct hda_codec *codec) { > > + struct alc_spec *spec = codec->spec; > > + hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > + int i, val; > > + int coef38, coef0d, coef36; > > + printk("%s-start hp=0x%x\n",__func__,hp_pin); > > + if (!hp_pin) > > + return; > > + > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 1<<15); > > + msleep(50); > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 0); > > + printk("%s-end hp=0x%x\n",__func__,hp_pin); } > > + > > static void alc225_init(struct hda_codec *codec) { > > struct alc_spec *spec = codec->spec; > > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > bool hp1_pin_sense, hp2_pin_sense; > > > > + alc225_hp_init(codec); > > if (!hp_pin) > > return; > > > > @@ -3262,6 +3279,7 @@ static void alc225_init(struct hda_codec > > > > alc_update_coef_idx(codec, 0x4a, 3 << 10, 0); > > alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight > > power */ > > + printk("%s hp=0x%x\n",__func__,hp_pin); > > } > > ... and I don't understand what's your problem. > > Is it about that alc255_hp_init() gets called at resume in addition to the boot time? If so, this is the intended behavior. > > > thanks, > > Takashi > > > > > -----Original Message----- > > From: Takashi Iwai <tiwai@suse.de> > > Sent: Tuesday, January 15, 2019 3:54 PM > > To: Kailang <kailang@realtek.com> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: Re: hp_pin was NULL value > > > > On Tue, 15 Jan 2019 08:43:40 +0100, > > Kailang wrote: > > > > > > > > > No, it not expected. > > > It will enter two times after boot ready. > > > I think it could add a flag in alc225_hp_init(). > > > To make sure it only excute one time. How do you think about? > > > > Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume(). > > > > And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation. > > > > > > thanks, > > > > Takashi > > > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai@suse.de> > > > Sent: Tuesday, January 15, 2019 2:37 PM > > > To: Kailang <kailang@realtek.com> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: Re: hp_pin was NULL value > > > > > > On Tue, 15 Jan 2019 03:31:33 +0100, Kailang wrote: > > > > > > > > Hi Takashi, > > > > > > > > Could you receive this email? > > > > > > > > BR, > > > > Kailang > > > > > > > > -----Original Message----- > > > > From: Kailang > > > > Sent: Thursday, January 10, 2019 11:14 AM > > > > To: 'Takashi Iwai' <tiwai@suse.de> > > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > > Subject: RE: hp_pin was NULL value > > > > > > > > Hi Takashi, > > > > > > > > I simulate test your prefer function. > > > > I put alc225_hp_init() in alc225_init(). > > > > If system boot ready, I write 1 to power_save of /sys/module/.... > > > > The print message as below. It called two times until boot ready. > > > > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > > > > > > > [ 21.497524] alc225_init hp_pin=0x21 > > > > [ 21.497526] alc225_hp_init-s hp=0x21 > > > > [ 22.140076] alc225_hp_init-e hp=0x21 > > > > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > [ 22.186846] alc225_shutup hp_pin=0x21 > > > > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > > > > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > > > > [ 22.205104] alc225_init hp_pin=0x21 > > > > [ 22.205108] alc225_hp_init-s hp=0x21 > > > > [ 22.852123] alc225_hp_init-e hp=0x21 > > > > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > ############ Boot ready ############## [ 116.832084] > > > > alc225_shutup > > > > hp_pin=0x21 ==> echo 1 to power_save > > > > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > > > > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > > > > alc225_hp_init-e hp=0x21 > > > > > > It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? > > > > > > > > > thanks, > > > > > > Takashi > > > > > > ------Please consider the environment before printing this e-mail. > > > > > >
Hi Takashi, I ask our AE for this function. We also prefer to run it only one time on boot time. S3 resume back not need to run this function. Because it will take about 650ms times to initial. Attach was the new patch. Reject commit or use attach patch to commit. Which is better? BR, Kailang -----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: Tuesday, January 15, 2019 5:17 PM To: Kailang <kailang@realtek.com> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: Re: hp_pin was NULL value On Tue, 15 Jan 2019 10:06:58 +0100, Kailang wrote: > > >>>Is it about that alc225_hp_init() gets called at resume in addition to the boot time? > > alc225_hp_init() ==> it only need to call one time at boot time. > This HP initial code doesn't need to call at resume. > If system boot, HP initial code just need to call it at boot time. > S3 state was not need to call this function. But S4 resume must call this function: that's my point. So the question is whether calling alc225_hp_init() at S3 resume is significantly harmful or not. If not, we can move it there. If it's harmful, we need to distinguish S3 and S4, and introduce either some flag or a new callback, which will be a much more work than simply patching the codec code. thanks, Takashi > Sorry!! Maybe I describe it confuse you. > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Tuesday, January 15, 2019 4:58 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Tue, 15 Jan 2019 09:17:24 +0100, > Kailang wrote: > > > > > > Hi Takashi, > > > > Sorry!! Maybe I don't understand what you mean. > > Please see below. > > > > --- patch_realtek.c.orig 2019-01-11 16:28:43.745957854 +0800 > > +++ patch_realtek.c 2019-01-15 16:09:56.017873567 +0800 > > @@ -3221,12 +3221,29 @@ static void alc256_shutup(struct hda_cod > > snd_hda_shutup_pins(codec); > > } > > > > +static void alc225_hp_init(struct hda_codec *codec) { > > + struct alc_spec *spec = codec->spec; > > + hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > + int i, val; > > + int coef38, coef0d, coef36; > > + printk("%s-start hp=0x%x\n",__func__,hp_pin); > > + if (!hp_pin) > > + return; > > + > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 1<<15); > > + msleep(50); > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 0); > > + printk("%s-end hp=0x%x\n",__func__,hp_pin); } > > + > > static void alc225_init(struct hda_codec *codec) { > > struct alc_spec *spec = codec->spec; > > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > bool hp1_pin_sense, hp2_pin_sense; > > > > + alc225_hp_init(codec); > > if (!hp_pin) > > return; > > > > @@ -3262,6 +3279,7 @@ static void alc225_init(struct hda_codec > > > > alc_update_coef_idx(codec, 0x4a, 3 << 10, 0); > > alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight > > power */ > > + printk("%s hp=0x%x\n",__func__,hp_pin); > > } > > ... and I don't understand what's your problem. > > Is it about that alc255_hp_init() gets called at resume in addition to the boot time? If so, this is the intended behavior. > > > thanks, > > Takashi > > > > > -----Original Message----- > > From: Takashi Iwai <tiwai@suse.de> > > Sent: Tuesday, January 15, 2019 3:54 PM > > To: Kailang <kailang@realtek.com> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: Re: hp_pin was NULL value > > > > On Tue, 15 Jan 2019 08:43:40 +0100, > > Kailang wrote: > > > > > > > > > No, it not expected. > > > It will enter two times after boot ready. > > > I think it could add a flag in alc225_hp_init(). > > > To make sure it only excute one time. How do you think about? > > > > Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume(). > > > > And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation. > > > > > > thanks, > > > > Takashi > > > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai@suse.de> > > > Sent: Tuesday, January 15, 2019 2:37 PM > > > To: Kailang <kailang@realtek.com> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: Re: hp_pin was NULL value > > > > > > On Tue, 15 Jan 2019 03:31:33 +0100, Kailang wrote: > > > > > > > > Hi Takashi, > > > > > > > > Could you receive this email? > > > > > > > > BR, > > > > Kailang > > > > > > > > -----Original Message----- > > > > From: Kailang > > > > Sent: Thursday, January 10, 2019 11:14 AM > > > > To: 'Takashi Iwai' <tiwai@suse.de> > > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > > Subject: RE: hp_pin was NULL value > > > > > > > > Hi Takashi, > > > > > > > > I simulate test your prefer function. > > > > I put alc225_hp_init() in alc225_init(). > > > > If system boot ready, I write 1 to power_save of /sys/module/.... > > > > The print message as below. It called two times until boot ready. > > > > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > > > > > > > [ 21.497524] alc225_init hp_pin=0x21 > > > > [ 21.497526] alc225_hp_init-s hp=0x21 > > > > [ 22.140076] alc225_hp_init-e hp=0x21 > > > > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > [ 22.186846] alc225_shutup hp_pin=0x21 > > > > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > > > > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > > > > [ 22.205104] alc225_init hp_pin=0x21 > > > > [ 22.205108] alc225_hp_init-s hp=0x21 > > > > [ 22.852123] alc225_hp_init-e hp=0x21 > > > > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > ############ Boot ready ############## [ 116.832084] > > > > alc225_shutup > > > > hp_pin=0x21 ==> echo 1 to power_save > > > > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > > > > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > > > > alc225_hp_init-e hp=0x21 > > > > > > It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? > > > > > > > > > thanks, > > > > > > Takashi > > > > > > ------Please consider the environment before printing this e-mail. > > > > > >
On Tue, 29 Jan 2019 09:05:48 +0100, Kailang wrote: > > Hi Takashi, > > I ask our AE for this function. > We also prefer to run it only one time on boot time. S3 resume back not need to run this function. > Because it will take about 650ms times to initial. > > Attach was the new patch. > Reject commit or use attach patch to commit. Which is better? This won't work with S4, unfortunately. The point of S4 problem is that the switch happens from the uninitialized state to the already running system via a single resume callback. That is, the driver was already initialized in the restored image although the chip is still uninitialized on the booted image before the switch. Then switch happens, and since it keeps done_hp_init=1 at S4 resume call, the whole trick won't be applied at all. I'll check whether we have some indicator showing that the call is in thaw/restore, or we'd have to implement a separate thaw/restore callback. thanks, Takashi > > BR, > Kailang > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Tuesday, January 15, 2019 5:17 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Tue, 15 Jan 2019 10:06:58 +0100, > Kailang wrote: > > > > >>>Is it about that alc225_hp_init() gets called at resume in addition to the boot time? > > > > alc225_hp_init() ==> it only need to call one time at boot time. > > This HP initial code doesn't need to call at resume. > > If system boot, HP initial code just need to call it at boot time. > > S3 state was not need to call this function. > > But S4 resume must call this function: that's my point. > > So the question is whether calling alc225_hp_init() at S3 resume is significantly harmful or not. If not, we can move it there. If it's harmful, we need to distinguish S3 and S4, and introduce either some flag or a new callback, which will be a much more work than simply patching the codec code. > > > thanks, > > Takashi > > > Sorry!! Maybe I describe it confuse you. > > > > -----Original Message----- > > From: Takashi Iwai <tiwai@suse.de> > > Sent: Tuesday, January 15, 2019 4:58 PM > > To: Kailang <kailang@realtek.com> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: Re: hp_pin was NULL value > > > > On Tue, 15 Jan 2019 09:17:24 +0100, > > Kailang wrote: > > > > > > > > > Hi Takashi, > > > > > > Sorry!! Maybe I don't understand what you mean. > > > Please see below. > > > > > > --- patch_realtek.c.orig 2019-01-11 16:28:43.745957854 +0800 > > > +++ patch_realtek.c 2019-01-15 16:09:56.017873567 +0800 > > > @@ -3221,12 +3221,29 @@ static void alc256_shutup(struct hda_cod > > > snd_hda_shutup_pins(codec); > > > } > > > > > > +static void alc225_hp_init(struct hda_codec *codec) { > > > + struct alc_spec *spec = codec->spec; > > > + hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > > + int i, val; > > > + int coef38, coef0d, coef36; > > > + printk("%s-start hp=0x%x\n",__func__,hp_pin); > > > + if (!hp_pin) > > > + return; > > > + > > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 1<<15); > > > + msleep(50); > > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 0); > > > + printk("%s-end hp=0x%x\n",__func__,hp_pin); } > > > + > > > static void alc225_init(struct hda_codec *codec) { > > > struct alc_spec *spec = codec->spec; > > > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > > bool hp1_pin_sense, hp2_pin_sense; > > > > > > + alc225_hp_init(codec); > > > if (!hp_pin) > > > return; > > > > > > @@ -3262,6 +3279,7 @@ static void alc225_init(struct hda_codec > > > > > > alc_update_coef_idx(codec, 0x4a, 3 << 10, 0); > > > alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight > > > power */ > > > + printk("%s hp=0x%x\n",__func__,hp_pin); > > > } > > > > ... and I don't understand what's your problem. > > > > Is it about that alc255_hp_init() gets called at resume in addition to the boot time? If so, this is the intended behavior. > > > > > > thanks, > > > > Takashi > > > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai@suse.de> > > > Sent: Tuesday, January 15, 2019 3:54 PM > > > To: Kailang <kailang@realtek.com> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: Re: hp_pin was NULL value > > > > > > On Tue, 15 Jan 2019 08:43:40 +0100, > > > Kailang wrote: > > > > > > > > > > > > No, it not expected. > > > > It will enter two times after boot ready. > > > > I think it could add a flag in alc225_hp_init(). > > > > To make sure it only excute one time. How do you think about? > > > > > > Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume(). > > > > > > And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation. > > > > > > > > > thanks, > > > > > > Takashi > > > > > > > > > > > -----Original Message----- > > > > From: Takashi Iwai <tiwai@suse.de> > > > > Sent: Tuesday, January 15, 2019 2:37 PM > > > > To: Kailang <kailang@realtek.com> > > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > > Subject: Re: hp_pin was NULL value > > > > > > > > On Tue, 15 Jan 2019 03:31:33 +0100, Kailang wrote: > > > > > > > > > > Hi Takashi, > > > > > > > > > > Could you receive this email? > > > > > > > > > > BR, > > > > > Kailang > > > > > > > > > > -----Original Message----- > > > > > From: Kailang > > > > > Sent: Thursday, January 10, 2019 11:14 AM > > > > > To: 'Takashi Iwai' <tiwai@suse.de> > > > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > > > Subject: RE: hp_pin was NULL value > > > > > > > > > > Hi Takashi, > > > > > > > > > > I simulate test your prefer function. > > > > > I put alc225_hp_init() in alc225_init(). > > > > > If system boot ready, I write 1 to power_save of /sys/module/.... > > > > > The print message as below. It called two times until boot ready. > > > > > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > > > > > > > > > [ 21.497524] alc225_init hp_pin=0x21 > > > > > [ 21.497526] alc225_hp_init-s hp=0x21 > > > > > [ 22.140076] alc225_hp_init-e hp=0x21 > > > > > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > [ 22.186846] alc225_shutup hp_pin=0x21 > > > > > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > > > > > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > > > > > [ 22.205104] alc225_init hp_pin=0x21 > > > > > [ 22.205108] alc225_hp_init-s hp=0x21 > > > > > [ 22.852123] alc225_hp_init-e hp=0x21 > > > > > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > ############ Boot ready ############## [ 116.832084] > > > > > alc225_shutup > > > > > hp_pin=0x21 ==> echo 1 to power_save > > > > > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > > > > > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > > > > > alc225_hp_init-e hp=0x21 > > > > > > > > It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? > > > > > > > > > > > > thanks, > > > > > > > > Takashi > > > > > > > > ------Please consider the environment before printing this e-mail. > > > > > > > > > > [2 0000-alc294-hp-init-again.patch <application/octet-stream (base64)>] >
I use Ubuntu to do the test. I can't find S4 function in Ubuntu OS. Does Yours OS support the S4 function? -----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: Tuesday, January 29, 2019 4:29 PM To: Kailang <kailang@realtek.com> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: Re: hp_pin was NULL value On Tue, 29 Jan 2019 09:05:48 +0100, Kailang wrote: > > Hi Takashi, > > I ask our AE for this function. > We also prefer to run it only one time on boot time. S3 resume back not need to run this function. > Because it will take about 650ms times to initial. > > Attach was the new patch. > Reject commit or use attach patch to commit. Which is better? This won't work with S4, unfortunately. The point of S4 problem is that the switch happens from the uninitialized state to the already running system via a single resume callback. That is, the driver was already initialized in the restored image although the chip is still uninitialized on the booted image before the switch. Then switch happens, and since it keeps done_hp_init=1 at S4 resume call, the whole trick won't be applied at all. I'll check whether we have some indicator showing that the call is in thaw/restore, or we'd have to implement a separate thaw/restore callback. thanks, Takashi > > BR, > Kailang > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Tuesday, January 15, 2019 5:17 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Tue, 15 Jan 2019 10:06:58 +0100, > Kailang wrote: > > > > >>>Is it about that alc225_hp_init() gets called at resume in addition to the boot time? > > > > alc225_hp_init() ==> it only need to call one time at boot time. > > This HP initial code doesn't need to call at resume. > > If system boot, HP initial code just need to call it at boot time. > > S3 state was not need to call this function. > > But S4 resume must call this function: that's my point. > > So the question is whether calling alc225_hp_init() at S3 resume is significantly harmful or not. If not, we can move it there. If it's harmful, we need to distinguish S3 and S4, and introduce either some flag or a new callback, which will be a much more work than simply patching the codec code. > > > thanks, > > Takashi > > > Sorry!! Maybe I describe it confuse you. > > > > -----Original Message----- > > From: Takashi Iwai <tiwai@suse.de> > > Sent: Tuesday, January 15, 2019 4:58 PM > > To: Kailang <kailang@realtek.com> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: Re: hp_pin was NULL value > > > > On Tue, 15 Jan 2019 09:17:24 +0100, > > Kailang wrote: > > > > > > > > > Hi Takashi, > > > > > > Sorry!! Maybe I don't understand what you mean. > > > Please see below. > > > > > > --- patch_realtek.c.orig 2019-01-11 16:28:43.745957854 +0800 > > > +++ patch_realtek.c 2019-01-15 16:09:56.017873567 +0800 > > > @@ -3221,12 +3221,29 @@ static void alc256_shutup(struct hda_cod > > > snd_hda_shutup_pins(codec); > > > } > > > > > > +static void alc225_hp_init(struct hda_codec *codec) { > > > + struct alc_spec *spec = codec->spec; > > > + hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > > + int i, val; > > > + int coef38, coef0d, coef36; > > > + printk("%s-start hp=0x%x\n",__func__,hp_pin); > > > + if (!hp_pin) > > > + return; > > > + > > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 1<<15); > > > + msleep(50); > > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 0); > > > + printk("%s-end hp=0x%x\n",__func__,hp_pin); } > > > + > > > static void alc225_init(struct hda_codec *codec) { > > > struct alc_spec *spec = codec->spec; > > > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > > bool hp1_pin_sense, hp2_pin_sense; > > > > > > + alc225_hp_init(codec); > > > if (!hp_pin) > > > return; > > > > > > @@ -3262,6 +3279,7 @@ static void alc225_init(struct hda_codec > > > > > > alc_update_coef_idx(codec, 0x4a, 3 << 10, 0); > > > alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight > > > power */ > > > + printk("%s hp=0x%x\n",__func__,hp_pin); > > > } > > > > ... and I don't understand what's your problem. > > > > Is it about that alc255_hp_init() gets called at resume in addition to the boot time? If so, this is the intended behavior. > > > > > > thanks, > > > > Takashi > > > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai@suse.de> > > > Sent: Tuesday, January 15, 2019 3:54 PM > > > To: Kailang <kailang@realtek.com> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: Re: hp_pin was NULL value > > > > > > On Tue, 15 Jan 2019 08:43:40 +0100, Kailang wrote: > > > > > > > > > > > > No, it not expected. > > > > It will enter two times after boot ready. > > > > I think it could add a flag in alc225_hp_init(). > > > > To make sure it only excute one time. How do you think about? > > > > > > Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume(). > > > > > > And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation. > > > > > > > > > thanks, > > > > > > Takashi > > > > > > > > > > > -----Original Message----- > > > > From: Takashi Iwai <tiwai@suse.de> > > > > Sent: Tuesday, January 15, 2019 2:37 PM > > > > To: Kailang <kailang@realtek.com> > > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > > Subject: Re: hp_pin was NULL value > > > > > > > > On Tue, 15 Jan 2019 03:31:33 +0100, Kailang wrote: > > > > > > > > > > Hi Takashi, > > > > > > > > > > Could you receive this email? > > > > > > > > > > BR, > > > > > Kailang > > > > > > > > > > -----Original Message----- > > > > > From: Kailang > > > > > Sent: Thursday, January 10, 2019 11:14 AM > > > > > To: 'Takashi Iwai' <tiwai@suse.de> > > > > > Cc: (alsa-devel@alsa-project.org) > > > > > <alsa-devel@alsa-project.org> > > > > > Subject: RE: hp_pin was NULL value > > > > > > > > > > Hi Takashi, > > > > > > > > > > I simulate test your prefer function. > > > > > I put alc225_hp_init() in alc225_init(). > > > > > If system boot ready, I write 1 to power_save of /sys/module/.... > > > > > The print message as below. It called two times until boot ready. > > > > > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > > > > > > > > > [ 21.497524] alc225_init hp_pin=0x21 > > > > > [ 21.497526] alc225_hp_init-s hp=0x21 > > > > > [ 22.140076] alc225_hp_init-e hp=0x21 > > > > > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > [ 22.186846] alc225_shutup hp_pin=0x21 > > > > > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > > > > > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > > > > > [ 22.205104] alc225_init hp_pin=0x21 > > > > > [ 22.205108] alc225_hp_init-s hp=0x21 > > > > > [ 22.852123] alc225_hp_init-e hp=0x21 > > > > > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > ############ Boot ready ############## [ 116.832084] > > > > > alc225_shutup > > > > > hp_pin=0x21 ==> echo 1 to power_save > > > > > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > > > > > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > > > > > alc225_hp_init-e hp=0x21 > > > > > > > > It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? > > > > > > > > > > > > thanks, > > > > > > > > Takashi > > > > > > > > ------Please consider the environment before printing this e-mail. > > > > > > > > > > [2 0000-alc294-hp-init-again.patch <application/octet-stream > (base64)>] >
Hi Takashi, So I think put it under alc269 parser. Maybe it is the quickly method. err = alc269_parse_auto_config(codec); if (err < 0) goto error; + ..... + ..... BR, kailang -----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: Tuesday, January 29, 2019 4:29 PM To: Kailang <kailang@realtek.com> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: Re: hp_pin was NULL value On Tue, 29 Jan 2019 09:05:48 +0100, Kailang wrote: > > Hi Takashi, > > I ask our AE for this function. > We also prefer to run it only one time on boot time. S3 resume back not need to run this function. > Because it will take about 650ms times to initial. > > Attach was the new patch. > Reject commit or use attach patch to commit. Which is better? This won't work with S4, unfortunately. The point of S4 problem is that the switch happens from the uninitialized state to the already running system via a single resume callback. That is, the driver was already initialized in the restored image although the chip is still uninitialized on the booted image before the switch. Then switch happens, and since it keeps done_hp_init=1 at S4 resume call, the whole trick won't be applied at all. I'll check whether we have some indicator showing that the call is in thaw/restore, or we'd have to implement a separate thaw/restore callback. thanks, Takashi > > BR, > Kailang > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Tuesday, January 15, 2019 5:17 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Tue, 15 Jan 2019 10:06:58 +0100, > Kailang wrote: > > > > >>>Is it about that alc225_hp_init() gets called at resume in addition to the boot time? > > > > alc225_hp_init() ==> it only need to call one time at boot time. > > This HP initial code doesn't need to call at resume. > > If system boot, HP initial code just need to call it at boot time. > > S3 state was not need to call this function. > > But S4 resume must call this function: that's my point. > > So the question is whether calling alc225_hp_init() at S3 resume is significantly harmful or not. If not, we can move it there. If it's harmful, we need to distinguish S3 and S4, and introduce either some flag or a new callback, which will be a much more work than simply patching the codec code. > > > thanks, > > Takashi > > > Sorry!! Maybe I describe it confuse you. > > > > -----Original Message----- > > From: Takashi Iwai <tiwai@suse.de> > > Sent: Tuesday, January 15, 2019 4:58 PM > > To: Kailang <kailang@realtek.com> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: Re: hp_pin was NULL value > > > > On Tue, 15 Jan 2019 09:17:24 +0100, > > Kailang wrote: > > > > > > > > > Hi Takashi, > > > > > > Sorry!! Maybe I don't understand what you mean. > > > Please see below. > > > > > > --- patch_realtek.c.orig 2019-01-11 16:28:43.745957854 +0800 > > > +++ patch_realtek.c 2019-01-15 16:09:56.017873567 +0800 > > > @@ -3221,12 +3221,29 @@ static void alc256_shutup(struct hda_cod > > > snd_hda_shutup_pins(codec); > > > } > > > > > > +static void alc225_hp_init(struct hda_codec *codec) { > > > + struct alc_spec *spec = codec->spec; > > > + hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > > + int i, val; > > > + int coef38, coef0d, coef36; > > > + printk("%s-start hp=0x%x\n",__func__,hp_pin); > > > + if (!hp_pin) > > > + return; > > > + > > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 1<<15); > > > + msleep(50); > > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 0); > > > + printk("%s-end hp=0x%x\n",__func__,hp_pin); } > > > + > > > static void alc225_init(struct hda_codec *codec) { > > > struct alc_spec *spec = codec->spec; > > > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > > bool hp1_pin_sense, hp2_pin_sense; > > > > > > + alc225_hp_init(codec); > > > if (!hp_pin) > > > return; > > > > > > @@ -3262,6 +3279,7 @@ static void alc225_init(struct hda_codec > > > > > > alc_update_coef_idx(codec, 0x4a, 3 << 10, 0); > > > alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight > > > power */ > > > + printk("%s hp=0x%x\n",__func__,hp_pin); > > > } > > > > ... and I don't understand what's your problem. > > > > Is it about that alc255_hp_init() gets called at resume in addition to the boot time? If so, this is the intended behavior. > > > > > > thanks, > > > > Takashi > > > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai@suse.de> > > > Sent: Tuesday, January 15, 2019 3:54 PM > > > To: Kailang <kailang@realtek.com> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: Re: hp_pin was NULL value > > > > > > On Tue, 15 Jan 2019 08:43:40 +0100, Kailang wrote: > > > > > > > > > > > > No, it not expected. > > > > It will enter two times after boot ready. > > > > I think it could add a flag in alc225_hp_init(). > > > > To make sure it only excute one time. How do you think about? > > > > > > Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume(). > > > > > > And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation. > > > > > > > > > thanks, > > > > > > Takashi > > > > > > > > > > > -----Original Message----- > > > > From: Takashi Iwai <tiwai@suse.de> > > > > Sent: Tuesday, January 15, 2019 2:37 PM > > > > To: Kailang <kailang@realtek.com> > > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > > Subject: Re: hp_pin was NULL value > > > > > > > > On Tue, 15 Jan 2019 03:31:33 +0100, Kailang wrote: > > > > > > > > > > Hi Takashi, > > > > > > > > > > Could you receive this email? > > > > > > > > > > BR, > > > > > Kailang > > > > > > > > > > -----Original Message----- > > > > > From: Kailang > > > > > Sent: Thursday, January 10, 2019 11:14 AM > > > > > To: 'Takashi Iwai' <tiwai@suse.de> > > > > > Cc: (alsa-devel@alsa-project.org) > > > > > <alsa-devel@alsa-project.org> > > > > > Subject: RE: hp_pin was NULL value > > > > > > > > > > Hi Takashi, > > > > > > > > > > I simulate test your prefer function. > > > > > I put alc225_hp_init() in alc225_init(). > > > > > If system boot ready, I write 1 to power_save of /sys/module/.... > > > > > The print message as below. It called two times until boot ready. > > > > > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > > > > > > > > > [ 21.497524] alc225_init hp_pin=0x21 > > > > > [ 21.497526] alc225_hp_init-s hp=0x21 > > > > > [ 22.140076] alc225_hp_init-e hp=0x21 > > > > > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > [ 22.186846] alc225_shutup hp_pin=0x21 > > > > > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > > > > > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > > > > > [ 22.205104] alc225_init hp_pin=0x21 > > > > > [ 22.205108] alc225_hp_init-s hp=0x21 > > > > > [ 22.852123] alc225_hp_init-e hp=0x21 > > > > > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > ############ Boot ready ############## [ 116.832084] > > > > > alc225_shutup > > > > > hp_pin=0x21 ==> echo 1 to power_save > > > > > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > > > > > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > > > > > alc225_hp_init-e hp=0x21 > > > > > > > > It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? > > > > > > > > > > > > thanks, > > > > > > > > Takashi > > > > > > > > ------Please consider the environment before printing this e-mail. > > > > > > > > > > [2 0000-alc294-hp-init-again.patch <application/octet-stream > (base64)>] >
On Tue, 29 Jan 2019 09:32:47 +0100, Kailang wrote: > > I use Ubuntu to do the test. > I can't find S4 function in Ubuntu OS. > Does Yours OS support the S4 function? Yes. And I'm surprised that Ubuntu doesn't support hibernate. Doesn't "systemctl hibernate" work? Takashi > > -----Original Message----- > From: Takashi Iwai <tiwai@suse.de> > Sent: Tuesday, January 29, 2019 4:29 PM > To: Kailang <kailang@realtek.com> > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > Subject: Re: hp_pin was NULL value > > On Tue, 29 Jan 2019 09:05:48 +0100, > Kailang wrote: > > > > Hi Takashi, > > > > I ask our AE for this function. > > We also prefer to run it only one time on boot time. S3 resume back not need to run this function. > > Because it will take about 650ms times to initial. > > > > Attach was the new patch. > > Reject commit or use attach patch to commit. Which is better? > > This won't work with S4, unfortunately. > > The point of S4 problem is that the switch happens from the uninitialized state to the already running system via a single resume callback. That is, the driver was already initialized in the restored image although the chip is still uninitialized on the booted image before the switch. Then switch happens, and since it keeps > done_hp_init=1 at S4 resume call, the whole trick won't be applied at all. > > I'll check whether we have some indicator showing that the call is in thaw/restore, or we'd have to implement a separate thaw/restore callback. > > > thanks, > > Takashi > > > > > BR, > > Kailang > > > > -----Original Message----- > > From: Takashi Iwai <tiwai@suse.de> > > Sent: Tuesday, January 15, 2019 5:17 PM > > To: Kailang <kailang@realtek.com> > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > Subject: Re: hp_pin was NULL value > > > > On Tue, 15 Jan 2019 10:06:58 +0100, > > Kailang wrote: > > > > > > >>>Is it about that alc225_hp_init() gets called at resume in addition to the boot time? > > > > > > alc225_hp_init() ==> it only need to call one time at boot time. > > > This HP initial code doesn't need to call at resume. > > > If system boot, HP initial code just need to call it at boot time. > > > S3 state was not need to call this function. > > > > But S4 resume must call this function: that's my point. > > > > So the question is whether calling alc225_hp_init() at S3 resume is significantly harmful or not. If not, we can move it there. If it's harmful, we need to distinguish S3 and S4, and introduce either some flag or a new callback, which will be a much more work than simply patching the codec code. > > > > > > thanks, > > > > Takashi > > > > > Sorry!! Maybe I describe it confuse you. > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai@suse.de> > > > Sent: Tuesday, January 15, 2019 4:58 PM > > > To: Kailang <kailang@realtek.com> > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > Subject: Re: hp_pin was NULL value > > > > > > On Tue, 15 Jan 2019 09:17:24 +0100, > > > Kailang wrote: > > > > > > > > > > > > Hi Takashi, > > > > > > > > Sorry!! Maybe I don't understand what you mean. > > > > Please see below. > > > > > > > > --- patch_realtek.c.orig 2019-01-11 16:28:43.745957854 +0800 > > > > +++ patch_realtek.c 2019-01-15 16:09:56.017873567 +0800 > > > > @@ -3221,12 +3221,29 @@ static void alc256_shutup(struct hda_cod > > > > snd_hda_shutup_pins(codec); > > > > } > > > > > > > > +static void alc225_hp_init(struct hda_codec *codec) { > > > > + struct alc_spec *spec = codec->spec; > > > > + hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > > > + int i, val; > > > > + int coef38, coef0d, coef36; > > > > + printk("%s-start hp=0x%x\n",__func__,hp_pin); > > > > + if (!hp_pin) > > > > + return; > > > > + > > > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 1<<15); > > > > + msleep(50); > > > > + alc_update_coef_idx(codec, 0x4a, 1<<15, 0); > > > > + printk("%s-end hp=0x%x\n",__func__,hp_pin); } > > > > + > > > > static void alc225_init(struct hda_codec *codec) { > > > > struct alc_spec *spec = codec->spec; > > > > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > > > bool hp1_pin_sense, hp2_pin_sense; > > > > > > > > + alc225_hp_init(codec); > > > > if (!hp_pin) > > > > return; > > > > > > > > @@ -3262,6 +3279,7 @@ static void alc225_init(struct hda_codec > > > > > > > > alc_update_coef_idx(codec, 0x4a, 3 << 10, 0); > > > > alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight > > > > power */ > > > > + printk("%s hp=0x%x\n",__func__,hp_pin); > > > > } > > > > > > ... and I don't understand what's your problem. > > > > > > Is it about that alc255_hp_init() gets called at resume in addition to the boot time? If so, this is the intended behavior. > > > > > > > > > thanks, > > > > > > Takashi > > > > > > > > > > > -----Original Message----- > > > > From: Takashi Iwai <tiwai@suse.de> > > > > Sent: Tuesday, January 15, 2019 3:54 PM > > > > To: Kailang <kailang@realtek.com> > > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > > Subject: Re: hp_pin was NULL value > > > > > > > > On Tue, 15 Jan 2019 08:43:40 +0100, Kailang wrote: > > > > > > > > > > > > > > > No, it not expected. > > > > > It will enter two times after boot ready. > > > > > I think it could add a flag in alc225_hp_init(). > > > > > To make sure it only excute one time. How do you think about? > > > > > > > > Where was it called, actually? The call of patch_ops.init is found in several places: once in snd_hda_codec_build_controls() just before creating controls (which is the boot time init), and at resume, alc269_resume(). > > > > > > > > And, as already explained, we have to call this at resume, because it's not guaranteed that it's been already called in the case of hibernation. > > > > > > > > > > > > thanks, > > > > > > > > Takashi > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Takashi Iwai <tiwai@suse.de> > > > > > Sent: Tuesday, January 15, 2019 2:37 PM > > > > > To: Kailang <kailang@realtek.com> > > > > > Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> > > > > > Subject: Re: hp_pin was NULL value > > > > > > > > > > On Tue, 15 Jan 2019 03:31:33 +0100, Kailang wrote: > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > Could you receive this email? > > > > > > > > > > > > BR, > > > > > > Kailang > > > > > > > > > > > > -----Original Message----- > > > > > > From: Kailang > > > > > > Sent: Thursday, January 10, 2019 11:14 AM > > > > > > To: 'Takashi Iwai' <tiwai@suse.de> > > > > > > Cc: (alsa-devel@alsa-project.org) > > > > > > <alsa-devel@alsa-project.org> > > > > > > Subject: RE: hp_pin was NULL value > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > I simulate test your prefer function. > > > > > > I put alc225_hp_init() in alc225_init(). > > > > > > If system boot ready, I write 1 to power_save of /sys/module/.... > > > > > > The print message as below. It called two times until boot ready. > > > > > > If System enter to power save, play stream will wake up codec. It also call alc225_hp_init(). > > > > > > > > > > > > [ 21.497524] alc225_init hp_pin=0x21 > > > > > > [ 21.497526] alc225_hp_init-s hp=0x21 > > > > > > [ 22.140076] alc225_hp_init-e hp=0x21 > > > > > > [ 22.183496] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > > [ 22.184681] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > > [ 22.186846] alc225_shutup hp_pin=0x21 > > > > > > [ 22.187831] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5 > > > > > > [ 22.188055] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 > > > > > > [ 22.205104] alc225_init hp_pin=0x21 > > > > > > [ 22.205108] alc225_hp_init-s hp=0x21 > > > > > > [ 22.852123] alc225_hp_init-e hp=0x21 > > > > > > [ 22.894772] snd_hda_codec_realtek hdaudioC0D2: Headset jack set to unplugged mode. > > > > > > ############ Boot ready ############## [ 116.832084] > > > > > > alc225_shutup > > > > > > hp_pin=0x21 ==> echo 1 to power_save > > > > > > [ 120.002582] alc225_init hp_pin=0x21 ==> play system sound > > > > > > [ 120.002586] alc225_hp_init-s hp=0x21 [ 120.644128] > > > > > > alc225_hp_init-e hp=0x21 > > > > > > > > > > It wasn't clear to me whether you meant this as a success or a failure... Did the patch work as expected, no? > > > > > > > > > > > > > > > thanks, > > > > > > > > > > Takashi > > > > > > > > > > ------Please consider the environment before printing this e-mail. > > > > > > > > > > > > > > [2 0000-alc294-hp-init-again.patch <application/octet-stream > > (base64)>] > > >
On Tue, 29 Jan 2019 09:39:56 +0100, Kailang wrote: > > Hi Takashi, > > So I think put it under alc269 parser. Maybe it is the quickly method. > > err = alc269_parse_auto_config(codec); > if (err < 0) > goto error; > + ..... > + ..... Not really... The init sequence needs to be applied in two different places: once in the init callback, and another in the resume callback but only for the hibernation restore. The patches below are applied on top of yours, and this should make things working. The first one lets the HD-audio core recording the currently processed PM event, and the second one evaluates it and applies the missing init sequence also for the hibernation resume. This isn't quite sexy, but it has the minimal change in the codec driver side. If this requirement is more common, we can think of splitting / reorganizing the codec callbacks to be more directly called from the device pm ops. thanks, Takashi
On Tue, 29 Jan 2019 14:22:45 +0100, Takashi Iwai wrote: > > On Tue, 29 Jan 2019 09:39:56 +0100, > Kailang wrote: > > > > Hi Takashi, > > > > So I think put it under alc269 parser. Maybe it is the quickly method. > > > > err = alc269_parse_auto_config(codec); > > if (err < 0) > > goto error; > > + ..... > > + ..... > > Not really... The init sequence needs to be applied in two different > places: once in the init callback, and another in the resume callback > but only for the hibernation restore. > > The patches below are applied on top of yours, and this should make > things working. > > The first one lets the HD-audio core recording the currently processed > PM event, and the second one evaluates it and applies the missing init > sequence also for the hibernation resume. > > This isn't quite sexy, but it has the minimal change in the codec > driver side. If this requirement is more common, we can think of > splitting / reorganizing the codec callbacks to be more directly > called from the device pm ops. I did quick tests and the test result looks positive, at least, about the PM power_state change tracking. So I'm going to push your fix to for-linus for 5.0, while other two to for-next, for 5.1, as the S4 resume issue isn't any urgent bug and it's no regression, either. thanks, Takashi
Many Thanks. ^^ -----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: Tuesday, January 29, 2019 11:37 PM To: Kailang <kailang@realtek.com> Cc: (alsa-devel@alsa-project.org) <alsa-devel@alsa-project.org> Subject: Re: hp_pin was NULL value On Tue, 29 Jan 2019 14:22:45 +0100, Takashi Iwai wrote: > > On Tue, 29 Jan 2019 09:39:56 +0100, > Kailang wrote: > > > > Hi Takashi, > > > > So I think put it under alc269 parser. Maybe it is the quickly method. > > > > err = alc269_parse_auto_config(codec); > > if (err < 0) > > goto error; > > + ..... > > + ..... > > Not really... The init sequence needs to be applied in two different > places: once in the init callback, and another in the resume callback > but only for the hibernation restore. > > The patches below are applied on top of yours, and this should make > things working. > > The first one lets the HD-audio core recording the currently processed > PM event, and the second one evaluates it and applies the missing init > sequence also for the hibernation resume. > > This isn't quite sexy, but it has the minimal change in the codec > driver side. If this requirement is more common, we can think of > splitting / reorganizing the codec callbacks to be more directly > called from the device pm ops. I did quick tests and the test result looks positive, at least, about the PM power_state change tracking. So I'm going to push your fix to for-linus for 5.0, while other two to for-next, for 5.1, as the S4 resume issue isn't any urgent bug and it's no regression, either. thanks, Takashi ------Please consider the environment before printing this e-mail.
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7514,7 +7514,6 @@ static int patch_alc269(struct hda_codec *codec) spec->codec_variant = ALC269_TYPE_ALC294; spec->gen.mixer_nid = 0; /* ALC2x4 does not have any loopback mixer path */ alc_update_coef_idx(codec, 0x6b, 0x0018, (1<<4) | (1<<3)); /* UAJ MIC Vref control by verb */ - alc294_hp_init(codec); break; case 0x10ec0300: spec->codec_variant = ALC269_TYPE_ALC300; @@ -7526,7 +7525,6 @@ static int patch_alc269(struct hda_codec *codec) spec->codec_variant = ALC269_TYPE_ALC700; spec->gen.mixer_nid = 0; /* ALC700 does not have any loopback mixer path */ alc_update_coef_idx(codec, 0x4a, 1 << 15, 0); /* Combo jack auto trigger control */ - alc294_hp_init(codec); break; } @@ -7553,6 +7551,16 @@ static int patch_alc269(struct hda_codec *codec) if (err < 0) goto error; + switch (codec->core.vendor_id) { + case 0x10ec0234: + case 0x10ec0274: + case 0x10ec0294: + case 0x10ec0700: + case 0x10ec0701: + case 0x10ec0703: + alc294_hp_init(codec); + break; + } if (!spec->gen.no_analog && spec->gen.beep_nid && spec->gen.mixer_nid) { err = set_beep_amp(spec, spec->gen.mixer_nid, 0x04, HDA_INPUT); if (err < 0)