Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 09 Apr 2004 14:54:52 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        scottl@FreeBSD.org
Cc:        cvs-all@FreeBSD.org
Subject:   Re: 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
Message-ID:  <20040409.145452.24901640.imp@bsdimp.com>
In-Reply-To: <20040409.103449.122315793.imp@bsdimp.com>
References:  <200404091544.i39FiYDY061986@repoman.freebsd.org> <4076CE28.1020705@freebsd.org> <20040409.103449.122315793.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
: : 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.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040409.145452.24901640.imp>