On Mon, 27 Apr 2009, David Brownell wrote: > 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.) Okay, I stand corrected. The patch has already been submitted, so you can see if it looks okay. 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
