[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1336119221-21146-2-git-send-email-ying.huang@intel.com>
Date: Fri, 4 May 2012 16:13:37 +0800
From: Huang Ying <ying.huang@...el.com>
To: Bjorn Helgaas <bhelgaas@...gle.com>
Cc: ming.m.lin@...el.com, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
Huang Ying <ying.huang@...el.com>,
Zheng Yan <zheng.z.yan@...el.com>
Subject: [RFC v2 1/5] PM, Runtime, Add power_must_be_on flag
The extreme way to save device power in runtime is to turn off power
of device. For example, D3cold for PCIe bus and ZPODD (Zero Power
Optical Disk Drive) for SATA bus will do that.
But sometimes power off is not expected, some possible reason is as
follow
- power off device usually incurs longer resume latency, if it exceeds
power QoS requirement, power off should be disabled.
- For some buses, device in power off state can not support remote
wakeup. If remote wakeup is desired, power off should be disabled.
In general, whether to put a device into power off state should be
decided by the driver of the device, but for some buses, whether to
put a device into power off state may be done by the parent of the
device. For example, a PCIe end point device may be put into power
off state by the PCIe port connected to it.
So a flag is introduced for the children devices to tell the parent
device, whether it should be put into power off state.
This flag is also used for device driver to tell bus layer whether it
is OK to be powered off.
Signed-off-by: Huang Ying <ying.huang@...el.com>
---
include/linux/pm.h | 1 +
1 file changed, 1 insertion(+)
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -536,6 +536,7 @@ struct dev_pm_info {
unsigned int irq_safe:1;
unsigned int use_autosuspend:1;
unsigned int timer_autosuspends:1;
+ unsigned int power_must_be_on:1;
enum rpm_request request;
enum rpm_status runtime_status;
int runtime_error;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists