Commen=
t # 63
on bug 75985<=
/a>
from Lukas Wunner
(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 regardle=
ss whether
> > bit 25 at config space offset 0x488 is set or cleared, which is s=
omewhat
> > disappointing. I also do not see a change in power consumption be=
tween PCI
> > power state D0 and D3hot.
>=20
> Was this your macbook or a regular laptop? The Kepler family still use=
d 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).<=
/span >
This was on my MacBook Pro. (Is that not a regular laptop? ;-) ) Power to t=
he
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. Becaus=
e,
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 de=
bunk
this theory by clearing and setting the bit and comparing power consumption=
in
powertop.
> Possibly relevant for this bug: I tested Lukas d=
evlink_v2 patches but found
> some issues when the HDMI/DP cable was disconnected on a GTX 965M (whe=
re by
> default the audio function would not be visible):
> https://lists.freedesktop.org/archives/nouveau/2018-March/02998=
8.html
>=20
> 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_P651R=
A
Bit 25 at offset 0x488 is named NHDA. In two places (in the _ON method of t=
he
root port's power resource and in _PS0 of the GPU device), the AML code pro=
bes
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 "Refu=
sed to
change power state, currently in D3" in dmesg). It will then restore t=
he saved
state, which will also fail because the device is inaccessible. Also, the s=
aved
state is invalidated and cannot be restored again. So the HDA's BARs are bl=
ank
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_noi=
rq
and runtime_resume phase. This means that in the scenario you've given abov=
e,
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.