Date: Thu, 26 Aug 2004 12:23:58 -0700 From: Nate Lawson <nate@root.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: acpi@freebsd.org Subject: Re: Cx states not working on Dell Inspiron 8600 (Pentium M) Message-ID: <412E38CE.50700@root.org> In-Reply-To: <20040826.124848.93209661.imp@bsdimp.com> References: <20040826163734.49EBF5D04@ptavv.es.net> <20040826181008.GA792@galgenberg.net> <412E2D33.1090900@root.org> <20040826.124848.93209661.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > In message: <412E2D33.1090900@root.org> > Nate Lawson <nate@root.org> writes: > : Ulrich Spoerlein wrote: > : > On Thu, 26.08.2004 at 09:37:33 -0700, Kevin Oberman wrote: > : > > : >>The cx_usage is limited to C1 or C2 if USB is loaded. It's polling of > : >>the bus for changes prevents the state from dropping to anything really > : >>useful. If you don't always need USB, build a kernel without it and load > : >>it as required. > : > > : > Ah, that explains it then. Is there anything that can be done about > : > that? Does that mean, that even Windows is not using C3 and C4 if there > : > is a USB mouse plugged in? > : > : USB needs to be improved to poll more delicately. I don't intend to > : work on this any time soon but it's on the acpi todo list: > : > : http://www.root.org/~nate/freebsd/ > > This strikes me as something more properly belonging to the busdma > layer. When there's bus mastering active, then we can't go into > C3/C4. However, not all drivers in the tree are good about only > loading the DMA maps when a DMA is possible (but leaving it active all > the time, say), so maybe there's some wider-ranging problems that need > to be looked at as well. While USB may also need some work to be > better about when it does DMA, I suspect that the problem is larger > than USB... Why does the bus mastering that ATA does not a problem > while USB's is a problem? (I bcc'd Ian Dowse in case he has some more to add). Because the BM activity is initiated by the host controller autonomously, not in response to any transaction by the driver. The [e,o,u]hci interface is relatively high level. Insertion/removal events are handled by the host controller firmware and a usb intr is generated. While a port is enabled, the controller decides to poll at its discretion, generating BM activity. I think the only way to prevent this is to suspend the port or place the host controller in global suspend mode. Global suspend seems too slow (20 ms transition max) but perhaps putting the port in suspend may be enough. See the UHCI spec, section 2.1 > Have you isolaged the USB agressive polling problem to some code I can > look at. I have some usb code staring time on my plate for work and > it would be nice to know where to look. That would be great. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?412E38CE.50700>