cvs commit: src/sys/dev/pci pci.c pci_pci.c pci_private.h src/sys/dev/acpica acpi_pci.c acpi_pcib_acpi.c

[Nate Lawson]

On Fri, 9 Apr 2004, M. Warner Losh wrote:
> : : I'm really really uncomfortable with the part of this that does the
> : : power state changes.  It's going to require a _lot_ of testing with as
> : : much hardware as we all can get our hands on.  It will be an interesting
> : : experiment =-)
> :
> : Yes.  I agree witht he power state changes being risky.  That's why
> : I'm committing them now rather than in 4 months so that we can get
> : some milage on -current with it.  If it is really bad, we can back off
> : that part of the change, or refine it to overcome the problems.
>
> Also, the power state changes should typically be no-ops (no cycles to
> hardware) since all that's added in the 'typical' case that I've seen
> is D0->D3 for some devices w/o drivers.  This may impact
> kldload/kldunload of drivers, however, and there are several laptops
> that power up all their pci devices in D3 state which may see them
> turned on and off where before they stated off.  On resume, we now set
> the state do D0 (obsoleting hundreds of lines of driver code, but I've
> not yet removed that code from the tree).
>
> So it isn't as huge a change as the change made it sound.  However,
> even having said that, I agree that we may find it causes issues.

The biggest issue though is that without BAR restoration, suspend/resume
will never work.  Without powerstate control, many peripherals will also
never work since they expect the OS to power them up before probing.  The
fact that most of our drivers do the power up individually helps but there
are some that don't.

We had to approach this at some point and it's better now than later.
It's also very easy to nop out for people that it causes problems for
while a solution is worked on.

-Nate