Comme=
nt # 48
on bug 10576=
0
from Alex Deucher
(In reply to Thomas Martitz from comment #47)
> So pci_raw_set_power_state() does a pci_read_con=
fig_word() and that returns
> a valid word. Yet, the device appears to be not in powerd up state lat=
er on.
> How's that possible, and why does it work on Windows?
>=20
> Can I inspect Windows behavior in some way to get insight?
>=20
> Since Windows works I'm sure there must be a SW fix (or at least a
> workaround) available. Perhaps just wait for a bit?
In HG laptops, the d3cold control is handled by the OS rather than the driv=
er
(e.g., the driver doesn't call into APCI to handle d3cold, the pci core doe=
s).=20
The driver just has to support the necessary callbacks to the OS to enter/l=
eave
this state when idle. Each OS interacts slightly differently with ACPI so =
if
the OEM never validated Linux it's likely there is some slight differences =
in
the sequencing that is causing a problem. You might try playing with the A=
CPI
interfaces directly on Linux. There are user mode tools to interact with A=
CPI.
Blacklist the amdgpu driver and try calling the _PR3 method for the device=
to
power it down/up and then see if the device comes back properly.