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>