On Tuesday, February 21, 2012, Zhang Rui wrote: > On 二, 2012-02-21 at 00:13 +0100, Rafael J. Wysocki wrote: > > > So how to handle this case, say, for a device in the generic PM domain > > > that supports 2 different low power state, D1 and D2. > > > D2 is deeper than D1, and it is kind of cold power off with remote > > > wakeup disabled. If the driver needs to runtime suspend the device with > > > remote wakeup enabled, it should set the device to D1, but it can not > > > set the RPM_SUSPEND? > > > > The device is regarded as "suspended" if its bus type's (or PM domain's) > > .runtime_suspend() callback has been executed and has returned 0 (success). > > What the callback has actually done is not of any interest to the core. > > > right. > > > Now, the D1 and D2 case has to be handled by the bus (PM domain) and > > driver. In both cases the device will be regarded as "suspended" and the > > core doesn't track the actual device state. > > > > > > I think the problem here is that the PCI bus type's runtime PM callbacks > > aren't very sophisticated (they just choose the lowest possible low-power > > state and attempt to put the device into it) and I can see two possible > > ways to address that. > > > > First, you can modify pci_pm_runtime_suspend/_resume() to handle multiple > > states (for example, to choose the target low-power state more intelligently > > than they do right now). Second, you can add a PM domain that will do what > > you want from pci_pm_runtime_suspend/_resume() for a specific set of devices. > > > But RPM_SUSPENDED is set by PM core after .runtime_suspend() being > invoked, even if device is in D1 instead of D2, right? > > So the problem is that, if a device in a generic power domain supports > two low power state, one is compatible with generic power domain power > off and another is not, how can the device driver pass this information > to the generic power domain, i.e. how to runtime suspend a device while > keep the generic power domain always on? There are two "low-power" levels in the generic PM domains framework. The first one is the per-device low-power in which devices are put into their individual (programmable) low-power states by the domain .dev_ops->stop() callback. The second one is when .stop() has been called for all devices, so presumably all of them are in programmable low-power states and it's possible to switch the entire domain off. This is done by the domain .power_off() callback. It seems that the trick might be to make .dev_ops->stop() avoid turning off power resources for the last suspending device in the domain and leave that to domain .power_off(). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
