On Friday 24 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. > > > 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). > > 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. > > > 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? pci_prepare_to_sleep() is for that. It first finds the appropriate state, either by calling the platform, or by choosing the lowest suitable power state on the basis of the contents of the PCI PM configuration registers, enables wake-up (if necessary) and puts the device into that state. > 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. pci_prepare_to_sleep() is supposed to work on these systems too. If it doesn't, then it's buggy and will have to be fixed. :-) Best, Rafael -- 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