From: Bjorn Helgaas <helgaas@kernel.org>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: linux-pci@vger.kernel.org, alsa-devel@alsa-project.org,
tiwai@suse.com, linux-kernel@vger.kernel.org
Subject: Re: [alsa-devel] [PATCH v2 2/2] ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound
Date: Thu, 5 Sep 2019 16:35:09 -0500 [thread overview]
Message-ID: <20190905213509.GI103977@google.com> (raw)
In-Reply-To: <20190828180128.1732-1-kai.heng.feng@canonical.com>
On Thu, Aug 29, 2019 at 02:01:28AM +0800, Kai-Heng Feng wrote:
> It's a common practice to let dGPU unbound and use PCI platform power
> management to disable its power through _OFF method of power resource,
> which is listed by _PR3.
> When the dGPU comes with an HDA function, the HDA won't be suspended if
> the dGPU is unbound, so the power resource can't be turned off.
I'm not involved in applying this patch, but from the peanut gallery:
- The above looks like it might be two paragraphs missing a blank
line between? Or maybe it's one paragraph that needs to be
rewrapped?
- I can't parse the first sentence. I guess "dGPU" and "HDA" are
hardware devices, but I don't know what "unbound" means. Is that
something to do with a driver being bound to the dGPU? Or is it
some connection between the dGPU and the HDA?
- "PCI platform power management" is still confusing -- I think we
either have "PCI power management" that uses the PCI PM Capability
(i.e., writing PCI_PM_CTRL as in pci_raw_set_power_state()) OR we
have "platform power management" that uses some other method,
typically ACPI. Since you refer to _OFF and _PR3, I guess you're
referring to platform power management here.
- "It's common practice to let dGPU unbound" -- does that refer to
some programming technique common in drivers, or some user-level
thing like unloading a driver, or ...? My guess is it probably
means "unbind the driver from the dGPU" but I still don't know
what makes it common practice.
This probably all makes perfect sense to the graphics cognoscenti, but
for the rest of us there are a lot of dots here that are not
connected.
> Commit 37a3a98ef601 ("ALSA: hda - Enable runtime PM only for
> discrete GPU") only allows HDA to be runtime-suspended once GPU is
> bound, to keep APU's HDA working.
>
> However, HDA on dGPU isn't that useful if dGPU is unbound. So let's
> relax the runtime suspend requirement for dGPU's HDA function, to save
> lots of power.
>
> BugLink: https://bugs.launchpad.net/bugs/1840835
> Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers”)
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> v2:
> - Change wording.
> - Rebase to Tiwai's branch.
>
> sound/pci/hda/hda_intel.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 91e71be42fa4..c3654d22795a 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1284,7 +1284,11 @@ static void init_vga_switcheroo(struct azx *chip)
> dev_info(chip->card->dev,
> "Handle vga_switcheroo audio client\n");
> hda->use_vga_switcheroo = 1;
> - chip->bus.keep_power = 1; /* cleared in either gpu_bound op or codec probe */
> +
> + /* cleared in either gpu_bound op or codec probe, or when its
> + * root port has _PR3 (i.e. dGPU).
> + */
> + chip->bus.keep_power = !pci_pr3_present(p);
> chip->driver_caps |= AZX_DCAPS_PM_RUNTIME;
> pci_dev_put(p);
> }
> --
> 2.17.1
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: tiwai@suse.com, linux-pci@vger.kernel.org,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound
Date: Thu, 5 Sep 2019 16:35:09 -0500 [thread overview]
Message-ID: <20190905213509.GI103977@google.com> (raw)
In-Reply-To: <20190828180128.1732-1-kai.heng.feng@canonical.com>
On Thu, Aug 29, 2019 at 02:01:28AM +0800, Kai-Heng Feng wrote:
> It's a common practice to let dGPU unbound and use PCI platform power
> management to disable its power through _OFF method of power resource,
> which is listed by _PR3.
> When the dGPU comes with an HDA function, the HDA won't be suspended if
> the dGPU is unbound, so the power resource can't be turned off.
I'm not involved in applying this patch, but from the peanut gallery:
- The above looks like it might be two paragraphs missing a blank
line between? Or maybe it's one paragraph that needs to be
rewrapped?
- I can't parse the first sentence. I guess "dGPU" and "HDA" are
hardware devices, but I don't know what "unbound" means. Is that
something to do with a driver being bound to the dGPU? Or is it
some connection between the dGPU and the HDA?
- "PCI platform power management" is still confusing -- I think we
either have "PCI power management" that uses the PCI PM Capability
(i.e., writing PCI_PM_CTRL as in pci_raw_set_power_state()) OR we
have "platform power management" that uses some other method,
typically ACPI. Since you refer to _OFF and _PR3, I guess you're
referring to platform power management here.
- "It's common practice to let dGPU unbound" -- does that refer to
some programming technique common in drivers, or some user-level
thing like unloading a driver, or ...? My guess is it probably
means "unbind the driver from the dGPU" but I still don't know
what makes it common practice.
This probably all makes perfect sense to the graphics cognoscenti, but
for the rest of us there are a lot of dots here that are not
connected.
> Commit 37a3a98ef601 ("ALSA: hda - Enable runtime PM only for
> discrete GPU") only allows HDA to be runtime-suspended once GPU is
> bound, to keep APU's HDA working.
>
> However, HDA on dGPU isn't that useful if dGPU is unbound. So let's
> relax the runtime suspend requirement for dGPU's HDA function, to save
> lots of power.
>
> BugLink: https://bugs.launchpad.net/bugs/1840835
> Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers”)
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> v2:
> - Change wording.
> - Rebase to Tiwai's branch.
>
> sound/pci/hda/hda_intel.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 91e71be42fa4..c3654d22795a 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1284,7 +1284,11 @@ static void init_vga_switcheroo(struct azx *chip)
> dev_info(chip->card->dev,
> "Handle vga_switcheroo audio client\n");
> hda->use_vga_switcheroo = 1;
> - chip->bus.keep_power = 1; /* cleared in either gpu_bound op or codec probe */
> +
> + /* cleared in either gpu_bound op or codec probe, or when its
> + * root port has _PR3 (i.e. dGPU).
> + */
> + chip->bus.keep_power = !pci_pr3_present(p);
> chip->driver_caps |= AZX_DCAPS_PM_RUNTIME;
> pci_dev_put(p);
> }
> --
> 2.17.1
>
next prev parent reply other threads:[~2019-09-05 21:36 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 13:47 [PATCH 1/2] PCI: Add a helper to check Power Resource Requirements _PR3 existence Kai-Heng Feng
2019-08-27 13:47 ` [PATCH 2/2] ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound Kai-Heng Feng
2019-08-27 14:50 ` Kai-Heng Feng
2019-08-27 15:24 ` Takashi Iwai
2019-08-27 15:24 ` Takashi Iwai
2019-08-27 22:31 ` Bjorn Helgaas
2019-08-28 8:25 ` Kai-Heng Feng
2019-08-28 18:01 ` [PATCH v2 " Kai-Heng Feng
2019-09-05 21:35 ` Bjorn Helgaas [this message]
2019-09-05 21:35 ` Bjorn Helgaas
2019-09-17 9:36 ` [alsa-devel] " Kai-Heng Feng
2019-09-17 9:36 ` Kai-Heng Feng
2019-09-18 12:42 ` [alsa-devel] [PATCH v3 2/2] ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound to a driver Kai-Heng Feng
2019-09-18 12:42 ` Kai-Heng Feng
2019-08-27 15:25 ` [PATCH 1/2] PCI: Add a helper to check Power Resource Requirements _PR3 existence Takashi Iwai
2019-08-27 15:25 ` Takashi Iwai
2019-08-27 16:58 ` Kai-Heng Feng
2019-08-27 22:13 ` Bjorn Helgaas
2019-08-27 22:39 ` Peter Wu
2019-09-09 11:41 ` [alsa-devel] " Bjorn Helgaas
2019-09-09 11:41 ` Bjorn Helgaas
2019-09-20 11:23 ` [alsa-devel] " Kai-Heng Feng
2019-09-20 11:23 ` Kai-Heng Feng
2019-09-20 13:26 ` [alsa-devel] " Bjorn Helgaas
2019-09-20 13:26 ` Bjorn Helgaas
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=20190905213509.GI103977@google.com \
--to=helgaas@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.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: 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.