[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75985

--- Comment #63 from Lukas Wunner <lukas at wunner.de> ---
(In reply to Peter Wu from comment #59)
> (In reply to Lukas Wunner from comment #51)
> > On my GK107 I do not see any change in power consumption regardless whether
> > bit 25 at config space offset 0x488 is set or cleared, which is somewhat
> > disappointing. I also do not see a change in power consumption between PCI
> > power state D0 and D3hot.
> 
> Was this your macbook or a regular laptop? The Kepler family still used an
> ACPI _DSM method to remove power, setting the PM bit in the PCI config space
> did not do anything (this was at least true for my older Fermi card).

This was on my MacBook Pro. (Is that not a regular laptop? ;-) ) Power to the
GK107 GPU is cut and reinstated by the GMUX controller rather than a _DSM. I
can hide and expose the audio device by clearing or setting bit 25 at offset
0x488, but this does not change power consumption in any way. Only cutting
power to the GPU via GMUX does.

That the audio device is powergated on newer GPUs was only a theory. Because,
why would laptop vendors hide the audio device if nothing is connected? One
possible explanation is that it saves power. Someone needs to confirm or debunk
this theory by clearing and setting the bit and comparing power consumption in
powertop.


> Possibly relevant for this bug: I tested Lukas devlink_v2 patches but found
> some issues when the HDMI/DP cable was disconnected on a GTX 965M (where by
> default the audio function would not be visible):
> https://lists.freedesktop.org/archives/nouveau/2018-March/029988.html
> 
> Do you also experience issues after these steps:
> 1. remove+rescan to make audio function appear
> 2. remove GPU power (runtime PM or system sleep)
> 3. remove HDMI/DP cable
> 4. restore power
> 5. check dmesg or try to access audio function (e.g. read PCI regs)

I've had a look at the acpidump of your machine:
https://github.com/Lekensteyn/acpi-stuff/tree/master/dsl/Clevo_P651RA

Bit 25 at offset 0x488 is named NHDA. In two places (in the _ON method of the
root port's power resource and in _PS0 of the GPU device), the AML code probes
three GPIO pins and exposes the HDA controller if any of them are high, or else
hides the GPU. These GPIO pins are probably wired to HPD of the external
connectors.

I think what happens in the scenario you've described above is: On runtime
suspend or system suspend, the state of the HDA is saved (BARs etc). Because
the cable is disconnected, the HDA will be hidden on resume. Now the kernel
tries to wake the HDA device to D0 and will fail (you should see "Refused to
change power state, currently in D3" in dmesg). It will then restore the saved
state, which will also fail because the device is inaccessible. Also, the saved
state is invalidated and cannot be restored again. So the HDA's BARs are blank
until you remove+rescan.

I've just attached three patches, please try those on top of my
switcheroo_devlink_v2 series, they should fix the issue.

Crucially, patch [1/3] now also applies the PCI quirk during the resume_noirq
and runtime_resume phase. This means that in the scenario you've given above,
even though the BIOS may have hidden the HDA, that change will be undone by the
quirk. The quirk is executed for the GPU device. We know that the HDA device
will resume *after* the GPU device because of the device link.

I cannot test these patches myself because the HDA is never hidden on my
machine. So the patches are compile-tested only.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20180309/39d7c4e7/attachment.html>