From: Kai-Heng Feng <kai.heng.feng@canonical.com> To: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, Liam Girdwood <lgirdwood@gmail.com>, Ranjani Sridharan <ranjani.sridharan@linux.intel.com>, daniel.baluta@nxp.com, Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>, Rander Wang <rander.wang@intel.com>, Payal Kshirsagar <payalskshirsagar1234@gmail.com>, "moderated list:SOUND - SOUND OPEN FIRMWARE (SOF) DRIVERS" <sound-open-firmware@alsa-project.org>, "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." <alsa-devel@alsa-project.org>, open list <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v2 1/3] ASoC: SOF: Intel: hda: Resume codec to do jack detection Date: Thu, 7 Jan 2021 12:00:16 +0800 [thread overview] Message-ID: <CAAd53p7==ttVR+XQchOLDwreK-4qov4FZQ8Q55HVx5egWDd7BA@mail.gmail.com> (raw) In-Reply-To: <alpine.DEB.2.22.394.2101051425560.864696@eliteleevi.tm.intel.com> On Tue, Jan 5, 2021 at 9:00 PM Kai Vehmanen <kai.vehmanen@linux.intel.com> wrote: > > Hi, > > On Mon, 4 Jan 2021, Kai-Heng Feng wrote: > > > Instead of queueing jackpoll_work, runtime resume the codec to let it > > use different jack detection methods based on jackpoll_interval. > > hmm, but jackpoll_work() does the same thing, right? So end result should > be the same. It depends on the jackpoll_interval value. But yes the end result should be the same. > > > This matches SOF driver's behavior with commit a6e7d0a4bdb0 ("ALSA: hda: > > fix jack detection with Realtek codecs when in D3"). Since SOF only uses > > Realtek codec, we don't need any additional check for the resume. > > This is not quite correct. First, SOF does support any HDA codec, not just > Realteks (see e.g. https://github.com/thesofproject/linux/issues/1807), > and second, this doesn't really match the hda_intel.c patch you mention. > SOF implements a more conservative approach where we basicly assume > codec->forced_resume=1 to always apply, and do not implement support for > codec->relaxed_resume. So the above patch doesn't fully apply to SOF as > the design is not same. OK, I assumed SOF always use Realtek codec, so codec->forced_resume=1 is always applied like the other patch. I'll remove this section. > > > diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c > > index 6875fa570c2c..df59c79cfdfc 100644 > > --- a/sound/soc/sof/intel/hda-codec.c > > +++ b/sound/soc/sof/intel/hda-codec.c > > @@ -93,8 +93,7 @@ void hda_codec_jack_check(struct snd_sof_dev *sdev) > > * has been recorded in STATESTS > > */ > > if (codec->jacktbl.used) > > - schedule_delayed_work(&codec->jackpoll_work, > > - codec->jackpoll_interval); > > + pm_request_resume(&codec->core.dev); > > I think this change is still good. Just drop the but about Realtek > codecs from commit message and maybe s/matches/aligns/. OK, will do. Kai-Heng > > Br, Kai
WARNING: multiple messages have this Message-ID (diff)
From: Kai-Heng Feng <kai.heng.feng@canonical.com> To: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." <alsa-devel@alsa-project.org>, Liam Girdwood <lgirdwood@gmail.com>, open list <linux-kernel@vger.kernel.org>, Takashi Iwai <tiwai@suse.com>, Ranjani Sridharan <ranjani.sridharan@linux.intel.com>, Mark Brown <broonie@kernel.org>, Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>, Payal Kshirsagar <payalskshirsagar1234@gmail.com>, Rander Wang <rander.wang@intel.com>, daniel.baluta@nxp.com, "moderated list:SOUND - SOUND OPEN FIRMWARE \(SOF\) DRIVERS" <sound-open-firmware@alsa-project.org> Subject: Re: [PATCH v2 1/3] ASoC: SOF: Intel: hda: Resume codec to do jack detection Date: Thu, 7 Jan 2021 12:00:16 +0800 [thread overview] Message-ID: <CAAd53p7==ttVR+XQchOLDwreK-4qov4FZQ8Q55HVx5egWDd7BA@mail.gmail.com> (raw) In-Reply-To: <alpine.DEB.2.22.394.2101051425560.864696@eliteleevi.tm.intel.com> On Tue, Jan 5, 2021 at 9:00 PM Kai Vehmanen <kai.vehmanen@linux.intel.com> wrote: > > Hi, > > On Mon, 4 Jan 2021, Kai-Heng Feng wrote: > > > Instead of queueing jackpoll_work, runtime resume the codec to let it > > use different jack detection methods based on jackpoll_interval. > > hmm, but jackpoll_work() does the same thing, right? So end result should > be the same. It depends on the jackpoll_interval value. But yes the end result should be the same. > > > This matches SOF driver's behavior with commit a6e7d0a4bdb0 ("ALSA: hda: > > fix jack detection with Realtek codecs when in D3"). Since SOF only uses > > Realtek codec, we don't need any additional check for the resume. > > This is not quite correct. First, SOF does support any HDA codec, not just > Realteks (see e.g. https://github.com/thesofproject/linux/issues/1807), > and second, this doesn't really match the hda_intel.c patch you mention. > SOF implements a more conservative approach where we basicly assume > codec->forced_resume=1 to always apply, and do not implement support for > codec->relaxed_resume. So the above patch doesn't fully apply to SOF as > the design is not same. OK, I assumed SOF always use Realtek codec, so codec->forced_resume=1 is always applied like the other patch. I'll remove this section. > > > diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c > > index 6875fa570c2c..df59c79cfdfc 100644 > > --- a/sound/soc/sof/intel/hda-codec.c > > +++ b/sound/soc/sof/intel/hda-codec.c > > @@ -93,8 +93,7 @@ void hda_codec_jack_check(struct snd_sof_dev *sdev) > > * has been recorded in STATESTS > > */ > > if (codec->jacktbl.used) > > - schedule_delayed_work(&codec->jackpoll_work, > > - codec->jackpoll_interval); > > + pm_request_resume(&codec->core.dev); > > I think this change is still good. Just drop the but about Realtek > codecs from commit message and maybe s/matches/aligns/. OK, will do. Kai-Heng > > Br, Kai
next prev parent reply other threads:[~2021-01-07 4:01 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-04 14:08 [PATCH v2 1/3] ASoC: SOF: Intel: hda: Resume codec to do jack detection Kai-Heng Feng 2021-01-04 14:08 ` Kai-Heng Feng 2021-01-04 14:08 ` [PATCH v2 2/3] ASoC: SOF: Intel: hda: Modify existing helper to disable WAKEEN Kai-Heng Feng 2021-01-04 14:08 ` Kai-Heng Feng 2021-01-05 12:59 ` Kai Vehmanen 2021-01-05 12:59 ` Kai Vehmanen 2021-01-04 14:08 ` [PATCH v2 3/3] ASoC: SOF: Intel: hda: Avoid checking jack on system suspend Kai-Heng Feng 2021-01-04 14:08 ` Kai-Heng Feng 2021-01-05 12:25 ` Kai Vehmanen 2021-01-05 12:25 ` Kai Vehmanen 2021-01-07 10:32 ` Kai-Heng Feng 2021-01-07 10:32 ` Kai-Heng Feng 2021-01-05 12:57 ` [PATCH v2 1/3] ASoC: SOF: Intel: hda: Resume codec to do jack detection Kai Vehmanen 2021-01-05 12:57 ` Kai Vehmanen 2021-01-07 4:00 ` Kai-Heng Feng [this message] 2021-01-07 4:00 ` Kai-Heng Feng
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='CAAd53p7==ttVR+XQchOLDwreK-4qov4FZQ8Q55HVx5egWDd7BA@mail.gmail.com' \ --to=kai.heng.feng@canonical.com \ --cc=alsa-devel@alsa-project.org \ --cc=broonie@kernel.org \ --cc=daniel.baluta@nxp.com \ --cc=guennadi.liakhovetski@linux.intel.com \ --cc=kai.vehmanen@linux.intel.com \ --cc=lgirdwood@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=payalskshirsagar1234@gmail.com \ --cc=perex@perex.cz \ --cc=pierre-louis.bossart@linux.intel.com \ --cc=rander.wang@intel.com \ --cc=ranjani.sridharan@linux.intel.com \ --cc=sound-open-firmware@alsa-project.org \ --cc=tiwai@suse.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe 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.