[lkml]   [2012]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC v2 1/5] PM, Runtime, Add power_must_be_on flag
    On Fri, May 4, 2012 at 2:13 AM, Huang Ying <> wrote:
    > 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 <>
    > ---
    >  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;

    It's a little weird to just add the field, with no users. Would it
    make sense to pull out the bits of patch 5 that use this and combine
    them into a single smaller patch? But see related comments there; it
    might be safer to have a function that computes this whenever you need
    it instead of caching the value.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-05-04 22:21    [W:0.033 / U:23.592 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site