Matthew Wilcox wrote:
On Fri, Feb 13, 2009 at 04:32:47PM +0000, Mark McLoughlin wrote:
- Secondary Bus Reset (SBR) allows software to trigger a reset on all
devices (and functions) behind a PCI bridge.
- A PCI Power Management D-state transition (D3hot to D0) can be used
to reset a device (all functions).
That's not guaranteed according to PCI PM 1.2:
5.4.1. Software Accessible D3 (D3hot)
When programmed to D0, the function may return to the D0 Initialized
or D0 Uninitialized state without PCI RST# being asserted. This option
is determined at design time and allows designs the option of either
performing an internal reset or not performing an internal reset.
The No_Soft_Reset bit in the PMCSR indicates which option is chosen at
design time:
Section 3.2.4. says:
Value at Reset: Device specific
Read/Write: Read Only
When set (“1”), this bit indicates that devices transitioning from D3hot
to D0 because of PowerState commands do not perform an internal reset.
Configuration Context is preserved. Upon transition from the D3hot to
the D0 Initialized state, no additional operating system intervention is
required to preserve Configuration Context beyond writing the PowerState
bits. When clear (“0”), devices do perform an internal reset upon
transitioning from D3hot to D0 via software control of the PowerState
bits. Configuration Context is lost when performing the soft reset. Upon
transition from the D3hot to the D0 state, full reinitialization
sequence is needed to return the device to D0 Initialized. Regardless of
this bit, devices that transition from D3hot to D0 by a system or bus
segment reset will return to the device state D0 Uninitialized with only
PME context preserved if PME is supported and enabled.
So the reset is guaranteed if the bit is 0.
And I checked the devices on my machine, all of them who have PM perform
internal reset when transiting from D3hot to D0 (GeForce 7300, Myri-10G,
E1000 82567, ICH10 SATA, EHCI, etc.)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
