My point is that's only needed if the hardware wasn't initialized correctly.
If it's initialized properly then it behaves like you expect.
So is this something that BIOS must initialize, and then it's locked
so that by the time Linux shows up, this one-time initialization can
no longer be done?
If Linux *could* do this one-time initialization, and subsequent
D0/D3hot transitions worked per spec, that would be awesome because we
wouldn't have to worry about making sure we run the quirk at every
possible transition.
It can be changed again at runtime.
That's exactly what we did in amdgpu for the case that the user didn't
disable integrated GPU.
We did the init for the IP block during amdgpu's HW init phase.
I see 3 ways to address this:
1) As submitted or similar (on every D state transition work around the
issue).
2) Mimic the Windows behavior in Linux by disabling MSI-X during D3
entry and re-enabling on D0.
3) Look for a way to get to and program that register outside of amdgpu.
There are merits to all those approaches, what do you think?
Let's say somebody runs coreboot on this platform. Does coreboot need
this device-specific knowledge?
Yes; the exact same bug will happen with a coreboot implementation that had
the initialization done improperly.
My claim is that this means the device doesn't conform to the spec.
If we add a conforming PCI device that neither the OS nor the firmware
has ever seen before, standard generic functionality like power
management should just work.
Bjorn
Yeah as it's configured here I agree with you.
