From: Takashi Iwai <tiwai@suse.de>
To: Kailang <kailang@realtek.com>
Cc: " (alsa-devel@alsa-project.org)" <alsa-devel@alsa-project.org>
Subject: Re: hp_pin was NULL value
Date: Tue, 29 Jan 2019 14:22:45 +0100 [thread overview]
Message-ID: <s5hpnsffviy.wl-tiwai@suse.de> (raw)
In-Reply-To: <6FAB7C47BCF00940BB0999A99BE3547A18DB7463@RTITMBSVM07.realtek.com.tw>
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
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
[-- Attachment #2: 0001-ALSA-hda-Record-the-current-power-state-before-suspe.patch --]
[-- Type: application/octet-stream, Size: 2624 bytes --]
>From 8028c19c7349737bfb002265b75af75c87d7c7a4 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Tue, 29 Jan 2019 14:03:33 +0100
Subject: [PATCH 1/2] ALSA: hda - Record the current power state before
suspend/resume calls
Currently we deal with single codec and suspend codec callbacks for
all S3, S4 and runtime PM handling. But it turned out that we want
distinguish the call patterns sometimes, e.g. for applying some init
sequence only at probing and restoring from hibernate.
This patch slightly modifies the common PM callbacks for HD-audio
codec and stores the currently processed PM event in power_state of
the codec's device.power field, which is currently unused. The codec
callback can take a look at this event value and judges which purpose
it's being called.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
sound/pci/hda/hda_codec.c | 37 +++++++++++++++++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index e4704f5729d3..43bcc6f1ea8c 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2917,6 +2917,7 @@ static void hda_call_codec_resume(struct hda_codec *codec)
hda_jackpoll_work(&codec->jackpoll_work.work);
else
snd_hda_jack_report_sync(codec);
+ dev->power.power_state = PMSG_ON;
snd_hdac_leave_pm(&codec->core);
}
@@ -2947,10 +2948,42 @@ static int hda_codec_runtime_resume(struct device *dev)
}
#endif /* CONFIG_PM */
+#ifdef CONFIG_PM_SLEEP
+static int hda_codec_pm_suspend(struct device *dev)
+{
+ dev->power.power_state = PMSG_SUSPEND;
+ return pm_runtime_force_suspend(dev);
+}
+
+static int hda_codec_pm_resume(struct device *dev)
+{
+ dev->power.power_state = PMSG_RESUME;
+ return pm_runtime_force_suspend(dev);
+}
+
+static int hda_codec_pm_thaw(struct device *dev)
+{
+ dev->power.power_state = PMSG_THAW;
+ return pm_runtime_force_resume(dev);
+}
+
+static int hda_codec_pm_restore(struct device *dev)
+{
+ dev->power.power_state = PMSG_RESTORE;
+ return pm_runtime_force_resume(dev);
+}
+#endif /* CONFIG_PM_SLEEP */
+
/* referred in hda_bind.c */
const struct dev_pm_ops hda_codec_driver_pm = {
- SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
- pm_runtime_force_resume)
+#ifdef CONFIG_PM_SLEEP
+ .suspend = hda_codec_pm_suspend,
+ .resume = hda_codec_pm_resume,
+ .freeze = hda_codec_pm_freeze,
+ .thaw = hda_codec_pm_thaw,
+ .poweroff = hda_codec_pm_suspend,
+ .restore = hda_codec_pm_restore,
+#endif /* CONFIG_PM_SLEEP */
SET_RUNTIME_PM_OPS(hda_codec_runtime_suspend, hda_codec_runtime_resume,
NULL)
};
--
2.16.4
[-- Attachment #3: 0002-ALSA-hda-realtek-Apply-ALC294-hp-init-also-for-S4-re.patch --]
[-- Type: application/octet-stream, Size: 1276 bytes --]
>From 259f064043a264d6b45b3e9738947a24814d9ab0 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Tue, 29 Jan 2019 14:14:51 +0100
Subject: [PATCH 2/2] ALSA: hda/realtek - Apply ALC294 hp init also for S4
resume
The init sequence for ALC294 headphone stuff is needed not only for
the boot up time but also for the resume from hibernation, where the
device is switched from the boot kernel without sound driver to the
suspended image. Since we record the PM event in the device
power_state field, we can now recognize the call pattern and apply the
sequence conditionally.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
sound/pci/hda/patch_realtek.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 4139aced63f8..e9dc9408d9bc 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3408,7 +3408,9 @@ static void alc294_init(struct hda_codec *codec)
{
struct alc_spec *spec = codec->spec;
- if (!spec->done_hp_init) {
+ /* required only at boot or S4 resume time */
+ if (!spec->done_hp_init ||
+ codec->core.dev.power.power_state.event == PM_EVENT_RESTORE) {
alc294_hp_init(codec);
spec->done_hp_init = true;
}
--
2.16.4
[-- Attachment #4: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2019-01-29 13:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-09 9:31 hp_pin was NULL value Kailang
2019-01-09 9:42 ` Takashi Iwai
2019-01-09 9:45 ` Kailang
2019-01-09 9:56 ` Takashi Iwai
[not found] ` <6FAB7C47BCF00940BB0999A99BE3547A18420EE6@RTITMBSV02.realtek.com.tw>
2019-01-09 11:29 ` Takashi Iwai
[not found] ` <6FAB7C47BCF00940BB0999A99BE3547A18420F05@RTITMBSV02.realtek.com.tw>
2019-01-09 13:00 ` Takashi Iwai
2019-01-10 3:14 ` Kailang
2019-01-15 2:31 ` Kailang
2019-01-15 6:36 ` Takashi Iwai
2019-01-15 7:43 ` Kailang
2019-01-15 7:53 ` Takashi Iwai
2019-01-15 8:17 ` Kailang
2019-01-15 8:57 ` Takashi Iwai
2019-01-15 9:06 ` Kailang
2019-01-15 9:16 ` Takashi Iwai
2019-01-15 9:25 ` Kailang
2019-01-29 8:05 ` Kailang
2019-01-29 8:28 ` Takashi Iwai
2019-01-29 8:32 ` Kailang
2019-01-29 9:11 ` Takashi Iwai
2019-01-29 8:39 ` Kailang
2019-01-29 13:22 ` Takashi Iwai [this message]
2019-01-29 15:37 ` Takashi Iwai
2019-01-30 6:26 ` Kailang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hpnsffviy.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=kailang@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.