Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
On Tue, Apr 13, 2021 at 1:17 PM Roy Spliet wrote: > > Op 13-04-2021 om 10:48 schreef Karol Herbst: > > On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet wrote: > >> > >> Op 13-04-2021 om 01:10 schreef Karol Herbst: > >>> On Mon, Apr 12, 2021 at 9: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. > > >>> > >>> 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):
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
Op 13-04-2021 om 10:48 schreef Karol Herbst: On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet wrote: Op 13-04-2021 om 01:10 schreef Karol Herbst: On Mon, Apr 12, 2021 at 9: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. 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 (0x3) 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 :00:02.0: optimus capabilities: enabled, status dynamic power, [3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x3) is beyond end of object (length 0x0) (20200925/exoparg2-393) [3.031731] ACPI Error: Aborting method \_SB.PCI0.GFX0._DSM due to previous error
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet wrote: > > Op 13-04-2021 om 01:10 schreef Karol Herbst: > > On Mon, Apr 12, 2021 at 9: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. > >> > > > > 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 > >> (0x3) 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
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
Op 13-04-2021 om 01:10 schreef Karol Herbst: On Mon, Apr 12, 2021 at 9: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. 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 (0x3) 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 :00:02.0: optimus capabilities: enabled, status dynamic power, [3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x3) 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
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
On Mon, Apr 12, 2021 at 9: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. > 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 > (0x3) 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 :00:02.0: optimus capabilities: enabled, status > dynamic power, > [3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index > (0x3) is beyond end of object
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
On Mon, Apr 12, 2021 at 4:01 PM Aaron Plattner 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
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
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
(0x3) 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 :00:02.0: optimus capabilities: enabled, status
dynamic power,
[ 3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index
(0x3) 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 :01:00.0: optimus capabilities: enabled, status
dynamic power,
[ 3.032061] VGA switcheroo: detected Optimus DSM method
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
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 (0x3) 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 :00:02.0: optimus capabilities: enabled, status dynamic power, [3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x3) 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 :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 (d000 41) vs hw (f600 100) [3.032325] checking generic (d000 41) vs hw (e000 1000) [3.032326] checking generic (d000 41) vs hw (f000 200) [3.032410] nouveau :01:00.0: NVIDIA GK107 (0e71f0a2) [3.042385] nouveau :01:00.0:
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
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
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
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
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
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
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
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
wrote:
On Tue, Dec 22, 2020 at 1:56 AM Ilia Mirkin wrote:
On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng
wrote:
[+Cc nouveau]
On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai 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/drivers/pci/quirks.c?h=v5.10#n5267
Cheers,
-ilia
___
Nouveau mailing list
nouv...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
nouv...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
On Tue, Dec 22, 2020 at 3:50 AM Kai-Heng Feng
wrote:
>
> On Tue, Dec 22, 2020 at 1:56 AM Ilia Mirkin wrote:
> >
> > On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng
> > wrote:
> > >
> > > [+Cc nouveau]
> > >
> > > On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai 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/drivers/pci/quirks.c?h=v5.10#n5267
> >
> > Cheers,
> >
> > -ilia
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
On Tue, Dec 22, 2020 at 1:56 AM Ilia Mirkin wrote:
>
> On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng
> wrote:
> >
> > [+Cc nouveau]
> >
> > On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai 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/drivers/pci/quirks.c?h=v5.10#n5267
>
> Cheers,
>
> -ilia
Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng
wrote:
>
> [+Cc nouveau]
>
> On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai 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/drivers/pci/quirks.c?h=v5.10#n5267
Cheers,
-ilia
