On Thursday 23 April 2009, Alan Stern wrote: > On Thu, 23 Apr 2009, Rafael J. Wysocki wrote: > > > On Thursday 23 April 2009, Alan Stern wrote: > > > Rafael: > > > > Hi, > > > > > This patch converts the USB PCI-based host controller drivers over to > > > the new PM framework. Does it all look right to you? > > > > Yes, it does, from a quick look, but I've always wondered why you insist on > > putting the devices into D3. > > You mean, why D3 instead of D1 or D2? Because we're trying to save > power, so we go to the lowest-power state. Actually ... I think the *original* reason is that nobody anywhere in-kernel tried to use D1 or D2 (back in 2.4.x). Then later on the reason was more coupled to the lack of a usable hook to choose the right state. Someone hacked together a severely broken choose_state() function, which -- because it was so broken -- wasn't remotely usable by USB. > > Is it a result of the experimental observation > > that none of the other states work in general? > > It's true that lots of devices have support for D3hot but not D1 or D2. > I've never seen it go the other way around (D1 or D2, but not D3). More like: D3 is guaranteed to be possible, D1/D2 are not. (Plus, as I recall, you can't know in advance whether D3 will be mapping to D3hot or D3cold as you're suspending. So you've got to accomodate D3cold in all cases. And ... testability for other states has always been weak and painful.) > And if the device can go into D3 then why mess around with D1 or D2? > Perhaps they might be useful as runtime-suspend states, but there's no > real point in using them for system suspend. Erm, there are *very* good reasons to prefer D1/D2 to D3. - First, remote wakeup is more likely to work there than in D3. - Second, wakeup latency is a lot lower ... preferable for STR, and even standby. Especially for the sort of stuff that OLPC was trying to do, with a system suspend state between keystrokes. (It's not clear to me that's realistic on PC hardware. Embedded ARMs -- piece'o'cake, OMAP systems do it routinely with Linux. High-wattage x86, PCI, southbridges, LPC, and all that? Not so much.) - Third, the D3->D0 transition can imply a reset, with loss of USB state (disconnection etc); annoying user experience. Not so from D2 or D1; things keep working, unless there was a *real* disconnect, no loss of state implied. - Fourth, ACPI may prefer that. (Although being able to care what ACPI thinks is a relatively new capability; and, even newer, having ACPI work right when it's used!) > > In principle ACPI might want to put them into D1 or D2 before suspend, > > especially is wake-up is enabled. > > I suppose it might. But how would I know, or what could I do about it? > Is there a core PCI function that should be called to select the > appropriate low-power state? There was some work in that area at one point. The first iteration was unusable crap. I've lost track since then, but I think Rafael may have made it become possible by now. > Bear in mind that this code also has to support PCI devices on non-ACPI > systems, as well as PCI devices on add-on cards (rather than built into > the motherboard) which ACPI is unaware of. Right, which is why there are PCI hooks to platform code, which will go to ACPI on some systems or otherwise just use raw PCI data. (Like the PCI PM capabilities saying that a device can support D2, and intermediate bridges saying they support all the necessary hooks also.) - Dave > Alan Stern > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
