[PATCH] ALSA: hda: Enable runtime PM when codec probe fails
When codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So enable runtime PM when codec probe fails, to let graphics card be able to runtime suspend again.
Merge azx_probe_continue() into azx_probe() and just let probe fail for this case could be a better approach. However that's a much bigger task so let's settle with a quirk workaround.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com --- sound/pci/hda/hda_intel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6852668f1bcb..3fd920069268 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip) if (bus->codec_mask) { err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); if (err < 0) - goto out_free; + goto out_enable_rpm; }
#ifdef CONFIG_SND_HDA_PATCH_LOADER @@ -2360,6 +2360,7 @@ static int azx_probe_continue(struct azx *chip)
set_default_power_save(chip);
+out_enable_rpm: if (azx_has_pm_runtime(chip)) { pm_runtime_use_autosuspend(&pci->dev); pm_runtime_allow(&pci->dev);
On Mon, 14 Dec 2020 07:06:20 +0100, Kai-Heng Feng wrote:
When codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So enable runtime PM when codec probe fails, to let graphics card be able to runtime suspend again.
Well, the runtime status is also active if the driver isn't probed at all. In that sense, keeping the status active at the driver load failure is rather consistent, IMO. If the driver fails or unloaded, it should restore the status as if it were beforehand.
thanks,
Takashi
Merge azx_probe_continue() into azx_probe() and just let probe fail for this case could be a better approach. However that's a much bigger task so let's settle with a quirk workaround.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
sound/pci/hda/hda_intel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6852668f1bcb..3fd920069268 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip) if (bus->codec_mask) { err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); if (err < 0)
goto out_free;
goto out_enable_rpm;#ifdef CONFIG_SND_HDA_PATCH_LOADER @@ -2360,6 +2360,7 @@ static int azx_probe_continue(struct azx *chip)
set_default_power_save(chip);
+out_enable_rpm: if (azx_has_pm_runtime(chip)) { pm_runtime_use_autosuspend(&pci->dev); pm_runtime_allow(&pci->dev); -- 2.29.2
On Mon, Dec 14, 2020 at 08:58, Takashi Iwai tiwai@suse.de wrote:
On Mon, 14 Dec 2020 07:06:20 +0100, Kai-Heng Feng wrote:
When codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So enable runtime PM when codec probe fails, to let graphics card be able to runtime suspend again.
Well, the runtime status is also active if the driver isn't probed at all. In that sense, keeping the status active at the driver load failure is rather consistent, IMO. If the driver fails or unloaded, it should restore the status as if it were beforehand.
Ok, let me find a better way to handle it.
Kai-Heng
thanks,
Takashi
Merge azx_probe_continue() into azx_probe() and just let probe fail for this case could be a better approach. However that's a much bigger task so let's settle with a quirk workaround.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com
mailto:kai.heng.feng@canonical.com>
sound/pci/hda/hda_intel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6852668f1bcb..3fd920069268 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip) if (bus->codec_mask) { err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); if (err < 0)
goto out_free;
goto out_enable_rpm;#ifdef CONFIG_SND_HDA_PATCH_LOADER @@ -2360,6 +2360,7 @@ static int azx_probe_continue(struct azx *chip)
set_default_power_save(chip);
+out_enable_rpm: if (azx_has_pm_runtime(chip)) { pm_runtime_use_autosuspend(&pci->dev); pm_runtime_allow(&pci->dev); -- 2.29.2
Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller initialization even if no codecs found"), when codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So mark there's no codec and continue probing to let runtime PM to work.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com --- sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6852668f1bcb..872a703dee43 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip) if (bus->codec_mask) { err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); if (err < 0) - goto out_free; + bus->codec_mask = 0; }
#ifdef CONFIG_SND_HDA_PATCH_LOADER
On Wed, 16 Dec 2020 13:47:24 +0100, Kai-Heng Feng wrote:
Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller initialization even if no codecs found"), when codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So mark there's no codec and continue probing to let runtime PM to work.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
Hm, but if the probe fails, doesn't it mean something really wrong? IOW, how does this situation happen?
The usual no-codec state is for the devices that have a bogus HD-audio bus remaining while codecs aren't hooked or disabled by BIOS. For that, it makes to leave the controller driver and let it idle. But if you get really an error, it's something to fix there, not to just ignore in general.
thanks,
Takashi
sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6852668f1bcb..872a703dee43 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip) if (bus->codec_mask) { err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); if (err < 0)
goto out_free;
bus->codec_mask = 0;#ifdef CONFIG_SND_HDA_PATCH_LOADER
2.29.2
On Wed, Dec 16, 2020 at 11:41 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 13:47:24 +0100, Kai-Heng Feng wrote:
Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller initialization even if no codecs found"), when codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So mark there's no codec and continue probing to let runtime PM to work.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
Hm, but if the probe fails, doesn't it mean something really wrong? IOW, how does this situation happen?
The HDA controller is forcely created by quirk_nvidia_hda(). So probably there's really not an HDA controller.
The usual no-codec state is for the devices that have a bogus HD-audio bus remaining while codecs aren't hooked or disabled by BIOS. For that, it makes to leave the controller driver and let it idle. But if you get really an error, it's something to fix there, not to just ignore in general.
The best approach I can think of is to make current two steps probe into one. So when probe fails, the driver won't bind to the device. What's the reason behind the two steps approach?
Kai-Heng
thanks,
Takashi
sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6852668f1bcb..872a703dee43 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip) if (bus->codec_mask) { err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); if (err < 0)
goto out_free;
bus->codec_mask = 0; }#ifdef CONFIG_SND_HDA_PATCH_LOADER
2.29.2
On Wed, 16 Dec 2020 16:50:20 +0100, Kai-Heng Feng wrote:
On Wed, Dec 16, 2020 at 11:41 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 13:47:24 +0100, Kai-Heng Feng wrote:
Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller initialization even if no codecs found"), when codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So mark there's no codec and continue probing to let runtime PM to work.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
Hm, but if the probe fails, doesn't it mean something really wrong? IOW, how does this situation happen?
The HDA controller is forcely created by quirk_nvidia_hda(). So probably there's really not an HDA controller.
I still don't understand how non-zero codec_mask is passed. The non-zero codec_mask means that BIOS or whatever believes that HD-audio codecs are present and let HD-audio controller reporting the presence. What error did you get at probing?
The usual no-codec state is for the devices that have a bogus HD-audio bus remaining while codecs aren't hooked or disabled by BIOS. For that, it makes to leave the controller driver and let it idle. But if you get really an error, it's something to fix there, not to just ignore in general.
The best approach I can think of is to make current two steps probe into one. So when probe fails, the driver won't bind to the device. What's the reason behind the two steps approach?
It's a sort of must, as the module loading is involved with binding with the codecs, as well as (optionally) request_firmware() invocation.
Takashi
On Wed, Dec 16, 2020 at 11:58 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 16:50:20 +0100, Kai-Heng Feng wrote:
On Wed, Dec 16, 2020 at 11:41 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 13:47:24 +0100, Kai-Heng Feng wrote:
Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller initialization even if no codecs found"), when codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So mark there's no codec and continue probing to let runtime PM to work.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
Hm, but if the probe fails, doesn't it mean something really wrong? IOW, how does this situation happen?
The HDA controller is forcely created by quirk_nvidia_hda(). So probably there's really not an HDA controller.
I still don't understand how non-zero codec_mask is passed. The non-zero codec_mask means that BIOS or whatever believes that HD-audio codecs are present and let HD-audio controller reporting the presence. What error did you get at probing?
[ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized Full dmesg here: https://launchpadlibrarian.net/510351476/dmesg.log
The usual no-codec state is for the devices that have a bogus HD-audio bus remaining while codecs aren't hooked or disabled by BIOS. For that, it makes to leave the controller driver and let it idle. But if you get really an error, it's something to fix there, not to just ignore in general.
The best approach I can think of is to make current two steps probe into one. So when probe fails, the driver won't bind to the device. What's the reason behind the two steps approach?
It's a sort of must, as the module loading is involved with binding with the codecs, as well as (optionally) request_firmware() invocation.
Ok. I also tried to use device_release_driver(), but azx_remove() calls "cancel_work_sync(&hda->probe_work)" so there will be a deadlock.
Kai-Heng
Takashi
On Wed, 16 Dec 2020 17:07:45 +0100, Kai-Heng Feng wrote:
On Wed, Dec 16, 2020 at 11:58 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 16:50:20 +0100, Kai-Heng Feng wrote:
On Wed, Dec 16, 2020 at 11:41 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 13:47:24 +0100, Kai-Heng Feng wrote:
Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller initialization even if no codecs found"), when codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So mark there's no codec and continue probing to let runtime PM to work.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
Hm, but if the probe fails, doesn't it mean something really wrong? IOW, how does this situation happen?
The HDA controller is forcely created by quirk_nvidia_hda(). So probably there's really not an HDA controller.
I still don't understand how non-zero codec_mask is passed. The non-zero codec_mask means that BIOS or whatever believes that HD-audio codecs are present and let HD-audio controller reporting the presence. What error did you get at probing?
[ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized Full dmesg here: https://launchpadlibrarian.net/510351476/dmesg.log
The actual problems are shown before that line.
[ 4.178848] pci 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.179502] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.179511] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible) .... [ 4.280571] hdaudio hdaudioC1D0: no AFG or MFG node found [ 4.280633] hdaudio hdaudioC1D1: no AFG or MFG node found [ 4.280685] hdaudio hdaudioC1D2: no AFG or MFG node found [ 4.280736] hdaudio hdaudioC1D3: no AFG or MFG node found [ 4.280788] hdaudio hdaudioC1D4: no AFG or MFG node found [ 4.280839] hdaudio hdaudioC1D5: no AFG or MFG node found [ 4.280892] hdaudio hdaudioC1D6: no AFG or MFG node found [ 4.280943] hdaudio hdaudioC1D7: no AFG or MFG node found
Could you check the codec_mask value read in sound/hda/hdac_controller.c? I guess it reads 0xff.
If that's the case, it can be corrected by the patch below. But, we should check the cause of the first error (inaccessible config space) in anyway; this must be the primary reason of the whole chain of errors.
The usual no-codec state is for the devices that have a bogus HD-audio bus remaining while codecs aren't hooked or disabled by BIOS. For that, it makes to leave the controller driver and let it idle. But if you get really an error, it's something to fix there, not to just ignore in general.
The best approach I can think of is to make current two steps probe into one. So when probe fails, the driver won't bind to the device. What's the reason behind the two steps approach?
It's a sort of must, as the module loading is involved with binding with the codecs, as well as (optionally) request_firmware() invocation.
Ok. I also tried to use device_release_driver(), but azx_remove() calls "cancel_work_sync(&hda->probe_work)" so there will be a deadlock.
You can't do that.
Takashi
--- --- a/sound/hda/hdac_controller.c +++ b/sound/hda/hdac_controller.c @@ -449,6 +449,10 @@ int snd_hdac_bus_reset_link(struct hdac_bus *bus, bool full_reset) if (!bus->codec_mask) { bus->codec_mask = snd_hdac_chip_readw(bus, STATESTS); dev_dbg(bus->dev, "codec_mask = 0x%lx\n", bus->codec_mask); + if (bus->codec_mask == 0xff) { + dev_err(bus->dev, "failed to read STATESTS register\n"); + bus->codec_mask = 0; + } }
return 0;
On Wed, 16 Dec 2020 17:22:17 +0100, Takashi Iwai wrote:
On Wed, 16 Dec 2020 17:07:45 +0100, Kai-Heng Feng wrote:
On Wed, Dec 16, 2020 at 11:58 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 16:50:20 +0100, Kai-Heng Feng wrote:
On Wed, Dec 16, 2020 at 11:41 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 13:47:24 +0100, Kai-Heng Feng wrote:
Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller initialization even if no codecs found"), when codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So mark there's no codec and continue probing to let runtime PM to work.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
Hm, but if the probe fails, doesn't it mean something really wrong? IOW, how does this situation happen?
The HDA controller is forcely created by quirk_nvidia_hda(). So probably there's really not an HDA controller.
I still don't understand how non-zero codec_mask is passed. The non-zero codec_mask means that BIOS or whatever believes that HD-audio codecs are present and let HD-audio controller reporting the presence. What error did you get at probing?
[ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized Full dmesg here: https://launchpadlibrarian.net/510351476/dmesg.log
The actual problems are shown before that line.
[ 4.178848] pci 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.179502] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.179511] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible) .... [ 4.280571] hdaudio hdaudioC1D0: no AFG or MFG node found [ 4.280633] hdaudio hdaudioC1D1: no AFG or MFG node found [ 4.280685] hdaudio hdaudioC1D2: no AFG or MFG node found [ 4.280736] hdaudio hdaudioC1D3: no AFG or MFG node found [ 4.280788] hdaudio hdaudioC1D4: no AFG or MFG node found [ 4.280839] hdaudio hdaudioC1D5: no AFG or MFG node found [ 4.280892] hdaudio hdaudioC1D6: no AFG or MFG node found [ 4.280943] hdaudio hdaudioC1D7: no AFG or MFG node found
Could you check the codec_mask value read in sound/hda/hdac_controller.c? I guess it reads 0xff.
If that's the case, it can be corrected by the patch below. But, we should check the cause of the first error (inaccessible config space) in anyway; this must be the primary reason of the whole chain of errors.
Now I took a deeper look at the code. So we hit errors after errors: - The first problem is that quirk_nvidia_hda() enabled HD-audio even if it's non-functional by some reason. We may need additional checks there.
- The second problem is that pci_enable_device() ignores the error returned from pci_set_power_state() if it's -EIO. And the inaccessible access error returns -EIO, although it's rather a fatal problem. So the driver believes as the PCI device gets enabled properly.
- The third problem is that HD-audio driver blindly believes the codec_mask read from the register even if it's a read failure as I already showed.
Ideally we should address in the first place.
Takashi
[+Cc Bjorn, Alan and linux-pci]
On Thu, Dec 17, 2020 at 12:57 AM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 17:22:17 +0100, Takashi Iwai wrote:
On Wed, 16 Dec 2020 17:07:45 +0100, Kai-Heng Feng wrote:
On Wed, Dec 16, 2020 at 11:58 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 16:50:20 +0100, Kai-Heng Feng wrote:
On Wed, Dec 16, 2020 at 11:41 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 13:47:24 +0100, Kai-Heng Feng wrote: > > Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller > initialization even if no codecs found"), when codec probe fails, it > doesn't enable runtime suspend, and can prevent graphics card from > getting powered down: > [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized > > $ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status > active > > So mark there's no codec and continue probing to let runtime PM to work. > > BugLink: https://bugs.launchpad.net/bugs/1907212 > Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
Hm, but if the probe fails, doesn't it mean something really wrong? IOW, how does this situation happen?
The HDA controller is forcely created by quirk_nvidia_hda(). So probably there's really not an HDA controller.
I still don't understand how non-zero codec_mask is passed. The non-zero codec_mask means that BIOS or whatever believes that HD-audio codecs are present and let HD-audio controller reporting the presence. What error did you get at probing?
[ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized Full dmesg here: https://launchpadlibrarian.net/510351476/dmesg.log
The actual problems are shown before that line.
[ 4.178848] pci 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.179502] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.179511] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible) .... [ 4.280571] hdaudio hdaudioC1D0: no AFG or MFG node found [ 4.280633] hdaudio hdaudioC1D1: no AFG or MFG node found [ 4.280685] hdaudio hdaudioC1D2: no AFG or MFG node found [ 4.280736] hdaudio hdaudioC1D3: no AFG or MFG node found [ 4.280788] hdaudio hdaudioC1D4: no AFG or MFG node found [ 4.280839] hdaudio hdaudioC1D5: no AFG or MFG node found [ 4.280892] hdaudio hdaudioC1D6: no AFG or MFG node found [ 4.280943] hdaudio hdaudioC1D7: no AFG or MFG node found
Could you check the codec_mask value read in sound/hda/hdac_controller.c? I guess it reads 0xff.
If that's the case, it can be corrected by the patch below. But, we should check the cause of the first error (inaccessible config space) in anyway; this must be the primary reason of the whole chain of errors.
Now I took a deeper look at the code. So we hit errors after errors:
- The first problem is that quirk_nvidia_hda() enabled HD-audio even if it's non-functional by some reason. We may need additional checks there.
Quite possibly the system doesn't power up HDA controller when there's no external monitor. So when it's connected to external monitor, it's still needed for HDMI audio. Let me ask the user to confirm this.
- The second problem is that pci_enable_device() ignores the error returned from pci_set_power_state() if it's -EIO. And the inaccessible access error returns -EIO, although it's rather a fatal problem. So the driver believes as the PCI device gets enabled properly.
This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix regression in pci_enable_device_bars") to fix UHCI controller.
- The third problem is that HD-audio driver blindly believes the codec_mask read from the register even if it's a read failure as I already showed.
This approach has least regression risk.
Kai-Heng
Ideally we should address in the first place.
Takashi
On Fri, 18 Dec 2020 06:09:38 +0100, Kai-Heng Feng wrote:
[+Cc Bjorn, Alan and linux-pci]
On Thu, Dec 17, 2020 at 12:57 AM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 17:22:17 +0100, Takashi Iwai wrote:
On Wed, 16 Dec 2020 17:07:45 +0100, Kai-Heng Feng wrote:
On Wed, Dec 16, 2020 at 11:58 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 16 Dec 2020 16:50:20 +0100, Kai-Heng Feng wrote:
On Wed, Dec 16, 2020 at 11:41 PM Takashi Iwai tiwai@suse.de wrote: > > On Wed, 16 Dec 2020 13:47:24 +0100, > Kai-Heng Feng wrote: > > > > Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller > > initialization even if no codecs found"), when codec probe fails, it > > doesn't enable runtime suspend, and can prevent graphics card from > > getting powered down: > > [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized > > > > $ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status > > active > > > > So mark there's no codec and continue probing to let runtime PM to work. > > > > BugLink: https://bugs.launchpad.net/bugs/1907212 > > Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com > > Hm, but if the probe fails, doesn't it mean something really wrong? > IOW, how does this situation happen?
The HDA controller is forcely created by quirk_nvidia_hda(). So probably there's really not an HDA controller.
I still don't understand how non-zero codec_mask is passed. The non-zero codec_mask means that BIOS or whatever believes that HD-audio codecs are present and let HD-audio controller reporting the presence. What error did you get at probing?
[ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized Full dmesg here: https://launchpadlibrarian.net/510351476/dmesg.log
The actual problems are shown before that line.
[ 4.178848] pci 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.179502] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.179511] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible) .... [ 4.280571] hdaudio hdaudioC1D0: no AFG or MFG node found [ 4.280633] hdaudio hdaudioC1D1: no AFG or MFG node found [ 4.280685] hdaudio hdaudioC1D2: no AFG or MFG node found [ 4.280736] hdaudio hdaudioC1D3: no AFG or MFG node found [ 4.280788] hdaudio hdaudioC1D4: no AFG or MFG node found [ 4.280839] hdaudio hdaudioC1D5: no AFG or MFG node found [ 4.280892] hdaudio hdaudioC1D6: no AFG or MFG node found [ 4.280943] hdaudio hdaudioC1D7: no AFG or MFG node found
Could you check the codec_mask value read in sound/hda/hdac_controller.c? I guess it reads 0xff.
If that's the case, it can be corrected by the patch below. But, we should check the cause of the first error (inaccessible config space) in anyway; this must be the primary reason of the whole chain of errors.
Now I took a deeper look at the code. So we hit errors after errors:
- The first problem is that quirk_nvidia_hda() enabled HD-audio even if it's non-functional by some reason. We may need additional checks there.
Quite possibly the system doesn't power up HDA controller when there's no external monitor. So when it's connected to external monitor, it's still needed for HDMI audio. Let me ask the user to confirm this.
Yeah, it's the basic question whether the HD-audio is supposed to work on this machine at all. If yes, the current approach we take makes less sense - instead we should rather make the HD-audio controller working.
- The second problem is that pci_enable_device() ignores the error returned from pci_set_power_state() if it's -EIO. And the inaccessible access error returns -EIO, although it's rather a fatal problem. So the driver believes as the PCI device gets enabled properly.
This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix regression in pci_enable_device_bars") to fix UHCI controller.
- The third problem is that HD-audio driver blindly believes the codec_mask read from the register even if it's a read failure as I already showed.
This approach has least regression risk.
Yes, but it assumes that HD-audio is really non-existent.
thanks,
Takashi
[+Cc nouveau]
On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai tiwai@suse.de wrote: [snip]
Quite possibly the system doesn't power up HDA controller when there's no external monitor. So when it's connected to external monitor, it's still needed for HDMI audio. Let me ask the user to confirm this.
Yeah, it's the basic question whether the HD-audio is supposed to work on this machine at all. If yes, the current approach we take makes less sense - instead we should rather make the HD-audio controller working.
Yea, confirmed that the Nvidia HDA works when HDMI is connected prior boot.
- The second problem is that pci_enable_device() ignores the error returned from pci_set_power_state() if it's -EIO. And the inaccessible access error returns -EIO, although it's rather a fatal problem. So the driver believes as the PCI device gets enabled properly.
This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix regression in pci_enable_device_bars") to fix UHCI controller.
- The third problem is that HD-audio driver blindly believes the codec_mask read from the register even if it's a read failure as I already showed.
This approach has least regression risk.
Yes, but it assumes that HD-audio is really non-existent.
I really don't know any good approach to address this. On Windows, HDA PCI is "hidden" until HDMI cable is plugged, then the driver will flag the magic bit to make HDA audio appear on the PCI bus. IIRC the current approach is to make nouveau and device link work.
Kai-Heng
thanks,
Takashi
On Mon, 21 Dec 2020 17:33:20 +0100, Kai-Heng Feng wrote:
[+Cc nouveau]
On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai tiwai@suse.de wrote: [snip]
Quite possibly the system doesn't power up HDA controller when there's no external monitor. So when it's connected to external monitor, it's still needed for HDMI audio. Let me ask the user to confirm this.
Yeah, it's the basic question whether the HD-audio is supposed to work on this machine at all. If yes, the current approach we take makes less sense - instead we should rather make the HD-audio controller working.
Yea, confirmed that the Nvidia HDA works when HDMI is connected prior boot.
- The second problem is that pci_enable_device() ignores the error returned from pci_set_power_state() if it's -EIO. And the inaccessible access error returns -EIO, although it's rather a fatal problem. So the driver believes as the PCI device gets enabled properly.
This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix regression in pci_enable_device_bars") to fix UHCI controller.
- The third problem is that HD-audio driver blindly believes the codec_mask read from the register even if it's a read failure as I already showed.
This approach has least regression risk.
Yes, but it assumes that HD-audio is really non-existent.
I really don't know any good approach to address this. On Windows, HDA PCI is "hidden" until HDMI cable is plugged, then the driver will flag the magic bit to make HDA audio appear on the PCI bus. IIRC the current approach is to make nouveau and device link work.
But what happens if you plug the HDMI cable later and want to use the HDMI audio? It won't work with your fix, right?
Takashi
On Tue, Dec 22, 2020 at 12:47 AM Takashi Iwai tiwai@suse.de wrote: [snip]
But what happens if you plug the HDMI cable later and want to use the HDMI audio? It won't work with your fix, right?
No it won't. It's possible to fix from nouveau, but it's at the mercy of Nvidia to fix their proprietary driver, which many users use.
Kai-Heng
Takashi
On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng kai.heng.feng@canonical.com wrote:
[+Cc nouveau]
On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai tiwai@suse.de wrote: [snip]
Quite possibly the system doesn't power up HDA controller when there's no external monitor. So when it's connected to external monitor, it's still needed for HDMI audio. Let me ask the user to confirm this.
Yeah, it's the basic question whether the HD-audio is supposed to work on this machine at all. If yes, the current approach we take makes less sense - instead we should rather make the HD-audio controller working.
Yea, confirmed that the Nvidia HDA works when HDMI is connected prior boot.
- The second problem is that pci_enable_device() ignores the error returned from pci_set_power_state() if it's -EIO. And the inaccessible access error returns -EIO, although it's rather a fatal problem. So the driver believes as the PCI device gets enabled properly.
This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix regression in pci_enable_device_bars") to fix UHCI controller.
- The third problem is that HD-audio driver blindly believes the codec_mask read from the register even if it's a read failure as I already showed.
This approach has least regression risk.
Yes, but it assumes that HD-audio is really non-existent.
I really don't know any good approach to address this. On Windows, HDA PCI is "hidden" until HDMI cable is plugged, then the driver will flag the magic bit to make HDA audio appear on the PCI bus. IIRC the current approach is to make nouveau and device link work.
I don't have the full context of this discussion, but the kernel force-enables the HDA subfunction nowadays, irrespective of nouveau or nvidia or whatever:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
Cheers,
-ilia
On Tue, Dec 22, 2020 at 1:56 AM Ilia Mirkin imirkin@alum.mit.edu wrote:
On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng kai.heng.feng@canonical.com wrote:
[+Cc nouveau]
On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai tiwai@suse.de wrote: [snip]
Quite possibly the system doesn't power up HDA controller when there's no external monitor. So when it's connected to external monitor, it's still needed for HDMI audio. Let me ask the user to confirm this.
Yeah, it's the basic question whether the HD-audio is supposed to work on this machine at all. If yes, the current approach we take makes less sense - instead we should rather make the HD-audio controller working.
Yea, confirmed that the Nvidia HDA works when HDMI is connected prior boot.
- The second problem is that pci_enable_device() ignores the error returned from pci_set_power_state() if it's -EIO. And the inaccessible access error returns -EIO, although it's rather a fatal problem. So the driver believes as the PCI device gets enabled properly.
This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix regression in pci_enable_device_bars") to fix UHCI controller.
- The third problem is that HD-audio driver blindly believes the codec_mask read from the register even if it's a read failure as I already showed.
This approach has least regression risk.
Yes, but it assumes that HD-audio is really non-existent.
I really don't know any good approach to address this. On Windows, HDA PCI is "hidden" until HDMI cable is plugged, then the driver will flag the magic bit to make HDA audio appear on the PCI bus. IIRC the current approach is to make nouveau and device link work.
I don't have the full context of this discussion, but the kernel force-enables the HDA subfunction nowadays, irrespective of nouveau or nvidia or whatever:
That's the problem.
The nvidia HDA controller on the affected system only gets its power after HDMI cable plugged, so the probe on boot fails.
Kai-Heng
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
Cheers,
-ilia
On Tue, Dec 22, 2020 at 3:50 AM Kai-Heng Feng kai.heng.feng@canonical.com wrote:
On Tue, Dec 22, 2020 at 1:56 AM Ilia Mirkin imirkin@alum.mit.edu wrote:
On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng kai.heng.feng@canonical.com wrote:
[+Cc nouveau]
On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai tiwai@suse.de wrote: [snip]
Quite possibly the system doesn't power up HDA controller when there's no external monitor. So when it's connected to external monitor, it's still needed for HDMI audio. Let me ask the user to confirm this.
Yeah, it's the basic question whether the HD-audio is supposed to work on this machine at all. If yes, the current approach we take makes less sense - instead we should rather make the HD-audio controller working.
Yea, confirmed that the Nvidia HDA works when HDMI is connected prior boot.
- The second problem is that pci_enable_device() ignores the error returned from pci_set_power_state() if it's -EIO. And the inaccessible access error returns -EIO, although it's rather a fatal problem. So the driver believes as the PCI device gets enabled properly.
This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix regression in pci_enable_device_bars") to fix UHCI controller.
- The third problem is that HD-audio driver blindly believes the codec_mask read from the register even if it's a read failure as I already showed.
This approach has least regression risk.
Yes, but it assumes that HD-audio is really non-existent.
I really don't know any good approach to address this. On Windows, HDA PCI is "hidden" until HDMI cable is plugged, then the driver will flag the magic bit to make HDA audio appear on the PCI bus. IIRC the current approach is to make nouveau and device link work.
I don't have the full context of this discussion, but the kernel force-enables the HDA subfunction nowadays, irrespective of nouveau or nvidia or whatever:
That's the problem.
The nvidia HDA controller on the affected system only gets its power after HDMI cable plugged, so the probe on boot fails.
it might be that the code to enable the sub function is a bit broken :/ but it should work. Maybe the quirk_nvidia_hda function needs to be called on more occasions? No idea.
Kai-Heng
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
Cheers,
-ilia
Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Reviving this thread as we have another user (rightfully) complaining on IRC about this.
The way I see it there's two issues: 1) snd_hda_intel not allowing runpm (or w/e vgaswitcheroo needs) when there's missing codecs, inhibiting the entire GPU from performing runpm. This needlessly wastes lots of battery power. 2) HDMI audio not working on such machines unless it was plugged in at boot-time.
The original workarounds proposed by Kai-Heng seem to fix 1), which is progress. I don't see a reason why that should be held off even if it doesn't fix 2). To fix 2), more work is needed. On a high level, I suspect nouveau should start controlling the enabling/disabling of the HDA controller based on connector events and/or connector state at module load. Currently the PCI quirk seems to enable it wholesale, and I don't know why. If no GPU driver is loaded, it's pointless to turn the HDA device on. The blob presumably doesn't need this either, as it can control the device just as well as nouveau. If it doesn't, NVIDIA should fix it rather than rely on this quirk. The only reason I can think of is that snd_hda_intel or vgaswitcheroo isn't prepared for hot(un)plugging (or alternatively reprobing) devices. Without that, we presumably won't solve issue 2). Can I ask someone with more technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about the possible challenges of nouveau taking matters into its own hand rather than keeping this PCI quirk around?
Roy
Op 04-01-2021 om 13:20 schreef Karol Herbst:
On Tue, Dec 22, 2020 at 3:50 AM Kai-Heng Feng kai.heng.feng@canonical.com wrote:
On Tue, Dec 22, 2020 at 1:56 AM Ilia Mirkin imirkin@alum.mit.edu wrote:
On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng kai.heng.feng@canonical.com wrote:
[+Cc nouveau]
On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai tiwai@suse.de wrote: [snip]
Quite possibly the system doesn't power up HDA controller when there's no external monitor. So when it's connected to external monitor, it's still needed for HDMI audio. Let me ask the user to confirm this.
Yeah, it's the basic question whether the HD-audio is supposed to work on this machine at all. If yes, the current approach we take makes less sense - instead we should rather make the HD-audio controller working.
Yea, confirmed that the Nvidia HDA works when HDMI is connected prior boot.
> - The second problem is that pci_enable_device() ignores the error > returned from pci_set_power_state() if it's -EIO. And the > inaccessible access error returns -EIO, although it's rather a fatal > problem. So the driver believes as the PCI device gets enabled > properly.
This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix regression in pci_enable_device_bars") to fix UHCI controller.
> > - The third problem is that HD-audio driver blindly believes the > codec_mask read from the register even if it's a read failure as I > already showed.
This approach has least regression risk.
Yes, but it assumes that HD-audio is really non-existent.
I really don't know any good approach to address this. On Windows, HDA PCI is "hidden" until HDMI cable is plugged, then the driver will flag the magic bit to make HDA audio appear on the PCI bus. IIRC the current approach is to make nouveau and device link work.
I don't have the full context of this discussion, but the kernel force-enables the HDA subfunction nowadays, irrespective of nouveau or nvidia or whatever:
That's the problem.
The nvidia HDA controller on the affected system only gets its power after HDMI cable plugged, so the probe on boot fails.
it might be that the code to enable the sub function is a bit broken :/ but it should work. Maybe the quirk_nvidia_hda function needs to be called on more occasions? No idea.
Kai-Heng
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
Cheers,
-ilia
Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
Can I ask someone with more technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about the possible challenges of nouveau taking matters into its own hand rather than keeping this PCI quirk around?
It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS?
Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit.
Thanks,
Lukas
Op 10-04-2021 om 20:23 schreef Lukas Wunner:
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
Can I ask someone with more technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about the possible challenges of nouveau taking matters into its own hand rather than keeping this PCI quirk around?
It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS?
Sometimes the BIOS, but definitely unconditionally the PCI quirk code: https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
(CC Aaron Plattner)
Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit.
Thanks,
Lukas
On 4/10/21 1:48 PM, Roy Spliet wrote:
Op 10-04-2021 om 20:23 schreef Lukas Wunner:
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
Can I ask someone with more technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about the possible challenges of nouveau taking matters into its own hand rather than keeping this PCI quirk around?
It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS?
Sometimes the BIOS, but definitely unconditionally the PCI quirk code: https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
(CC Aaron Plattner)
My basic understanding is that the audio function stops responding whenever the graphics function is powered off. So the requirement here is that the audio driver can't try to talk to the audio function while the graphics function is asleep, and must trigger a graphics function wakeup before trying to communicate with the audio function. I think there are also requirements about the audio function needing to be awake when the graphics driver is updating the ELD, but I'm not sure.
This is harder on Windows because the audio driver lives in its own little world doing its own thing but on Linux we can do better.
Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit.
After system boot, I don't think there's any firmware involved, but I'm not super familiar with the low-level details and it's possible the situation changed since I last looked at it.
I think the problem with having nouveau write this quirk is that the kernel will need to re-probe the PCI device to notice that it has suddenly become a multi-function device with an audio function, and hotplug the audio driver. I originally looked into trying to do that but it was tricky because the PCI subsystem didn't really have a mechanism for a single-function device to become a multi-function device on the fly and it seemed easier to enable it early on during bus enumeration. That way the kernel sees both functions all the time without anything else having to be special about this configuration.
-- Aaron
Thanks,
Lukas
Hello Aaron,
Thanks for your insights. A follow-up query and some observations in-line.
Op 12-04-2021 om 20:06 schreef Aaron Plattner:
On 4/10/21 1:48 PM, Roy Spliet wrote:
Op 10-04-2021 om 20:23 schreef Lukas Wunner:
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
Can I ask someone with more technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about the possible challenges of nouveau taking matters into its own hand rather than keeping this PCI quirk around?
It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS?
Sometimes the BIOS, but definitely unconditionally the PCI quirk code: https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
(CC Aaron Plattner)
My basic understanding is that the audio function stops responding whenever the graphics function is powered off. So the requirement here is that the audio driver can't try to talk to the audio function while the graphics function is asleep, and must trigger a graphics function wakeup before trying to communicate with the audio function.
I believe that vgaswitcheroo takes care of this for us.
I think there are also requirements about the audio function needing to be awake when the graphics driver is updating the ELD, but I'm not sure.
This is harder on Windows because the audio driver lives in its own little world doing its own thing but on Linux we can do better.
Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit.
After system boot, I don't think there's any firmware involved, but I'm not super familiar with the low-level details and it's possible the situation changed since I last looked at it.
I think the problem with having nouveau write this quirk is that the kernel will need to re-probe the PCI device to notice that it has suddenly become a multi-function device with an audio function, and hotplug the audio driver. I originally looked into trying to do that but it was tricky because the PCI subsystem didn't really have a mechanism for a single-function device to become a multi-function device on the fly and it seemed easier to enable it early on during bus enumeration. That way the kernel sees both functions all the time without anything else having to be special about this configuration.
Right, so for a little more context: a while ago I noticed that my laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems legit, given how this GPU has no displays attached; they're all hooked up to the Intel integrated GPU. That threw off the snd_hda_intel mid-probe, and as a result didn't permit runpm, keeping the entire GPU, PCIe bus and thus the CPU package awake. A bit of hackerly later we decided to continue probing without a codec, and now my laptop is happy, but... A new problem popped up with several other NVIDIA GPUs that expose their HDA subdevice, but somehow its inaccessible. Relevant lines from a users' log:
[ 3.031222] MXM: GUID detected in BIOS [ 3.031280] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031352] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031419] ACPI: _SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b) [ 3.031424] ACPI Warning: _SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 3.031619] pci 0000:00:02.0: optimus capabilities: enabled, status dynamic power, [ 3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031731] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031791] ACPI Error: Aborting method _SB.PCI0.PEG0.PEGP._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031856] ACPI: _SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b) [ 3.031859] ACPI Warning: _SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 3.032058] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, [ 3.032061] VGA switcheroo: detected Optimus DSM method _SB_.PCI0.PEG0.PEGP handle [ 3.032323] checking generic (d0000000 410000) vs hw (f6000000 1000000) [ 3.032325] checking generic (d0000000 410000) vs hw (e0000000 10000000) [ 3.032326] checking generic (d0000000 410000) vs hw (f0000000 2000000) [ 3.032410] nouveau 0000:01:00.0: NVIDIA GK107 (0e71f0a2) [ 3.042385] nouveau 0000:01:00.0: bios: version 80.07.a0.00.11 --- snip --- [ 8.951478] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 8.951509] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible) [ 8.951608] snd_hda_intel 0000:01:00.1: Disabling MSI [ 8.951621] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 8.952461] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 8.952642] snd_hda_intel 0000:01:00.1: number of I/O streams is 30, forcing separate stream tags
Now I don't know what's going on, but the snd_hda_intel messages are ominous. And so are the ACPI warnings. But I don't know how much these two are related.
You say that it is desirable to switch on HDA at boot-time because the PCI subsystem doesn't play nicely with changing a device to multi-function. That rules out the option of only enabling the HDA device once a cable is plugged in. Are there any other trap doors that snd_hda_intel needs to navigate around to make this work fault free on all hardware, such as: - Codecs not revealing themselves until a display is plugged in, requiring perhaps a "codec reprobe" and "codec remove" event from nouveau/rm to snd_hda_intel, - Borked BIOSes just blindly assigning the MMIO space of the HDA device to another device, or nothing at all, - ... other things that might give any of us nightmares and heart burn?
Thanks!
Roy
-- Aaron
Thanks,
Lukas
On 4/12/21 12:36 PM, Roy Spliet wrote:
Hello Aaron,
Thanks for your insights. A follow-up query and some observations in-line.
Op 12-04-2021 om 20:06 schreef Aaron Plattner:
On 4/10/21 1:48 PM, Roy Spliet wrote:
Op 10-04-2021 om 20:23 schreef Lukas Wunner:
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
Can I ask someone with more technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about the possible challenges of nouveau taking matters into its own hand rather than keeping this PCI quirk around?
It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS?
Sometimes the BIOS, but definitely unconditionally the PCI quirk code: https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
(CC Aaron Plattner)
My basic understanding is that the audio function stops responding whenever the graphics function is powered off. So the requirement here is that the audio driver can't try to talk to the audio function while the graphics function is asleep, and must trigger a graphics function wakeup before trying to communicate with the audio function.
I believe that vgaswitcheroo takes care of this for us.
I think there are also requirements about the audio function needing to be awake when the graphics driver is updating the ELD, but I'm not sure.
This is harder on Windows because the audio driver lives in its own little world doing its own thing but on Linux we can do better.
Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit.
After system boot, I don't think there's any firmware involved, but I'm not super familiar with the low-level details and it's possible the situation changed since I last looked at it.
I think the problem with having nouveau write this quirk is that the kernel will need to re-probe the PCI device to notice that it has suddenly become a multi-function device with an audio function, and hotplug the audio driver. I originally looked into trying to do that but it was tricky because the PCI subsystem didn't really have a mechanism for a single-function device to become a multi-function device on the fly and it seemed easier to enable it early on during bus enumeration. That way the kernel sees both functions all the time without anything else having to be special about this configuration.
Right, so for a little more context: a while ago I noticed that my laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems legit, given how this GPU has no displays attached; they're all hooked up to the Intel integrated GPU. That threw off the snd_hda_intel mid-probe, and as a result didn't permit runpm, keeping the entire GPU, PCIe bus and thus the CPU package awake. A bit of hackerly later we decided to continue probing without a codec, and now my laptop is happy, but...
What is the PCI class of the GPU in your system? If it has no display outputs it's probably 0x302 ("3D Controller") rather than 0x300 ("VGA Controller"). Looking at the code it looks like this workaround is being applied to both but maybe it should be restricted to just VGA controllers.
-- Aaron
A new problem popped up with several other NVIDIA GPUs that expose their HDA subdevice, but somehow its inaccessible. Relevant lines from a users' log:
[ 3.031222] MXM: GUID detected in BIOS [ 3.031280] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031352] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031419] ACPI: _SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b) [ 3.031424] ACPI Warning: _SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 3.031619] pci 0000:00:02.0: optimus capabilities: enabled, status dynamic power, [ 3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031731] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031791] ACPI Error: Aborting method _SB.PCI0.PEG0.PEGP._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031856] ACPI: _SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b) [ 3.031859] ACPI Warning: _SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 3.032058] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, [ 3.032061] VGA switcheroo: detected Optimus DSM method _SB_.PCI0.PEG0.PEGP handle [ 3.032323] checking generic (d0000000 410000) vs hw (f6000000 1000000) [ 3.032325] checking generic (d0000000 410000) vs hw (e0000000 10000000) [ 3.032326] checking generic (d0000000 410000) vs hw (f0000000 2000000) [ 3.032410] nouveau 0000:01:00.0: NVIDIA GK107 (0e71f0a2) [ 3.042385] nouveau 0000:01:00.0: bios: version 80.07.a0.00.11 --- snip --- [ 8.951478] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 8.951509] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible) [ 8.951608] snd_hda_intel 0000:01:00.1: Disabling MSI [ 8.951621] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 8.952461] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 8.952642] snd_hda_intel 0000:01:00.1: number of I/O streams is 30, forcing separate stream tags
Now I don't know what's going on, but the snd_hda_intel messages are ominous. And so are the ACPI warnings. But I don't know how much these two are related.
You say that it is desirable to switch on HDA at boot-time because the PCI subsystem doesn't play nicely with changing a device to multi-function. That rules out the option of only enabling the HDA device once a cable is plugged in. Are there any other trap doors that snd_hda_intel needs to navigate around to make this work fault free on all hardware, such as:
- Codecs not revealing themselves until a display is plugged in,
requiring perhaps a "codec reprobe" and "codec remove" event from nouveau/rm to snd_hda_intel,
- Borked BIOSes just blindly assigning the MMIO space of the HDA
device to another device, or nothing at all,
- ... other things that might give any of us nightmares and heart burn?
Thanks!
Roy
-- Aaron
Thanks,
Lukas
On Mon, Apr 12, 2021 at 4:01 PM Aaron Plattner aplattner@nvidia.com wrote:
On 4/12/21 12:36 PM, Roy Spliet wrote:
Hello Aaron,
Thanks for your insights. A follow-up query and some observations in-line.
Op 12-04-2021 om 20:06 schreef Aaron Plattner:
On 4/10/21 1:48 PM, Roy Spliet wrote:
Op 10-04-2021 om 20:23 schreef Lukas Wunner:
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
Can I ask someone with more technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about the possible challenges of nouveau taking matters into its own hand rather than keeping this PCI quirk around?
It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS?
Sometimes the BIOS, but definitely unconditionally the PCI quirk code: https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
(CC Aaron Plattner)
My basic understanding is that the audio function stops responding whenever the graphics function is powered off. So the requirement here is that the audio driver can't try to talk to the audio function while the graphics function is asleep, and must trigger a graphics function wakeup before trying to communicate with the audio function.
I believe that vgaswitcheroo takes care of this for us.
I think there are also requirements about the audio function needing to be awake when the graphics driver is updating the ELD, but I'm not sure.
This is harder on Windows because the audio driver lives in its own little world doing its own thing but on Linux we can do better.
Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit.
After system boot, I don't think there's any firmware involved, but I'm not super familiar with the low-level details and it's possible the situation changed since I last looked at it.
I think the problem with having nouveau write this quirk is that the kernel will need to re-probe the PCI device to notice that it has suddenly become a multi-function device with an audio function, and hotplug the audio driver. I originally looked into trying to do that but it was tricky because the PCI subsystem didn't really have a mechanism for a single-function device to become a multi-function device on the fly and it seemed easier to enable it early on during bus enumeration. That way the kernel sees both functions all the time without anything else having to be special about this configuration.
Right, so for a little more context: a while ago I noticed that my laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems legit, given how this GPU has no displays attached; they're all hooked up to the Intel integrated GPU. That threw off the snd_hda_intel mid-probe, and as a result didn't permit runpm, keeping the entire GPU, PCIe bus and thus the CPU package awake. A bit of hackerly later we decided to continue probing without a codec, and now my laptop is happy, but...
What is the PCI class of the GPU in your system? If it has no display outputs it's probably 0x302 ("3D Controller") rather than 0x300 ("VGA Controller"). Looking at the code it looks like this workaround is being applied to both but maybe it should be restricted to just VGA controllers.
That was a comment I had back when the quirk was being implemented, but helpfully there are some of these devices running around which say "3D Controller" but still have displays attached to them. Lukas probably remembers more specifics.
-ilia
On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet nouveau@spliet.org wrote:
Hello Aaron,
Thanks for your insights. A follow-up query and some observations in-line.
Op 12-04-2021 om 20:06 schreef Aaron Plattner:
On 4/10/21 1:48 PM, Roy Spliet wrote:
Op 10-04-2021 om 20:23 schreef Lukas Wunner:
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
Can I ask someone with more technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about the possible challenges of nouveau taking matters into its own hand rather than keeping this PCI quirk around?
It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS?
Sometimes the BIOS, but definitely unconditionally the PCI quirk code: https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
(CC Aaron Plattner)
My basic understanding is that the audio function stops responding whenever the graphics function is powered off. So the requirement here is that the audio driver can't try to talk to the audio function while the graphics function is asleep, and must trigger a graphics function wakeup before trying to communicate with the audio function.
I believe that vgaswitcheroo takes care of this for us.
yeah, and also: why would the driver want to do stuff? If the GPU is turned off, there is no point in communicating with the audio device anyway. The driver should do the initial probe and leave the device be unless it's actively used. Also there is no such thing as "use the audio function, but not the graphics one"
I think there are also requirements about the audio function needing to be awake when the graphics driver is updating the ELD, but I'm not sure.
well, it's one physical device anyway, so technically the audio function is powered on.
This is harder on Windows because the audio driver lives in its own little world doing its own thing but on Linux we can do better.
Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit.
After system boot, I don't think there's any firmware involved, but I'm not super familiar with the low-level details and it's possible the situation changed since I last looked at it.
I think the problem with having nouveau write this quirk is that the kernel will need to re-probe the PCI device to notice that it has suddenly become a multi-function device with an audio function, and hotplug the audio driver. I originally looked into trying to do that but it was tricky because the PCI subsystem didn't really have a mechanism for a single-function device to become a multi-function device on the fly and it seemed easier to enable it early on during bus enumeration. That way the kernel sees both functions all the time without anything else having to be special about this configuration.
Well, we do have this pci/quirk.c thing, no? Nouveau does flip the bit, but I am actually not sure if that's even doing something anymore. Maybe in the runtime_resume case it's still relevant but not sure _when_ DECLARE_PCI_FIXUP_CLASS_RESUME_EARLY is triggered, it does seem to be called even in the runtime_resume case though.
Right, so for a little more context: a while ago I noticed that my laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems legit, given how this GPU has no displays attached; they're all hooked up to the Intel integrated GPU. That threw off the snd_hda_intel mid-probe, and as a result didn't permit runpm, keeping the entire GPU, PCIe bus and thus the CPU package awake. A bit of hackerly later we decided to continue probing without a codec, and now my laptop is happy, but... A new problem popped up with several other NVIDIA GPUs that expose their HDA subdevice, but somehow its inaccessible. Relevant lines from a users' log:
[ 3.031222] MXM: GUID detected in BIOS [ 3.031280] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031352] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031419] ACPI: _SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b) [ 3.031424] ACPI Warning: _SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 3.031619] pci 0000:00:02.0: optimus capabilities: enabled, status dynamic power, [ 3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031731] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031791] ACPI Error: Aborting method _SB.PCI0.PEG0.PEGP._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031856] ACPI: _SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b) [ 3.031859] ACPI Warning: _SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61)
If I am not wrong we are calling the _DSM method inside nouveau when doing runpm on pre _PR3 systems. As this is all very vendor specific, we might be doing something incorrectly.
[ 3.032058] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, [ 3.032061] VGA switcheroo: detected Optimus DSM method _SB_.PCI0.PEG0.PEGP handle [ 3.032323] checking generic (d0000000 410000) vs hw (f6000000 1000000) [ 3.032325] checking generic (d0000000 410000) vs hw (e0000000 10000000) [ 3.032326] checking generic (d0000000 410000) vs hw (f0000000 2000000) [ 3.032410] nouveau 0000:01:00.0: NVIDIA GK107 (0e71f0a2) [ 3.042385] nouveau 0000:01:00.0: bios: version 80.07.a0.00.11 --- snip --- [ 8.951478] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 8.951509] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible)
This is actually a little bad, because it means that the device doesn't come back up from D3. It's a bit weird it's D3cold and D3hot in the messages, but maybe the device just takes quite some time to wake up. But it does look like the device gets woken up.
[ 8.951608] snd_hda_intel 0000:01:00.1: Disabling MSI [ 8.951621] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 8.952461] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 8.952642] snd_hda_intel 0000:01:00.1: number of I/O streams is 30, forcing separate stream tags
Now I don't know what's going on, but the snd_hda_intel messages are ominous. And so are the ACPI warnings. But I don't know how much these two are related.
What is the actual problem though? Seems like everything is fine despite those messages.
You say that it is desirable to switch on HDA at boot-time because the PCI subsystem doesn't play nicely with changing a device to multi-function. That rules out the option of only enabling the HDA device once a cable is plugged in. Are there any other trap doors that
yeah, we can absolutely not do that. We do quirk the device to put the GPU into multi function state asap and the intel_hda_snd driver should deal with it.
snd_hda_intel needs to navigate around to make this work fault free on all hardware, such as:
- Codecs not revealing themselves until a display is plugged in,
requiring perhaps a "codec reprobe" and "codec remove" event from nouveau/rm to snd_hda_intel,
we could trigger the reprobe from within nouveau as we are dealing with display hotplug events anyway.
- Borked BIOSes just blindly assigning the MMIO space of the HDA device
to another device, or nothing at all,
that exists? *sigh*
- ... other things that might give any of us nightmares and heart burn?
hopefully there are none :p
Thanks!
Roy
-- Aaron
Thanks,
Lukas
Op 13-04-2021 om 01:10 schreef Karol Herbst:
On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet nouveau@spliet.org wrote:
Hello Aaron,
Thanks for your insights. A follow-up query and some observations in-line.
Op 12-04-2021 om 20:06 schreef Aaron Plattner:
On 4/10/21 1:48 PM, Roy Spliet wrote:
Op 10-04-2021 om 20:23 schreef Lukas Wunner:
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
Can I ask someone with more technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about the possible challenges of nouveau taking matters into its own hand rather than keeping this PCI quirk around?
It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS?
Sometimes the BIOS, but definitely unconditionally the PCI quirk code: https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
(CC Aaron Plattner)
My basic understanding is that the audio function stops responding whenever the graphics function is powered off. So the requirement here is that the audio driver can't try to talk to the audio function while the graphics function is asleep, and must trigger a graphics function wakeup before trying to communicate with the audio function.
I believe that vgaswitcheroo takes care of this for us.
yeah, and also: why would the driver want to do stuff? If the GPU is turned off, there is no point in communicating with the audio device anyway. The driver should do the initial probe and leave the device be unless it's actively used. Also there is no such thing as "use the audio function, but not the graphics one"
I think there are also requirements about the audio function needing to be awake when the graphics driver is updating the ELD, but I'm not sure.
well, it's one physical device anyway, so technically the audio function is powered on.
This is harder on Windows because the audio driver lives in its own little world doing its own thing but on Linux we can do better.
Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit.
After system boot, I don't think there's any firmware involved, but I'm not super familiar with the low-level details and it's possible the situation changed since I last looked at it.
I think the problem with having nouveau write this quirk is that the kernel will need to re-probe the PCI device to notice that it has suddenly become a multi-function device with an audio function, and hotplug the audio driver. I originally looked into trying to do that but it was tricky because the PCI subsystem didn't really have a mechanism for a single-function device to become a multi-function device on the fly and it seemed easier to enable it early on during bus enumeration. That way the kernel sees both functions all the time without anything else having to be special about this configuration.
Well, we do have this pci/quirk.c thing, no? Nouveau does flip the bit, but I am actually not sure if that's even doing something anymore. Maybe in the runtime_resume case it's still relevant but not sure _when_ DECLARE_PCI_FIXUP_CLASS_RESUME_EARLY is triggered, it does seem to be called even in the runtime_resume case though.
Right, so for a little more context: a while ago I noticed that my laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems legit, given how this GPU has no displays attached; they're all hooked up to the Intel integrated GPU. That threw off the snd_hda_intel mid-probe, and as a result didn't permit runpm, keeping the entire GPU, PCIe bus and thus the CPU package awake. A bit of hackerly later we decided to continue probing without a codec, and now my laptop is happy, but... A new problem popped up with several other NVIDIA GPUs that expose their HDA subdevice, but somehow its inaccessible. Relevant lines from a users' log:
[ 3.031222] MXM: GUID detected in BIOS [ 3.031280] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031352] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031419] ACPI: _SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b) [ 3.031424] ACPI Warning: _SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 3.031619] pci 0000:00:02.0: optimus capabilities: enabled, status dynamic power, [ 3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031731] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031791] ACPI Error: Aborting method _SB.PCI0.PEG0.PEGP._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031856] ACPI: _SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b) [ 3.031859] ACPI Warning: _SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61)
If I am not wrong we are calling the _DSM method inside nouveau when doing runpm on pre _PR3 systems. As this is all very vendor specific, we might be doing something incorrectly.
[ 3.032058] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, [ 3.032061] VGA switcheroo: detected Optimus DSM method _SB_.PCI0.PEG0.PEGP handle [ 3.032323] checking generic (d0000000 410000) vs hw (f6000000 1000000) [ 3.032325] checking generic (d0000000 410000) vs hw (e0000000 10000000) [ 3.032326] checking generic (d0000000 410000) vs hw (f0000000 2000000) [ 3.032410] nouveau 0000:01:00.0: NVIDIA GK107 (0e71f0a2) [ 3.042385] nouveau 0000:01:00.0: bios: version 80.07.a0.00.11 --- snip --- [ 8.951478] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 8.951509] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible)
This is actually a little bad, because it means that the device doesn't come back up from D3. It's a bit weird it's D3cold and D3hot in the messages, but maybe the device just takes quite some time to wake up. But it does look like the device gets woken up.
[ 8.951608] snd_hda_intel 0000:01:00.1: Disabling MSI [ 8.951621] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 8.952461] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 8.952642] snd_hda_intel 0000:01:00.1: number of I/O streams is 30, forcing separate stream tags
Now I don't know what's going on, but the snd_hda_intel messages are ominous. And so are the ACPI warnings. But I don't know how much these two are related.
What is the actual problem though? Seems like everything is fine despite those messages.
The problem, as stated a few e-mails earlier, is that the HDA errors currently prevent snd_hda_intel from properly probing the device and registering it with vgaswitcheroo. As a result, the GPU always stays in DynPwr rather than DynOff even when it's unused, keeping the PCIe bus and the CPU package powered. Basically burning through a charged battery a lot quicker than need be. If we go back a mile on the e-mail thread, I think the problem was narrowed down to snd_hda_intel reading an invalid codec mask on the config space, and using it anyway. That being said, I believe there are also reports of users that don't get HDMI audio unless the cable was plugged in at boot-time, with similar messages in their logs. The codec might in such cases be hiding themselves until a cable is plugged in? @Aaron Plattner: does that latter observation sound right to you?
You say that it is desirable to switch on HDA at boot-time because the PCI subsystem doesn't play nicely with changing a device to multi-function. That rules out the option of only enabling the HDA device once a cable is plugged in. Are there any other trap doors that
yeah, we can absolutely not do that. We do quirk the device to put the GPU into multi function state asap and the intel_hda_snd driver should deal with it.
snd_hda_intel needs to navigate around to make this work fault free on all hardware, such as:
- Codecs not revealing themselves until a display is plugged in,
requiring perhaps a "codec reprobe" and "codec remove" event from nouveau/rm to snd_hda_intel,
we could trigger the reprobe from within nouveau as we are dealing with display hotplug events anyway.
Right. Are there situations where nouveau needs to? Or is this a misunderstanding of the problem from my end?
- Borked BIOSes just blindly assigning the MMIO space of the HDA device
to another device, or nothing at all,
that exists? *sigh*
- ... other things that might give any of us nightmares and heart burn?
hopefully there are none :p
Thanks!
Roy
-- Aaron
Thanks,
Lukas
On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet nouveau@spliet.org wrote:
Op 13-04-2021 om 01:10 schreef Karol Herbst:
On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet nouveau@spliet.org wrote:
Hello Aaron,
Thanks for your insights. A follow-up query and some observations in-line.
Op 12-04-2021 om 20:06 schreef Aaron Plattner:
On 4/10/21 1:48 PM, Roy Spliet wrote:
Op 10-04-2021 om 20:23 schreef Lukas Wunner:
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote: > Can I ask someone with more > technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm > about > the possible challenges of nouveau taking matters into its own hand > rather > than keeping this PCI quirk around?
It sounds to me like the HDA is not powered if no cable is plugged in. What is reponsible then for powering it up or down, firmware code on the GPU or in the host's BIOS?
Sometimes the BIOS, but definitely unconditionally the PCI quirk code: https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
(CC Aaron Plattner)
My basic understanding is that the audio function stops responding whenever the graphics function is powered off. So the requirement here is that the audio driver can't try to talk to the audio function while the graphics function is asleep, and must trigger a graphics function wakeup before trying to communicate with the audio function.
I believe that vgaswitcheroo takes care of this for us.
yeah, and also: why would the driver want to do stuff? If the GPU is turned off, there is no point in communicating with the audio device anyway. The driver should do the initial probe and leave the device be unless it's actively used. Also there is no such thing as "use the audio function, but not the graphics one"
I think there are also requirements about the audio function needing to be awake when the graphics driver is updating the ELD, but I'm not sure.
well, it's one physical device anyway, so technically the audio function is powered on.
This is harder on Windows because the audio driver lives in its own little world doing its own thing but on Linux we can do better.
Ideally, we should try to find out how to control HDA power from the operating system rather than trying to cooperate with whatever firmware is doing. If we have that capability, the OS should power the HDA up and down as it sees fit.
After system boot, I don't think there's any firmware involved, but I'm not super familiar with the low-level details and it's possible the situation changed since I last looked at it.
I think the problem with having nouveau write this quirk is that the kernel will need to re-probe the PCI device to notice that it has suddenly become a multi-function device with an audio function, and hotplug the audio driver. I originally looked into trying to do that but it was tricky because the PCI subsystem didn't really have a mechanism for a single-function device to become a multi-function device on the fly and it seemed easier to enable it early on during bus enumeration. That way the kernel sees both functions all the time without anything else having to be special about this configuration.
Well, we do have this pci/quirk.c thing, no? Nouveau does flip the bit, but I am actually not sure if that's even doing something anymore. Maybe in the runtime_resume case it's still relevant but not sure _when_ DECLARE_PCI_FIXUP_CLASS_RESUME_EARLY is triggered, it does seem to be called even in the runtime_resume case though.
Right, so for a little more context: a while ago I noticed that my laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems legit, given how this GPU has no displays attached; they're all hooked up to the Intel integrated GPU. That threw off the snd_hda_intel mid-probe, and as a result didn't permit runpm, keeping the entire GPU, PCIe bus and thus the CPU package awake. A bit of hackerly later we decided to continue probing without a codec, and now my laptop is happy, but... A new problem popped up with several other NVIDIA GPUs that expose their HDA subdevice, but somehow its inaccessible. Relevant lines from a users' log:
[ 3.031222] MXM: GUID detected in BIOS [ 3.031280] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031352] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031419] ACPI: _SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b) [ 3.031424] ACPI Warning: _SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 3.031619] pci 0000:00:02.0: optimus capabilities: enabled, status dynamic power, [ 3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031731] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031791] ACPI Error: Aborting method _SB.PCI0.PEG0.PEGP._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031856] ACPI: _SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b) [ 3.031859] ACPI Warning: _SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61)
If I am not wrong we are calling the _DSM method inside nouveau when doing runpm on pre _PR3 systems. As this is all very vendor specific, we might be doing something incorrectly.
[ 3.032058] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, [ 3.032061] VGA switcheroo: detected Optimus DSM method _SB_.PCI0.PEG0.PEGP handle [ 3.032323] checking generic (d0000000 410000) vs hw (f6000000 1000000) [ 3.032325] checking generic (d0000000 410000) vs hw (e0000000 10000000) [ 3.032326] checking generic (d0000000 410000) vs hw (f0000000 2000000) [ 3.032410] nouveau 0000:01:00.0: NVIDIA GK107 (0e71f0a2) [ 3.042385] nouveau 0000:01:00.0: bios: version 80.07.a0.00.11 --- snip --- [ 8.951478] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 8.951509] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible)
This is actually a little bad, because it means that the device doesn't come back up from D3. It's a bit weird it's D3cold and D3hot in the messages, but maybe the device just takes quite some time to wake up. But it does look like the device gets woken up.
[ 8.951608] snd_hda_intel 0000:01:00.1: Disabling MSI [ 8.951621] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 8.952461] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 8.952642] snd_hda_intel 0000:01:00.1: number of I/O streams is 30, forcing separate stream tags
Now I don't know what's going on, but the snd_hda_intel messages are ominous. And so are the ACPI warnings. But I don't know how much these two are related.
What is the actual problem though? Seems like everything is fine despite those messages.
The problem, as stated a few e-mails earlier, is that the HDA errors currently prevent snd_hda_intel from properly probing the device and registering it with vgaswitcheroo. As a result, the GPU always stays in DynPwr rather than DynOff even when it's unused, keeping the PCIe bus and the CPU package powered. Basically burning through a charged battery a lot quicker than need be.
That's not the result of those errors, just the result of having no codecs, no?
If we go back a mile on the e-mail thread, I think the problem was narrowed down to snd_hda_intel reading an invalid codec mask on the config space, and using it anyway. That being said, I believe there are also reports of users that don't get HDMI audio unless the cable was plugged in at boot-time, with similar messages in their logs. The codec might in such cases be hiding themselves until a cable is plugged in? @Aaron Plattner: does that latter observation sound right to you?
yeah, I think that's the thing we should focus on, everything else just seems unrelated at this point until we have more information (like, codecs hide, because the _DSM calls failed or something)
You say that it is desirable to switch on HDA at boot-time because the PCI subsystem doesn't play nicely with changing a device to multi-function. That rules out the option of only enabling the HDA device once a cable is plugged in. Are there any other trap doors that
yeah, we can absolutely not do that. We do quirk the device to put the GPU into multi function state asap and the intel_hda_snd driver should deal with it.
snd_hda_intel needs to navigate around to make this work fault free on all hardware, such as:
- Codecs not revealing themselves until a display is plugged in,
requiring perhaps a "codec reprobe" and "codec remove" event from nouveau/rm to snd_hda_intel,
we could trigger the reprobe from within nouveau as we are dealing with display hotplug events anyway.
Right. Are there situations where nouveau needs to? Or is this a misunderstanding of the problem from my end?
nouveau has to do some configuration anyway, like connecting the audio stream with the port used etc...that's the ELD part. We have some drm_audio bits though, so maybe we can solve this more general and maybe the radeon drivers already have something here? Might be worth to take a look there as well.
- Borked BIOSes just blindly assigning the MMIO space of the HDA device
to another device, or nothing at all,
that exists? *sigh*
- ... other things that might give any of us nightmares and heart burn?
hopefully there are none :p
Thanks!
Roy
-- Aaron
Thanks,
Lukas
Op 13-04-2021 om 10:48 schreef Karol Herbst:
On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet nouveau@spliet.org wrote:
Op 13-04-2021 om 01:10 schreef Karol Herbst:
On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet nouveau@spliet.org wrote:
Hello Aaron,
Thanks for your insights. A follow-up query and some observations in-line.
Op 12-04-2021 om 20:06 schreef Aaron Plattner:
On 4/10/21 1:48 PM, Roy Spliet wrote:
Op 10-04-2021 om 20:23 schreef Lukas Wunner: > On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote: >> Can I ask someone with more >> technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm >> about >> the possible challenges of nouveau taking matters into its own hand >> rather >> than keeping this PCI quirk around? > > It sounds to me like the HDA is not powered if no cable is plugged in. > What is reponsible then for powering it up or down, firmware code on > the GPU or in the host's BIOS?
Sometimes the BIOS, but definitely unconditionally the PCI quirk code: https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
(CC Aaron Plattner)
My basic understanding is that the audio function stops responding whenever the graphics function is powered off. So the requirement here is that the audio driver can't try to talk to the audio function while the graphics function is asleep, and must trigger a graphics function wakeup before trying to communicate with the audio function.
I believe that vgaswitcheroo takes care of this for us.
yeah, and also: why would the driver want to do stuff? If the GPU is turned off, there is no point in communicating with the audio device anyway. The driver should do the initial probe and leave the device be unless it's actively used. Also there is no such thing as "use the audio function, but not the graphics one"
I think there are also requirements about the audio function needing to be awake when the graphics driver is updating the ELD, but I'm not sure.
well, it's one physical device anyway, so technically the audio function is powered on.
This is harder on Windows because the audio driver lives in its own little world doing its own thing but on Linux we can do better.
> Ideally, we should try to find out how to control HDA power from the > operating system rather than trying to cooperate with whatever firmware > is doing. If we have that capability, the OS should power the HDA up > and down as it sees fit.
After system boot, I don't think there's any firmware involved, but I'm not super familiar with the low-level details and it's possible the situation changed since I last looked at it.
I think the problem with having nouveau write this quirk is that the kernel will need to re-probe the PCI device to notice that it has suddenly become a multi-function device with an audio function, and hotplug the audio driver. I originally looked into trying to do that but it was tricky because the PCI subsystem didn't really have a mechanism for a single-function device to become a multi-function device on the fly and it seemed easier to enable it early on during bus enumeration. That way the kernel sees both functions all the time without anything else having to be special about this configuration.
Well, we do have this pci/quirk.c thing, no? Nouveau does flip the bit, but I am actually not sure if that's even doing something anymore. Maybe in the runtime_resume case it's still relevant but not sure _when_ DECLARE_PCI_FIXUP_CLASS_RESUME_EARLY is triggered, it does seem to be called even in the runtime_resume case though.
Right, so for a little more context: a while ago I noticed that my laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems legit, given how this GPU has no displays attached; they're all hooked up to the Intel integrated GPU. That threw off the snd_hda_intel mid-probe, and as a result didn't permit runpm, keeping the entire GPU, PCIe bus and thus the CPU package awake. A bit of hackerly later we decided to continue probing without a codec, and now my laptop is happy, but... A new problem popped up with several other NVIDIA GPUs that expose their HDA subdevice, but somehow its inaccessible. Relevant lines from a users' log:
[ 3.031222] MXM: GUID detected in BIOS [ 3.031280] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031352] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031419] ACPI: _SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b) [ 3.031424] ACPI Warning: _SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 3.031619] pci 0000:00:02.0: optimus capabilities: enabled, status dynamic power, [ 3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031731] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031791] ACPI Error: Aborting method _SB.PCI0.PEG0.PEGP._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031856] ACPI: _SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b) [ 3.031859] ACPI Warning: _SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61)
If I am not wrong we are calling the _DSM method inside nouveau when doing runpm on pre _PR3 systems. As this is all very vendor specific, we might be doing something incorrectly.
[ 3.032058] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, [ 3.032061] VGA switcheroo: detected Optimus DSM method _SB_.PCI0.PEG0.PEGP handle [ 3.032323] checking generic (d0000000 410000) vs hw (f6000000 1000000) [ 3.032325] checking generic (d0000000 410000) vs hw (e0000000 10000000) [ 3.032326] checking generic (d0000000 410000) vs hw (f0000000 2000000) [ 3.032410] nouveau 0000:01:00.0: NVIDIA GK107 (0e71f0a2) [ 3.042385] nouveau 0000:01:00.0: bios: version 80.07.a0.00.11 --- snip --- [ 8.951478] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 8.951509] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible)
This is actually a little bad, because it means that the device doesn't come back up from D3. It's a bit weird it's D3cold and D3hot in the messages, but maybe the device just takes quite some time to wake up. But it does look like the device gets woken up.
[ 8.951608] snd_hda_intel 0000:01:00.1: Disabling MSI [ 8.951621] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 8.952461] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 8.952642] snd_hda_intel 0000:01:00.1: number of I/O streams is 30, forcing separate stream tags
Now I don't know what's going on, but the snd_hda_intel messages are ominous. And so are the ACPI warnings. But I don't know how much these two are related.
What is the actual problem though? Seems like everything is fine despite those messages.
The problem, as stated a few e-mails earlier, is that the HDA errors currently prevent snd_hda_intel from properly probing the device and registering it with vgaswitcheroo. As a result, the GPU always stays in DynPwr rather than DynOff even when it's unused, keeping the PCIe bus and the CPU package powered. Basically burning through a charged battery a lot quicker than need be.
That's not the result of those errors, just the result of having no codecs, no?
If it was just a case of no codecs, Takashi and my patches from last year would have fixed it. This one seems a bit more hairy.
If we go back a mile on the e-mail thread, I think the problem was narrowed down to snd_hda_intel reading an invalid codec mask on the config space, and using it anyway. That being said, I believe there are also reports of users that don't get HDMI audio unless the cable was plugged in at boot-time, with similar messages in their logs. The codec might in such cases be hiding themselves until a cable is plugged in? @Aaron Plattner: does that latter observation sound right to you?
yeah, I think that's the thing we should focus on, everything else just seems unrelated at this point until we have more information (like, codecs hide, because the _DSM calls failed or something)
Sure, but the option of not exposing the HDA device in the first place had to be explored, even if it just led to rejecting the idea like it seems to have. I'm in favour of pushing forward the original fix that makes snd_hda_intel not fail on reading an invalid codec mask, and have it register the device with vgaswitcheroo so we can send it to DynOff. With the current snd_hda_intel architecture that seems simpler than failing to probe and unmapping the driver from the device. However, the issue of no HDMI sound unless plugged in as boot is/might be related, and needs to be on someone's agenda.
You say that it is desirable to switch on HDA at boot-time because the PCI subsystem doesn't play nicely with changing a device to multi-function. That rules out the option of only enabling the HDA device once a cable is plugged in. Are there any other trap doors that
yeah, we can absolutely not do that. We do quirk the device to put the GPU into multi function state asap and the intel_hda_snd driver should deal with it.
snd_hda_intel needs to navigate around to make this work fault free on all hardware, such as:
- Codecs not revealing themselves until a display is plugged in,
requiring perhaps a "codec reprobe" and "codec remove" event from nouveau/rm to snd_hda_intel,
we could trigger the reprobe from within nouveau as we are dealing with display hotplug events anyway.
Right. Are there situations where nouveau needs to? Or is this a misunderstanding of the problem from my end?
nouveau has to do some configuration anyway, like connecting the audio stream with the port used etc...that's the ELD part. We have some drm_audio bits though, so maybe we can solve this more general and maybe the radeon drivers already have something here? Might be worth to take a look there as well.
- Borked BIOSes just blindly assigning the MMIO space of the HDA device
to another device, or nothing at all,
that exists? *sigh*
- ... other things that might give any of us nightmares and heart burn?
hopefully there are none :p
Thanks!
Roy
-- Aaron
> Thanks, > > Lukas
On Tue, Apr 13, 2021 at 1:17 PM Roy Spliet nouveau@spliet.org wrote:
Op 13-04-2021 om 10:48 schreef Karol Herbst:
On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet nouveau@spliet.org wrote:
Op 13-04-2021 om 01:10 schreef Karol Herbst:
On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet nouveau@spliet.org wrote:
Hello Aaron,
Thanks for your insights. A follow-up query and some observations in-line.
Op 12-04-2021 om 20:06 schreef Aaron Plattner:
On 4/10/21 1:48 PM, Roy Spliet wrote: > Op 10-04-2021 om 20:23 schreef Lukas Wunner: >> On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote: >>> Can I ask someone with more >>> technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm >>> about >>> the possible challenges of nouveau taking matters into its own hand >>> rather >>> than keeping this PCI quirk around? >> >> It sounds to me like the HDA is not powered if no cable is plugged in. >> What is reponsible then for powering it up or down, firmware code on >> the GPU or in the host's BIOS? > > Sometimes the BIOS, but definitely unconditionally the PCI quirk code: > https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289 > > (CC Aaron Plattner)
My basic understanding is that the audio function stops responding whenever the graphics function is powered off. So the requirement here is that the audio driver can't try to talk to the audio function while the graphics function is asleep, and must trigger a graphics function wakeup before trying to communicate with the audio function.
I believe that vgaswitcheroo takes care of this for us.
yeah, and also: why would the driver want to do stuff? If the GPU is turned off, there is no point in communicating with the audio device anyway. The driver should do the initial probe and leave the device be unless it's actively used. Also there is no such thing as "use the audio function, but not the graphics one"
I think there are also requirements about the audio function needing to be awake when the graphics driver is updating the ELD, but I'm not sure.
well, it's one physical device anyway, so technically the audio function is powered on.
This is harder on Windows because the audio driver lives in its own little world doing its own thing but on Linux we can do better.
>> Ideally, we should try to find out how to control HDA power from the >> operating system rather than trying to cooperate with whatever firmware >> is doing. If we have that capability, the OS should power the HDA up >> and down as it sees fit.
After system boot, I don't think there's any firmware involved, but I'm not super familiar with the low-level details and it's possible the situation changed since I last looked at it.
I think the problem with having nouveau write this quirk is that the kernel will need to re-probe the PCI device to notice that it has suddenly become a multi-function device with an audio function, and hotplug the audio driver. I originally looked into trying to do that but it was tricky because the PCI subsystem didn't really have a mechanism for a single-function device to become a multi-function device on the fly and it seemed easier to enable it early on during bus enumeration. That way the kernel sees both functions all the time without anything else having to be special about this configuration.
Well, we do have this pci/quirk.c thing, no? Nouveau does flip the bit, but I am actually not sure if that's even doing something anymore. Maybe in the runtime_resume case it's still relevant but not sure _when_ DECLARE_PCI_FIXUP_CLASS_RESUME_EARLY is triggered, it does seem to be called even in the runtime_resume case though.
Right, so for a little more context: a while ago I noticed that my laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems legit, given how this GPU has no displays attached; they're all hooked up to the Intel integrated GPU. That threw off the snd_hda_intel mid-probe, and as a result didn't permit runpm, keeping the entire GPU, PCIe bus and thus the CPU package awake. A bit of hackerly later we decided to continue probing without a codec, and now my laptop is happy, but... A new problem popped up with several other NVIDIA GPUs that expose their HDA subdevice, but somehow its inaccessible. Relevant lines from a users' log:
[ 3.031222] MXM: GUID detected in BIOS [ 3.031280] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031352] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031419] ACPI: _SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b) [ 3.031424] ACPI Warning: _SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 3.031619] pci 0000:00:02.0: optimus capabilities: enabled, status dynamic power, [ 3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 3.031731] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031791] ACPI Error: Aborting method _SB.PCI0.PEG0.PEGP._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 3.031856] ACPI: _SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b) [ 3.031859] ACPI Warning: _SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61)
If I am not wrong we are calling the _DSM method inside nouveau when doing runpm on pre _PR3 systems. As this is all very vendor specific, we might be doing something incorrectly.
[ 3.032058] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, [ 3.032061] VGA switcheroo: detected Optimus DSM method _SB_.PCI0.PEG0.PEGP handle [ 3.032323] checking generic (d0000000 410000) vs hw (f6000000 1000000) [ 3.032325] checking generic (d0000000 410000) vs hw (e0000000 10000000) [ 3.032326] checking generic (d0000000 410000) vs hw (f0000000 2000000) [ 3.032410] nouveau 0000:01:00.0: NVIDIA GK107 (0e71f0a2) [ 3.042385] nouveau 0000:01:00.0: bios: version 80.07.a0.00.11 --- snip --- [ 8.951478] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 8.951509] snd_hda_intel 0000:01:00.1: can't change power state from D3hot to D0 (config space inaccessible)
This is actually a little bad, because it means that the device doesn't come back up from D3. It's a bit weird it's D3cold and D3hot in the messages, but maybe the device just takes quite some time to wake up. But it does look like the device gets woken up.
[ 8.951608] snd_hda_intel 0000:01:00.1: Disabling MSI [ 8.951621] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 8.952461] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 8.952642] snd_hda_intel 0000:01:00.1: number of I/O streams is 30, forcing separate stream tags
Now I don't know what's going on, but the snd_hda_intel messages are ominous. And so are the ACPI warnings. But I don't know how much these two are related.
What is the actual problem though? Seems like everything is fine despite those messages.
The problem, as stated a few e-mails earlier, is that the HDA errors currently prevent snd_hda_intel from properly probing the device and registering it with vgaswitcheroo. As a result, the GPU always stays in DynPwr rather than DynOff even when it's unused, keeping the PCIe bus and the CPU package powered. Basically burning through a charged battery a lot quicker than need be.
That's not the result of those errors, just the result of having no codecs, no?
If it was just a case of no codecs, Takashi and my patches from last year would have fixed it. This one seems a bit more hairy.
sure, but the issue is still that no codecs are there on initial probe time, right? I still don't see how any of those warnings/errors are related to that unless the _DSM call flips something.
If we go back a mile on the e-mail thread, I think the problem was narrowed down to snd_hda_intel reading an invalid codec mask on the config space, and using it anyway. That being said, I believe there are also reports of users that don't get HDMI audio unless the cable was plugged in at boot-time, with similar messages in their logs. The codec might in such cases be hiding themselves until a cable is plugged in? @Aaron Plattner: does that latter observation sound right to you?
yeah, I think that's the thing we should focus on, everything else just seems unrelated at this point until we have more information (like, codecs hide, because the _DSM calls failed or something)
Sure, but the option of not exposing the HDA device in the first place had to be explored, even if it just led to rejecting the idea like it seems to have. I'm in favour of pushing forward the original fix that makes snd_hda_intel not fail on reading an invalid codec mask, and have it register the device with vgaswitcheroo so we can send it to DynOff. With the current snd_hda_intel architecture that seems simpler than failing to probe and unmapping the driver from the device. However, the issue of no HDMI sound unless plugged in as boot is/might be related, and needs to be on someone's agenda.
yeah.. but it might require a bigger rework of the snd_hda_intel driver as it seems. I am not sure how "dynamic" audio devices are in general, but it sounds like that devices usually just expose everything and are done with it.
In the end the GPU can wake up for any reason. you might start rendering and then you plug in the connector and honestly.. I think snd_hda_intel has to be able to recheck for changed configuration, because I have no idea what nouveau could do here anyway?
What I think we need to figure out is, what exactly is changing the audio device, it might be some bits in the nouveau loading code or it might indeed be something the device itself is doing? dunno... Maybe some of the vbios scripts are doing something as well?
I think having access to such a system would allow us to dig deeper and I think we need this understanding before throwing in random suggestions on what to do.
Maybe it's also worth checking with the nvidia driver and see how the situation is there?
You say that it is desirable to switch on HDA at boot-time because the PCI subsystem doesn't play nicely with changing a device to multi-function. That rules out the option of only enabling the HDA device once a cable is plugged in. Are there any other trap doors that
yeah, we can absolutely not do that. We do quirk the device to put the GPU into multi function state asap and the intel_hda_snd driver should deal with it.
snd_hda_intel needs to navigate around to make this work fault free on all hardware, such as:
- Codecs not revealing themselves until a display is plugged in,
requiring perhaps a "codec reprobe" and "codec remove" event from nouveau/rm to snd_hda_intel,
we could trigger the reprobe from within nouveau as we are dealing with display hotplug events anyway.
Right. Are there situations where nouveau needs to? Or is this a misunderstanding of the problem from my end?
nouveau has to do some configuration anyway, like connecting the audio stream with the port used etc...that's the ELD part. We have some drm_audio bits though, so maybe we can solve this more general and maybe the radeon drivers already have something here? Might be worth to take a look there as well.
- Borked BIOSes just blindly assigning the MMIO space of the HDA device
to another device, or nothing at all,
that exists? *sigh*
- ... other things that might give any of us nightmares and heart burn?
hopefully there are none :p
Thanks!
Roy
-- Aaron
>> Thanks, >> >> Lukas
Hi Kai-Heng,
I am facing the same bug. Unfortunately your patch does not seem to fix the bug for me, the nvidia GPU stays constantly active. Only if I unbind the snd-hda-intel module for this PCI device that the nvidia GPU will eventually go to sleep.
My dmesg (with your patch applied):
[ 1.821358] MXM: GUID detected in BIOS [ 1.821396] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 1.821406] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 1.821415] ACPI: _SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b) [ 1.821419] ACPI Warning: _SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 1.821528] i915 0000:00:02.0: optimus capabilities: enabled, status dynamic power, [ 1.821554] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 1.821560] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 1.821565] ACPI Error: Aborting method _SB.PCI0.PEG0.PEGP._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 1.821572] ACPI: _SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b) [ 1.821574] ACPI Warning: _SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 1.821683] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, [ 1.821685] VGA switcheroo: detected Optimus DSM method _SB_.PCI0.PEG0.PEGP handle [ 1.821920] nouveau 0000:01:00.0: NVIDIA GK107 (0e71f0a2) [ 1.830781] nouveau 0000:01:00.0: bios: version 80.07.95.00.07 [ 1.894392] nouveau 0000:01:00.0: fb: 2048 MiB DDR3 [ 1.896669] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on minor 0 [ 1.896862] ACPI: Video Device [PEGP] (multi-head: yes rom: yes post: no) [ 1.897361] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/LNXVIDEO:00/input/input12 [ 1.897974] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 1.898219] nouveau 0000:01:00.0: bus: MMIO write of 0000001f FAULT at 6013d4 [ IBUS ] [ 1.900114] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input13 [ 1.969353] vga_switcheroo: enabled [ 1.969407] [TTM] Zone kernel: Available graphics memory: 3791596 KiB [ 1.969408] [TTM] Zone dma32: Available graphics memory: 2097152 KiB [ 1.969409] [TTM] Initializing pool allocator [ 1.969416] [TTM] Initializing DMA pool allocator [ 1.969431] nouveau 0000:01:00.0: DRM: VRAM: 2048 MiB [ 1.969432] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB [ 1.969436] nouveau 0000:01:00.0: DRM: Pointer to TMDS table not found [ 1.969438] nouveau 0000:01:00.0: DRM: DCB version 4.0 [ 1.971139] nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies [ 1.971485] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 1
[ ... ]
[ 4.594245] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 4.594380] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.594410] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.594486] snd_hda_intel 0000:01:00.1: Disabling MSI [ 4.594494] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 4.594526] snd_hda_intel 0000:01:00.1: number of I/O streams is 30, forcing separate stream tags
[ ... ]
[ 4.696732] hdaudio hdaudioC1D0: no AFG or MFG node found [ 4.696745] hdaudio hdaudioC1D1: no AFG or MFG node found [ 4.696752] hdaudio hdaudioC1D2: no AFG or MFG node found [ 4.696759] hdaudio hdaudioC1D3: no AFG or MFG node found [ 4.696765] hdaudio hdaudioC1D4: no AFG or MFG node found [ 4.696771] hdaudio hdaudioC1D5: no AFG or MFG node found [ 4.696778] hdaudio hdaudioC1D6: no AFG or MFG node found [ 4.696785] hdaudio hdaudioC1D7: no AFG or MFG node found [ 4.696787] snd_hda_intel 0000:01:00.1: no codecs initialized
Cheers, -Paul
Le mer., déc. 16 2020 at 20:47:24 +0800, Kai-Heng Feng kai.heng.feng@canonical.com a écrit :
Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller initialization even if no codecs found"), when codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So mark there's no codec and continue probing to let runtime PM to work.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6852668f1bcb..872a703dee43 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip) if (bus->codec_mask) { err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); if (err < 0)
goto out_free;
bus->codec_mask = 0;#ifdef CONFIG_SND_HDA_PATCH_LOADER
Hi,
Le ven., juin 25 2021 at 13:45:35 +0100, Paul Cercueil paul@crapouillou.net a écrit :
Hi Kai-Heng,
I am facing the same bug. Unfortunately your patch does not seem to fix the bug for me, the nvidia GPU stays constantly active. Only if I unbind the snd-hda-intel module for this PCI device that the nvidia GPU will eventually go to sleep.
Nevermind, I'm stupid. I think I just didn't have the PM mode set to "auto", because I tried again and it works now. Ignore my email.
If you (or anybody) does a v3, please Cc me.
Cheers, -Paul
My dmesg (with your patch applied):
[ 1.821358] MXM: GUID detected in BIOS [ 1.821396] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 1.821406] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 1.821415] ACPI: _SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b) [ 1.821419] ACPI Warning: _SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 1.821528] i915 0000:00:02.0: optimus capabilities: enabled, status dynamic power, [ 1.821554] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 1.821560] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 1.821565] ACPI Error: Aborting method _SB.PCI0.PEG0.PEGP._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 1.821572] ACPI: _SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b) [ 1.821574] ACPI Warning: _SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 1.821683] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, [ 1.821685] VGA switcheroo: detected Optimus DSM method _SB_.PCI0.PEG0.PEGP handle [ 1.821920] nouveau 0000:01:00.0: NVIDIA GK107 (0e71f0a2) [ 1.830781] nouveau 0000:01:00.0: bios: version 80.07.95.00.07 [ 1.894392] nouveau 0000:01:00.0: fb: 2048 MiB DDR3 [ 1.896669] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on minor 0 [ 1.896862] ACPI: Video Device [PEGP] (multi-head: yes rom: yes post: no) [ 1.897361] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/LNXVIDEO:00/input/input12 [ 1.897974] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 1.898219] nouveau 0000:01:00.0: bus: MMIO write of 0000001f FAULT at 6013d4 [ IBUS ] [ 1.900114] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input13 [ 1.969353] vga_switcheroo: enabled [ 1.969407] [TTM] Zone kernel: Available graphics memory: 3791596 KiB [ 1.969408] [TTM] Zone dma32: Available graphics memory: 2097152 KiB [ 1.969409] [TTM] Initializing pool allocator [ 1.969416] [TTM] Initializing DMA pool allocator [ 1.969431] nouveau 0000:01:00.0: DRM: VRAM: 2048 MiB [ 1.969432] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB [ 1.969436] nouveau 0000:01:00.0: DRM: Pointer to TMDS table not found [ 1.969438] nouveau 0000:01:00.0: DRM: DCB version 4.0 [ 1.971139] nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies [ 1.971485] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 1
[ ... ]
[ 4.594245] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 4.594380] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.594410] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.594486] snd_hda_intel 0000:01:00.1: Disabling MSI [ 4.594494] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 4.594526] snd_hda_intel 0000:01:00.1: number of I/O streams is 30, forcing separate stream tags
[ ... ]
[ 4.696732] hdaudio hdaudioC1D0: no AFG or MFG node found [ 4.696745] hdaudio hdaudioC1D1: no AFG or MFG node found [ 4.696752] hdaudio hdaudioC1D2: no AFG or MFG node found [ 4.696759] hdaudio hdaudioC1D3: no AFG or MFG node found [ 4.696765] hdaudio hdaudioC1D4: no AFG or MFG node found [ 4.696771] hdaudio hdaudioC1D5: no AFG or MFG node found [ 4.696778] hdaudio hdaudioC1D6: no AFG or MFG node found [ 4.696785] hdaudio hdaudioC1D7: no AFG or MFG node found [ 4.696787] snd_hda_intel 0000:01:00.1: no codecs initialized
Cheers, -Paul
Le mer., déc. 16 2020 at 20:47:24 +0800, Kai-Heng Feng kai.heng.feng@canonical.com a écrit :
Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller initialization even if no codecs found"), when codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So mark there's no codec and continue probing to let runtime PM to work.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6852668f1bcb..872a703dee43 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip) if (bus->codec_mask) { err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); if (err < 0)
goto out_free;
bus->codec_mask = 0;#ifdef CONFIG_SND_HDA_PATCH_LOADER
Le ven., juil. 2 2021 at 18:59:33 +0100, Paul Cercueil paul@crapouillou.net a écrit :
Hi,
Le ven., juin 25 2021 at 13:45:35 +0100, Paul Cercueil paul@crapouillou.net a écrit :
Hi Kai-Heng,
I am facing the same bug. Unfortunately your patch does not seem to fix the bug for me, the nvidia GPU stays constantly active. Only if I unbind the snd-hda-intel module for this PCI device that the nvidia GPU will eventually go to sleep.
Nevermind, I'm stupid. I think I just didn't have the PM mode set to "auto", because I tried again and it works now. Ignore my email.
Ok, I'm definitely not stupid, I could reproduce it again, with this patch applied and the PM set to "auto". It then only suspends when I unload the snd-hda-intel module.
Sorry about the spam.
-Paul
If you (or anybody) does a v3, please Cc me.
Cheers, -Paul
My dmesg (with your patch applied):
[ 1.821358] MXM: GUID detected in BIOS [ 1.821396] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 1.821406] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 1.821415] ACPI: _SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b) [ 1.821419] ACPI Warning: _SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 1.821528] i915 0000:00:02.0: optimus capabilities: enabled, status dynamic power, [ 1.821554] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000003) is beyond end of object (length 0x0) (20200925/exoparg2-393) [ 1.821560] ACPI Error: Aborting method _SB.PCI0.GFX0._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 1.821565] ACPI Error: Aborting method _SB.PCI0.PEG0.PEGP._DSM due to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529) [ 1.821572] ACPI: _SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b) [ 1.821574] ACPI Warning: _SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61) [ 1.821683] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, [ 1.821685] VGA switcheroo: detected Optimus DSM method _SB_.PCI0.PEG0.PEGP handle [ 1.821920] nouveau 0000:01:00.0: NVIDIA GK107 (0e71f0a2) [ 1.830781] nouveau 0000:01:00.0: bios: version 80.07.95.00.07 [ 1.894392] nouveau 0000:01:00.0: fb: 2048 MiB DDR3 [ 1.896669] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on minor 0 [ 1.896862] ACPI: Video Device [PEGP] (multi-head: yes rom: yes post: no) [ 1.897361] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/LNXVIDEO:00/input/input12 [ 1.897974] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 1.898219] nouveau 0000:01:00.0: bus: MMIO write of 0000001f FAULT at 6013d4 [ IBUS ] [ 1.900114] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input13 [ 1.969353] vga_switcheroo: enabled [ 1.969407] [TTM] Zone kernel: Available graphics memory: 3791596 KiB [ 1.969408] [TTM] Zone dma32: Available graphics memory: 2097152 KiB [ 1.969409] [TTM] Initializing pool allocator [ 1.969416] [TTM] Initializing DMA pool allocator [ 1.969431] nouveau 0000:01:00.0: DRM: VRAM: 2048 MiB [ 1.969432] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB [ 1.969436] nouveau 0000:01:00.0: DRM: Pointer to TMDS table not found [ 1.969438] nouveau 0000:01:00.0: DRM: DCB version 4.0 [ 1.971139] nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies [ 1.971485] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 1
[ ... ]
[ 4.594245] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 4.594380] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.594410] snd_hda_intel 0000:01:00.1: can't change power state from D3cold to D0 (config space inaccessible) [ 4.594486] snd_hda_intel 0000:01:00.1: Disabling MSI [ 4.594494] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 4.594526] snd_hda_intel 0000:01:00.1: number of I/O streams is 30, forcing separate stream tags
[ ... ]
[ 4.696732] hdaudio hdaudioC1D0: no AFG or MFG node found [ 4.696745] hdaudio hdaudioC1D1: no AFG or MFG node found [ 4.696752] hdaudio hdaudioC1D2: no AFG or MFG node found [ 4.696759] hdaudio hdaudioC1D3: no AFG or MFG node found [ 4.696765] hdaudio hdaudioC1D4: no AFG or MFG node found [ 4.696771] hdaudio hdaudioC1D5: no AFG or MFG node found [ 4.696778] hdaudio hdaudioC1D6: no AFG or MFG node found [ 4.696785] hdaudio hdaudioC1D7: no AFG or MFG node found [ 4.696787] snd_hda_intel 0000:01:00.1: no codecs initialized
Cheers, -Paul
Le mer., déc. 16 2020 at 20:47:24 +0800, Kai-Heng Feng kai.heng.feng@canonical.com a écrit :
Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller initialization even if no codecs found"), when codec probe fails, it doesn't enable runtime suspend, and can prevent graphics card from getting powered down: [ 4.280991] snd_hda_intel 0000:01:00.1: no codecs initialized
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active
So mark there's no codec and continue probing to let runtime PM to work.
BugLink: https://bugs.launchpad.net/bugs/1907212 Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6852668f1bcb..872a703dee43 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip) if (bus->codec_mask) { err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); if (err < 0)
goto out_free;
bus->codec_mask = 0;#ifdef CONFIG_SND_HDA_PATCH_LOADER
participants (8)
-
Aaron Plattner -
Ilia Mirkin -
Kai-Heng Feng -
Karol Herbst -
Lukas Wunner -
Paul Cercueil -
Roy Spliet -
Takashi Iwai