Subject: Re: PCI power state code (was: CVS commit: syssrc)
To: Johan Danielsson <firstname.lastname@example.org>
From: John Hawkinson <jhawk@MIT.EDU>
Date: 07/19/2000 13:30:42
| 5.4 PCI Function D3 State
Thanks for the exceprt. I think the more relevent part, though, is:
/ 8.3 Restoring PCI Functions From a Low Power State
/ 8.3.3 D3 State
/ Restoring a function from D3 requires the operating system to
/ reinitialize the function, beginning with, for the case of D3cold,
/ restoring power to the device and initiating a PCI Bus Segment
/ Reset. This is accomplished by either programming the hosting bus's
/ Originating Device to D0 or by other ACPI-type control methods.
/ Full context must be restored to the function before it is capable
/ of resuming normal operation.
/ For example, reinitialization includes, but is not necessarily
/ limited to, restoring the Base Address registers, re-enabling the
/ I/O and memory spaces, re-enabling bus master capabilities, and
/ unmasking any IRQs or PCI Interrupts as well as restoring the INT
/ Line register. Furthermore, if the function has the DSI bit set, the
/ operating system is required to execute whatever initialization code
/ is necessary, either via the device driver's initialization code or
/ by executing POST.
In our case, D3cold is irrelevent, and we're only restoring
devices from D3hot, as we have no mechanism to control whether
power is applied. So that limits what we need to do to:
1. Restore PCI configuration state.
2. Unmask any masked IRQs
3. Execute any driver-specific initialization
4. Wait 10ms recovery time.
It would seem that in these cases (2) was not pertinent, and
(3) is driver-specific, but in the _attach() routine, that may be less
It would seem that, for devices that re unconfigured, at least for the
i386 port, we can leverge the pcibios fixup routines, which setup the BAR
for those devices that the BIOS does not.
I'm unsure how it would be best to do this, though. Perhaps the
pcibios code should detect devices that are in D3 and power them up,
or perhaps the fxp/tlp/epic drivers should execute some sort of MD
callback that (on the i386) routes back to the pcibios stuff?