Date: Fri, 9 Apr 2004 13:59:25 -0700 (PDT) From: Nate Lawson <nate@root.org> To: "M. Warner Losh" <imp@bsdimp.com> 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: <20040409135648.V49998@root.org> In-Reply-To: <20040409.145452.24901640.imp@bsdimp.com> References: <200404091544.i39FiYDY061986@repoman.freebsd.org> <4076CE28.1020705@freebsd.org> <20040409.103449.122315793.imp@bsdimp.com> <20040409.145452.24901640.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040409135648.V49998>