Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Runtime power management in Windows 8

Jake_OshinsJake_Oshins Member Posts: 1,058
As all of you know, Microsoft has shifted it's policies in the last few
years, asking us not to discuss upcoming products. It's nice, at this
point, to be able to tell you what we've been working on. For no reason in
particular, here are some links to the just-updated docs on runtime power
management in Windows 8, which is what I've been working on for the last
year or so. It includes support for D3cold in PCI and other buses, as well
as sub-device, component-level power management.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff543162(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff543186(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/hh967706(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/hh406637(v=vs.85).aspx

I'm happy to discuss any of this as it pertains to writing drivers.

Jake Oshins
Windows Kernel Team

This message offers no warranties and confers no rights.

-----------------------------------------------------------

Comments

  • mmmm Member - All Emails Posts: 1,410
    Why thanks, Jakeo.

    Mm
    On May 31, 2012 6:53 PM, "Jake Oshins" wrote:

    > As all of you know, Microsoft has shifted it's policies in the last few
    > years, asking us not to discuss upcoming products. It's nice, at this
    > point, to be able to tell you what we've been working on. For no reason in
    > particular, here are some links to the just-updated docs on runtime power
    > management in Windows 8, which is what I've been working on for the last
    > year or so. It includes support for D3cold in PCI and other buses, as well
    > as sub-device, component-level power management.
    >
    > http://msdn.microsoft.com/en-**us/library/windows/hardware/**
    > ff543162(v=vs.85).aspx
    > http://msdn.microsoft.com/en-**us/library/windows/hardware/**
    > ff543186(v=vs.85).aspx
    > http://msdn.microsoft.com/en-**us/library/windows/hardware/**
    > hh967706(v=vs.85).aspx
    > http://msdn.microsoft.com/en-**us/library/windows/hardware/**
    > hh406637(v=vs.85).aspx
    >
    > I'm happy to discuss any of this as it pertains to writing drivers.
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > ------------------------------**-----------------------------
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.**cfm?name=ListServer
    >
  • SoquelDudeSoquelDude Member Posts: 67
    Thanks, Jake!

    Are there definitions for AOAC and Connected Standby? As with most things,
    I'm confused as to what these are exactly.

    "Jake Oshins" wrote in message news:xxxxx@ntdev...

    As all of you know, Microsoft has shifted it's policies in the last few
    years, asking us not to discuss upcoming products. It's nice, at this
    point, to be able to tell you what we've been working on. For no reason in
    particular, here are some links to the just-updated docs on runtime power
    management in Windows 8, which is what I've been working on for the last
    year or so. It includes support for D3cold in PCI and other buses, as well
    as sub-device, component-level power management.

    http://msdn.microsoft.com/en-us/library/windows/hardware/ff543162(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff543186(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/hh967706(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/hh406637(v=vs.85).aspx

    I'm happy to discuss any of this as it pertains to writing drivers.

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    Good point. I'll ask the doc writer to link to definitions of these.

    AOAC => Always On, Always Connected. It's a usage model for a machine.
    It's never entirely off and never disconnected from networks, unless you
    want it to be. Today's phones and tablets already do this.

    Connected Standby is a state that an AOAC machine idles in. The screen is
    off and the machine appears off to the user, but background computation can
    occasionally occur, particularly when data is received from a network. Thus
    your e-mail can be immediately available when you turn the screen on, Skype
    might be in a mode to answer a call, etc.

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------

    "SoquelDude" wrote in message news:xxxxx@ntdev...

    Thanks, Jake!

    Are there definitions for AOAC and Connected Standby? As with most things,
    I'm confused as to what these are exactly.

    "Jake Oshins" wrote in message news:xxxxx@ntdev...

    As all of you know, Microsoft has shifted it's policies in the last few
    years, asking us not to discuss upcoming products. It's nice, at this
    point, to be able to tell you what we've been working on. For no reason in
    particular, here are some links to the just-updated docs on runtime power
    management in Windows 8, which is what I've been working on for the last
    year or so. It includes support for D3cold in PCI and other buses, as well
    as sub-device, component-level power management.

    http://msdn.microsoft.com/en-us/library/windows/hardware/ff543162(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff543186(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/hh967706(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/hh406637(v=vs.85).aspx

    I'm happy to discuss any of this as it pertains to writing drivers.

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------
  • SoquelDudeSoquelDude Member Posts: 67
    Thanks again, Jake!

    WRT AOAC: Is there a BIOS dependency for this? How can a system be queried
    to determine whether it supports AOAC?

    WRT ConnectedStandby: This appears to be unrelated to device power states
    (e.g., D0, D3). What classes of devices (e.g., USB) typically support this
    mode under Win8?


    "Jake Oshins" wrote in message news:xxxxx@ntdev...

    Good point. I'll ask the doc writer to link to definitions of these.

    AOAC => Always On, Always Connected. It's a usage model for a machine.
    It's never entirely off and never disconnected from networks, unless you
    want it to be. Today's phones and tablets already do this.

    Connected Standby is a state that an AOAC machine idles in. The screen is
    off and the machine appears off to the user, but background computation can
    occasionally occur, particularly when data is received from a network. Thus
    your e-mail can be immediately available when you turn the screen on, Skype
    might be in a mode to answer a call, etc.

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------

    "SoquelDude" wrote in message news:xxxxx@ntdev...

    Thanks, Jake!

    Are there definitions for AOAC and Connected Standby? As with most things,
    I'm confused as to what these are exactly.

    "Jake Oshins" wrote in message news:xxxxx@ntdev...

    As all of you know, Microsoft has shifted it's policies in the last few
    years, asking us not to discuss upcoming products. It's nice, at this
    point, to be able to tell you what we've been working on. For no reason in
    particular, here are some links to the just-updated docs on runtime power
    management in Windows 8, which is what I've been working on for the last
    year or so. It includes support for D3cold in PCI and other buses, as well
    as sub-device, component-level power management.

    http://msdn.microsoft.com/en-us/library/windows/hardware/ff543162(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff543186(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/hh967706(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/hh406637(v=vs.85).aspx

    I'm happy to discuss any of this as it pertains to writing drivers.

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    AOAC requirements are spelled out in ACPI 5.0: http://acpi.info/spec50.htm

    Microsoft requires more than that, however. We're working with the OEMs
    brining tablets to market to ensure that the machines have the attributes
    that they need to work for users in this mode, like low-latency storage
    devices, suitable NICs that can remain connected to WiFi while in D3, audio
    devices which can work largely without the main processor, etc.

    Connected Standby is an attribute of an entire system. Each individual
    device may be in a variety of states. For devices that are not within a
    system-on-chip (SoC) the usual D-states apply, with the addition of runtime
    D3cold support, where power is removed so entirely that the device actually
    disconnects from the bus. A device with no associated wake signal will
    typically idle in D3cold. A device with a wake signal will typically idle
    in the lowest D-state where that wake signal can be triggered.

    For a device within a SoC, there is more ambiguity about which state the
    device may be in while the machine is in Connected Standby. There is a
    negotiation between the device driver and the Power Engine Plug-in (a device
    driver supplied by the SoC vendor.) The device may move, as a whole, to D3,
    or it may move some or all of its components to lower-power states within
    D0.


    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------

    "SoquelDude" wrote in message news:xxxxx@ntdev...

    Thanks again, Jake!

    WRT AOAC: Is there a BIOS dependency for this? How can a system be queried
    to determine whether it supports AOAC?

    WRT ConnectedStandby: This appears to be unrelated to device power states
    (e.g., D0, D3). What classes of devices (e.g., USB) typically support this
    mode under Win8?


    "Jake Oshins" wrote in message news:xxxxx@ntdev...

    Good point. I'll ask the doc writer to link to definitions of these.

    AOAC => Always On, Always Connected. It's a usage model for a machine.
    It's never entirely off and never disconnected from networks, unless you
    want it to be. Today's phones and tablets already do this.

    Connected Standby is a state that an AOAC machine idles in. The screen is
    off and the machine appears off to the user, but background computation can
    occasionally occur, particularly when data is received from a network. Thus
    your e-mail can be immediately available when you turn the screen on, Skype
    might be in a mode to answer a call, etc.

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------

    "SoquelDude" wrote in message news:xxxxx@ntdev...

    Thanks, Jake!

    Are there definitions for AOAC and Connected Standby? As with most things,
    I'm confused as to what these are exactly.

    "Jake Oshins" wrote in message news:xxxxx@ntdev...

    As all of you know, Microsoft has shifted it's policies in the last few
    years, asking us not to discuss upcoming products. It's nice, at this
    point, to be able to tell you what we've been working on. For no reason in
    particular, here are some links to the just-updated docs on runtime power
    management in Windows 8, which is what I've been working on for the last
    year or so. It includes support for D3cold in PCI and other buses, as well
    as sub-device, component-level power management.

    http://msdn.microsoft.com/en-us/library/windows/hardware/ff543162(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff543186(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/hh967706(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/hardware/hh406637(v=vs.85).aspx

    I'm happy to discuss any of this as it pertains to writing drivers.

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------
  • Ivan_RouzanovIvan_Rouzanov Member Posts: 1
    BIOS Dependency: ACPI 5.0 defines a LOW_POWER_S0_IDLE_CAPABLE bit in FADT:
    >>
    "A one informs OSPM that the platform is able to achieve
    power savings in S0 similar to or better than those typically
    achieved in S3. In effect, when this bit is set it indicates that
    the system will achieve no power benefit by making a sleep
    transition to S3."
    >>

    There are obviously a lot of other things BIOS might need to do to support AOAC systems, but LOW_POWER_S0_IDLE_CAPABLE is one important bit.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Hi Jake,

    Can you elaborate a bit?

    > Connected Standby is an attribute of an entire system. Each individual
    > device may be in a variety of states. For devices that are not within a
    > system-on-chip (SoC) the usual D-states apply

    What exactly it means for a device driver? My interest are mainly USB and SPB UMDF drivers. Should they receive Dx IRP in S0 state or how is it expected to work?

    Thanks,

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-504675-
    > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > Sent: Monday, June 04, 2012 1:02 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Runtime power management in Windows 8
    >
    > AOAC requirements are spelled out in ACPI 5.0: http://acpi.info/spec50.htm
    >
    > Microsoft requires more than that, however. We're working with the OEMs
    > brining tablets to market to ensure that the machines have the attributes
    > that they need to work for users in this mode, like low-latency storage
    > devices, suitable NICs that can remain connected to WiFi while in D3, audio
    > devices which can work largely without the main processor, etc.
    >
    > Connected Standby is an attribute of an entire system. Each individual
    > device may be in a variety of states. For devices that are not within a
    > system-on-chip (SoC) the usual D-states apply, with the addition of runtime
    > D3cold support, where power is removed so entirely that the device actually
    > disconnects from the bus. A device with no associated wake signal will
    > typically idle in D3cold. A device with a wake signal will typically idle
    > in the lowest D-state where that wake signal can be triggered.
    >
    > For a device within a SoC, there is more ambiguity about which state the
    > device may be in while the machine is in Connected Standby. There is a
    > negotiation between the device driver and the Power Engine Plug-in (a
    > device
    > driver supplied by the SoC vendor.) The device may move, as a whole, to D3,
    > or it may move some or all of its components to lower-power states within
    > D0.
    >
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "SoquelDude" wrote in message news:xxxxx@ntdev...
    >
    > Thanks again, Jake!
    >
    > WRT AOAC: Is there a BIOS dependency for this? How can a system be
    > queried
    > to determine whether it supports AOAC?
    >
    > WRT ConnectedStandby: This appears to be unrelated to device power
    > states
    > (e.g., D0, D3). What classes of devices (e.g., USB) typically support this
    > mode under Win8?
    >
    >
    > "Jake Oshins" wrote in message news:xxxxx@ntdev...
    >
    > Good point. I'll ask the doc writer to link to definitions of these.
    >
    > AOAC => Always On, Always Connected. It's a usage model for a machine.
    > It's never entirely off and never disconnected from networks, unless you
    > want it to be. Today's phones and tablets already do this.
    >
    > Connected Standby is a state that an AOAC machine idles in. The screen is
    > off and the machine appears off to the user, but background computation
    > can
    > occasionally occur, particularly when data is received from a network. Thus
    > your e-mail can be immediately available when you turn the screen on,
    > Skype
    > might be in a mode to answer a call, etc.
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "SoquelDude" wrote in message news:xxxxx@ntdev...
    >
    > Thanks, Jake!
    >
    > Are there definitions for AOAC and Connected Standby? As with most things,
    > I'm confused as to what these are exactly.
    >
    > "Jake Oshins" wrote in message news:xxxxx@ntdev...
    >
    > As all of you know, Microsoft has shifted it's policies in the last few
    > years, asking us not to discuss upcoming products. It's nice, at this
    > point, to be able to tell you what we've been working on. For no reason in
    > particular, here are some links to the just-updated docs on runtime power
    > management in Windows 8, which is what I've been working on for the last
    > year or so. It includes support for D3cold in PCI and other buses, as well
    > as sub-device, component-level power management.
    >
    > http://msdn.microsoft.com/en-
    > us/library/windows/hardware/ff543162(v=vs.85).aspx
    > http://msdn.microsoft.com/en-
    > us/library/windows/hardware/ff543186(v=vs.85).aspx
    > http://msdn.microsoft.com/en-
    > us/library/windows/hardware/hh967706(v=vs.85).aspx
    > http://msdn.microsoft.com/en-
    > us/library/windows/hardware/hh406637(v=vs.85).aspx
    >
    > I'm happy to discuss any of this as it pertains to writing drivers.
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    The links at the bottom of this thread were intended to explain what it
    means for a device driver. I'm happy to elaborate, but I'd rather do that
    from a specific question, rather than try to write a dissertation that
    recapitulates the MSDN content.

    I will say, though, that Windows itself isn't structured around the notion
    of "USB" or "SPB" drivers. It's structured around the notion of storage
    drivers, input drivers, sensor drivers, etc. So when you ask "should a USB
    driver receive a Dx IRP in S0," the answer has to come in the context of
    "what kind of USB device are we talking about?" In general, the answer to
    your question is yes, extra-SoC devices (those not integrated on the
    processor itself) need to shut themselves off when they are not being
    actively used. SoC-integrated devices need runtime power management too,
    but their usage model is somewhat more complicated. Exactly who is the
    power policy owner for each stack, which is to say who sends that Dx IRP,
    varies a lot by device class.

    Care to ask a specific question?

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------

    "Vodicka, Michal" wrote in message news:xxxxx@ntdev...

    Hi Jake,

    Can you elaborate a bit?

    > Connected Standby is an attribute of an entire system. Each individual
    > device may be in a variety of states. For devices that are not within a
    > system-on-chip (SoC) the usual D-states apply

    What exactly it means for a device driver? My interest are mainly USB and
    SPB UMDF drivers. Should they receive Dx IRP in S0 state or how is it
    expected to work?

    Thanks,

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-504675-
    > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > Sent: Monday, June 04, 2012 1:02 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Runtime power management in Windows 8
    >
    > AOAC requirements are spelled out in ACPI 5.0:
    > http://acpi.info/spec50.htm
    >
    > Microsoft requires more than that, however. We're working with the OEMs
    > brining tablets to market to ensure that the machines have the attributes
    > that they need to work for users in this mode, like low-latency storage
    > devices, suitable NICs that can remain connected to WiFi while in D3,
    > audio
    > devices which can work largely without the main processor, etc.
    >
    > Connected Standby is an attribute of an entire system. Each individual
    > device may be in a variety of states. For devices that are not within a
    > system-on-chip (SoC) the usual D-states apply, with the addition of
    > runtime
    > D3cold support, where power is removed so entirely that the device
    > actually
    > disconnects from the bus. A device with no associated wake signal will
    > typically idle in D3cold. A device with a wake signal will typically idle
    > in the lowest D-state where that wake signal can be triggered.
    >
    > For a device within a SoC, there is more ambiguity about which state the
    > device may be in while the machine is in Connected Standby. There is a
    > negotiation between the device driver and the Power Engine Plug-in (a
    > device
    > driver supplied by the SoC vendor.) The device may move, as a whole, to
    > D3,
    > or it may move some or all of its components to lower-power states within
    > D0.
    >
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "SoquelDude" wrote in message news:xxxxx@ntdev...
    >
    > Thanks again, Jake!
    >
    > WRT AOAC: Is there a BIOS dependency for this? How can a system be
    > queried
    > to determine whether it supports AOAC?
    >
    > WRT ConnectedStandby: This appears to be unrelated to device power
    > states
    > (e.g., D0, D3). What classes of devices (e.g., USB) typically support this
    > mode under Win8?
    >
    >
    > "Jake Oshins" wrote in message news:xxxxx@ntdev...
    >
    > Good point. I'll ask the doc writer to link to definitions of these.
    >
    > AOAC => Always On, Always Connected. It's a usage model for a machine.
    > It's never entirely off and never disconnected from networks, unless you
    > want it to be. Today's phones and tablets already do this.
    >
    > Connected Standby is a state that an AOAC machine idles in. The screen is
    > off and the machine appears off to the user, but background computation
    > can
    > occasionally occur, particularly when data is received from a network.
    > Thus
    > your e-mail can be immediately available when you turn the screen on,
    > Skype
    > might be in a mode to answer a call, etc.
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "SoquelDude" wrote in message news:xxxxx@ntdev...
    >
    > Thanks, Jake!
    >
    > Are there definitions for AOAC and Connected Standby? As with most things,
    > I'm confused as to what these are exactly.
    >
    > "Jake Oshins" wrote in message news:xxxxx@ntdev...
    >
    > As all of you know, Microsoft has shifted it's policies in the last few
    > years, asking us not to discuss upcoming products. It's nice, at this
    > point, to be able to tell you what we've been working on. For no reason
    > in
    > particular, here are some links to the just-updated docs on runtime power
    > management in Windows 8, which is what I've been working on for the last
    > year or so. It includes support for D3cold in PCI and other buses, as
    > well
    > as sub-device, component-level power management.
    >
    > http://msdn.microsoft.com/en-
    > us/library/windows/hardware/ff543162(v=vs.85).aspx
    > http://msdn.microsoft.com/en-
    > us/library/windows/hardware/ff543186(v=vs.85).aspx
    > http://msdn.microsoft.com/en-
    > us/library/windows/hardware/hh967706(v=vs.85).aspx
    > http://msdn.microsoft.com/en-
    > us/library/windows/hardware/hh406637(v=vs.85).aspx
    >
    > I'm happy to discuss any of this as it pertains to writing drivers.
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and
    confidential use of the designated recipient(s) named above. To the extent
    the recipient(s) is/are bound by a non-disclosure agreement, or other
    agreement that contains an obligation of confidentiality, with AuthenTec,
    then this message and/or any attachments shall be considered confidential
    information and subject to the confidentiality terms of that agreement. If
    the reader of this message is not the intended recipient named above, you
    are notified that you have received this document in error, and any review,
    dissemination, distribution or copying of this message is strictly
    prohibited. If you have received this document in error, please delete the
    original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    No problem with specific question :)

    I'm writing USB and SPB drivers for our fingerprint sensors. SPB is for SoC platforms but not integrated to SoC itself. USB is for general use which might (rather unlikely) include SoC platforms. Both drivers are UMDF, Biometric class, exporting WBDI interface and used by WinBio service. Both should be power policy owners for their stacks if something didn't change.

    At Win7 USB device uses selective suspend to save power i.e. D2 state. Our devices are mostly in finger detect mode which mean power draw withing suspended USB limits (less than 0.5 mA I think). The devices conform to USB 2.0 specs (full speed).

    My question is generally what should we do to support runtime power management. I've read all the docs you pointed out, understand the general concept but don't see consequences for our drivers.

    BTW, I have a SoC platform where I can (hopefully) test S0i3 state in Intel terminology (if it is the same thing as I hope).

    Thanks,

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506762-
    > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > Sent: Thursday, June 28, 2012 2:33 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Runtime power management in Windows 8
    >
    > The links at the bottom of this thread were intended to explain what it
    > means for a device driver. I'm happy to elaborate, but I'd rather do that
    > from a specific question, rather than try to write a dissertation that
    > recapitulates the MSDN content.
    >
    > I will say, though, that Windows itself isn't structured around the notion
    > of "USB" or "SPB" drivers. It's structured around the notion of storage
    > drivers, input drivers, sensor drivers, etc. So when you ask "should a USB
    > driver receive a Dx IRP in S0," the answer has to come in the context of
    > "what kind of USB device are we talking about?" In general, the answer to
    > your question is yes, extra-SoC devices (those not integrated on the
    > processor itself) need to shut themselves off when they are not being
    > actively used. SoC-integrated devices need runtime power management
    > too,
    > but their usage model is somewhat more complicated. Exactly who is the
    > power policy owner for each stack, which is to say who sends that Dx IRP,
    > varies a lot by device class.
    >
    > Care to ask a specific question?
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    >
    > Hi Jake,
    >
    > Can you elaborate a bit?
    >
    > > Connected Standby is an attribute of an entire system. Each individual
    > > device may be in a variety of states. For devices that are not within a
    > > system-on-chip (SoC) the usual D-states apply
    >
    > What exactly it means for a device driver? My interest are mainly USB and
    > SPB UMDF drivers. Should they receive Dx IRP in S0 state or how is it
    > expected to work?
    >
    > Thanks,
    >
    > Michal
    >
    > > -----Original Message-----
    > > From: xxxxx@lists.osr.com [mailto:bounce-504675-
    > > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > > Sent: Monday, June 04, 2012 1:02 AM
    > > To: Windows System Software Devs Interest List
    > > Subject: Re:[ntdev] Runtime power management in Windows 8
    > >
    > > AOAC requirements are spelled out in ACPI 5.0:
    > > http://acpi.info/spec50.htm
    > >
    > > Microsoft requires more than that, however. We're working with the
    > OEMs
    > > brining tablets to market to ensure that the machines have the attributes
    > > that they need to work for users in this mode, like low-latency storage
    > > devices, suitable NICs that can remain connected to WiFi while in D3,
    > > audio
    > > devices which can work largely without the main processor, etc.
    > >
    > > Connected Standby is an attribute of an entire system. Each individual
    > > device may be in a variety of states. For devices that are not within a
    > > system-on-chip (SoC) the usual D-states apply, with the addition of
    > > runtime
    > > D3cold support, where power is removed so entirely that the device
    > > actually
    > > disconnects from the bus. A device with no associated wake signal will
    > > typically idle in D3cold. A device with a wake signal will typically idle
    > > in the lowest D-state where that wake signal can be triggered.
    > >
    > > For a device within a SoC, there is more ambiguity about which state the
    > > device may be in while the machine is in Connected Standby. There is a
    > > negotiation between the device driver and the Power Engine Plug-in (a
    > > device
    > > driver supplied by the SoC vendor.) The device may move, as a whole, to
    > > D3,
    > > or it may move some or all of its components to lower-power states within
    > > D0.
    > >
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > > "SoquelDude" wrote in message news:xxxxx@ntdev...
    > >
    > > Thanks again, Jake!
    > >
    > > WRT AOAC: Is there a BIOS dependency for this? How can a system be
    > > queried
    > > to determine whether it supports AOAC?
    > >
    > > WRT ConnectedStandby: This appears to be unrelated to device power
    > > states
    > > (e.g., D0, D3). What classes of devices (e.g., USB) typically support this
    > > mode under Win8?
    > >
    > >
    > > "Jake Oshins" wrote in message news:xxxxx@ntdev...
    > >
    > > Good point. I'll ask the doc writer to link to definitions of these.
    > >
    > > AOAC => Always On, Always Connected. It's a usage model for a machine.
    > > It's never entirely off and never disconnected from networks, unless you
    > > want it to be. Today's phones and tablets already do this.
    > >
    > > Connected Standby is a state that an AOAC machine idles in. The screen is
    > > off and the machine appears off to the user, but background computation
    > > can
    > > occasionally occur, particularly when data is received from a network.
    > > Thus
    > > your e-mail can be immediately available when you turn the screen on,
    > > Skype
    > > might be in a mode to answer a call, etc.
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > > "SoquelDude" wrote in message news:xxxxx@ntdev...
    > >
    > > Thanks, Jake!
    > >
    > > Are there definitions for AOAC and Connected Standby? As with most
    > things,
    > > I'm confused as to what these are exactly.
    > >
    > > "Jake Oshins" wrote in message news:xxxxx@ntdev...
    > >
    > > As all of you know, Microsoft has shifted it's policies in the last few
    > > years, asking us not to discuss upcoming products. It's nice, at this
    > > point, to be able to tell you what we've been working on. For no reason
    > > in
    > > particular, here are some links to the just-updated docs on runtime power
    > > management in Windows 8, which is what I've been working on for the last
    > > year or so. It includes support for D3cold in PCI and other buses, as
    > > well
    > > as sub-device, component-level power management.
    > >
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/ff543162(v=vs.85).aspx
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/ff543186(v=vs.85).aspx
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/hh967706(v=vs.85).aspx
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/hh406637(v=vs.85).aspx
    > >
    > > I'm happy to discuss any of this as it pertains to writing drivers.
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > >
    > > ---
    > > NTDEV is sponsored by OSR
    > >
    > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > http://www.osr.com/seminars
    > >
    > > To unsubscribe, visit the List Server section of OSR Online at
    > > http://www.osronline.com/page.cfm?name=ListServer
    >
    > NOTE: The information in this message is intended for the personal and
    > confidential use of the designated recipient(s) named above. To the extent
    > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > agreement that contains an obligation of confidentiality, with AuthenTec,
    > then this message and/or any attachments shall be considered confidential
    > information and subject to the confidentiality terms of that agreement. If
    > the reader of this message is not the intended recipient named above, you
    > are notified that you have received this document in error, and any review,
    > dissemination, distribution or copying of this message is strictly
    > prohibited. If you have received this document in error, please delete the
    > original message and notify the sender immediately.
    > Thank You!
    > AuthenTec, Inc. http://www.authentec.com/
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    To hit the power goals of a SoC system in connected standby, selective
    suspend is not sufficient. You'll need to support D3cold. To do that,
    you'll need some kind of side-band wake signal that allows your device to
    trigger wake when a user touches it without any power on the USB itself. Do
    you have that?



    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------

    "Vodicka, Michal" wrote in message news:xxxxx@ntdev...

    No problem with specific question :)

    I'm writing USB and SPB drivers for our fingerprint sensors. SPB is for SoC
    platforms but not integrated to SoC itself. USB is for general use which
    might (rather unlikely) include SoC platforms. Both drivers are UMDF,
    Biometric class, exporting WBDI interface and used by WinBio service. Both
    should be power policy owners for their stacks if something didn't change.

    At Win7 USB device uses selective suspend to save power i.e. D2 state. Our
    devices are mostly in finger detect mode which mean power draw withing
    suspended USB limits (less than 0.5 mA I think). The devices conform to USB
    2.0 specs (full speed).

    My question is generally what should we do to support runtime power
    management. I've read all the docs you pointed out, understand the general
    concept but don't see consequences for our drivers.

    BTW, I have a SoC platform where I can (hopefully) test S0i3 state in Intel
    terminology (if it is the same thing as I hope).

    Thanks,

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506762-
    > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > Sent: Thursday, June 28, 2012 2:33 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Runtime power management in Windows 8
    >
    > The links at the bottom of this thread were intended to explain what it
    > means for a device driver. I'm happy to elaborate, but I'd rather do that
    > from a specific question, rather than try to write a dissertation that
    > recapitulates the MSDN content.
    >
    > I will say, though, that Windows itself isn't structured around the notion
    > of "USB" or "SPB" drivers. It's structured around the notion of storage
    > drivers, input drivers, sensor drivers, etc. So when you ask "should a
    > USB
    > driver receive a Dx IRP in S0," the answer has to come in the context of
    > "what kind of USB device are we talking about?" In general, the answer to
    > your question is yes, extra-SoC devices (those not integrated on the
    > processor itself) need to shut themselves off when they are not being
    > actively used. SoC-integrated devices need runtime power management
    > too,
    > but their usage model is somewhat more complicated. Exactly who is the
    > power policy owner for each stack, which is to say who sends that Dx IRP,
    > varies a lot by device class.
    >
    > Care to ask a specific question?
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    >
    > Hi Jake,
    >
    > Can you elaborate a bit?
    >
    > > Connected Standby is an attribute of an entire system. Each individual
    > > device may be in a variety of states. For devices that are not within a
    > > system-on-chip (SoC) the usual D-states apply
    >
    > What exactly it means for a device driver? My interest are mainly USB and
    > SPB UMDF drivers. Should they receive Dx IRP in S0 state or how is it
    > expected to work?
    >
    > Thanks,
    >
    > Michal
    >
    > > -----Original Message-----
    > > From: xxxxx@lists.osr.com [mailto:bounce-504675-
    > > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > > Sent: Monday, June 04, 2012 1:02 AM
    > > To: Windows System Software Devs Interest List
    > > Subject: Re:[ntdev] Runtime power management in Windows 8
    > >
    > > AOAC requirements are spelled out in ACPI 5.0:
    > > http://acpi.info/spec50.htm
    > >
    > > Microsoft requires more than that, however. We're working with the
    > OEMs
    > > brining tablets to market to ensure that the machines have the
    > > attributes
    > > that they need to work for users in this mode, like low-latency storage
    > > devices, suitable NICs that can remain connected to WiFi while in D3,
    > > audio
    > > devices which can work largely without the main processor, etc.
    > >
    > > Connected Standby is an attribute of an entire system. Each individual
    > > device may be in a variety of states. For devices that are not within a
    > > system-on-chip (SoC) the usual D-states apply, with the addition of
    > > runtime
    > > D3cold support, where power is removed so entirely that the device
    > > actually
    > > disconnects from the bus. A device with no associated wake signal will
    > > typically idle in D3cold. A device with a wake signal will typically
    > > idle
    > > in the lowest D-state where that wake signal can be triggered.
    > >
    > > For a device within a SoC, there is more ambiguity about which state the
    > > device may be in while the machine is in Connected Standby. There is a
    > > negotiation between the device driver and the Power Engine Plug-in (a
    > > device
    > > driver supplied by the SoC vendor.) The device may move, as a whole, to
    > > D3,
    > > or it may move some or all of its components to lower-power states
    > > within
    > > D0.
    > >
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > > "SoquelDude" wrote in message news:xxxxx@ntdev...
    > >
    > > Thanks again, Jake!
    > >
    > > WRT AOAC: Is there a BIOS dependency for this? How can a system be
    > > queried
    > > to determine whether it supports AOAC?
    > >
    > > WRT ConnectedStandby: This appears to be unrelated to device power
    > > states
    > > (e.g., D0, D3). What classes of devices (e.g., USB) typically support
    > > this
    > > mode under Win8?
    > >
    > >
    > > "Jake Oshins" wrote in message news:xxxxx@ntdev...
    > >
    > > Good point. I'll ask the doc writer to link to definitions of these.
    > >
    > > AOAC => Always On, Always Connected. It's a usage model for a machine.
    > > It's never entirely off and never disconnected from networks, unless you
    > > want it to be. Today's phones and tablets already do this.
    > >
    > > Connected Standby is a state that an AOAC machine idles in. The screen
    > > is
    > > off and the machine appears off to the user, but background computation
    > > can
    > > occasionally occur, particularly when data is received from a network.
    > > Thus
    > > your e-mail can be immediately available when you turn the screen on,
    > > Skype
    > > might be in a mode to answer a call, etc.
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > > "SoquelDude" wrote in message news:xxxxx@ntdev...
    > >
    > > Thanks, Jake!
    > >
    > > Are there definitions for AOAC and Connected Standby? As with most
    > things,
    > > I'm confused as to what these are exactly.
    > >
    > > "Jake Oshins" wrote in message news:xxxxx@ntdev...
    > >
    > > As all of you know, Microsoft has shifted it's policies in the last few
    > > years, asking us not to discuss upcoming products. It's nice, at this
    > > point, to be able to tell you what we've been working on. For no reason
    > > in
    > > particular, here are some links to the just-updated docs on runtime
    > > power
    > > management in Windows 8, which is what I've been working on for the last
    > > year or so. It includes support for D3cold in PCI and other buses, as
    > > well
    > > as sub-device, component-level power management.
    > >
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/ff543162(v=vs.85).aspx
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/ff543186(v=vs.85).aspx
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/hh967706(v=vs.85).aspx
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/hh406637(v=vs.85).aspx
    > >
    > > I'm happy to discuss any of this as it pertains to writing drivers.
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > >
    > > ---
    > > NTDEV is sponsored by OSR
    > >
    > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > http://www.osr.com/seminars
    > >
    > > To unsubscribe, visit the List Server section of OSR Online at
    > > http://www.osronline.com/page.cfm?name=ListServer
    >
    > NOTE: The information in this message is intended for the personal and
    > confidential use of the designated recipient(s) named above. To the extent
    > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > agreement that contains an obligation of confidentiality, with AuthenTec,
    > then this message and/or any attachments shall be considered confidential
    > information and subject to the confidentiality terms of that agreement.
    > If
    > the reader of this message is not the intended recipient named above, you
    > are notified that you have received this document in error, and any
    > review,
    > dissemination, distribution or copying of this message is strictly
    > prohibited. If you have received this document in error, please delete the
    > original message and notify the sender immediately.
    > Thank You!
    > AuthenTec, Inc. http://www.authentec.com/
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and
    confidential use of the designated recipient(s) named above. To the extent
    the recipient(s) is/are bound by a non-disclosure agreement, or other
    agreement that contains an obligation of confidentiality, with AuthenTec,
    then this message and/or any attachments shall be considered confidential
    information and subject to the confidentiality terms of that agreement. If
    the reader of this message is not the intended recipient named above, you
    are notified that you have received this document in error, and any review,
    dissemination, distribution or copying of this message is strictly
    prohibited. If you have received this document in error, please delete the
    original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    No. For SPB devices we have a GPIO used as an interrupt which might be probably configured as wake signal. Anyway, we need at least some power to be able to detect finger touch...

    To be clear, main target for SPB devices is SoC platforms and for USB standard PCs. But customers are asking is we can support "runtime D3" even there.

    Michal

    Sent from my HTC

    -----Original Message-----
    From: Jake Oshins <xxxxx@windows.microsoft.com>
    Sent: Thursday, June 28, 2012 3:47
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: Re:[ntdev] Runtime power management in Windows 8


    To hit the power goals of a SoC system in connected standby, selective
    suspend is not sufficient. You'll need to support D3cold. To do that,
    you'll need some kind of side-band wake signal that allows your device to
    trigger wake when a user touches it without any power on the USB itself. Do
    you have that?



    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------

    "Vodicka, Michal" wrote in message news:xxxxx@ntdev...

    No problem with specific question :)

    I'm writing USB and SPB drivers for our fingerprint sensors. SPB is for SoC
    platforms but not integrated to SoC itself. USB is for general use which
    might (rather unlikely) include SoC platforms. Both drivers are UMDF,
    Biometric class, exporting WBDI interface and used by WinBio service. Both
    should be power policy owners for their stacks if something didn't change.

    At Win7 USB device uses selective suspend to save power i.e. D2 state. Our
    devices are mostly in finger detect mode which mean power draw withing
    suspended USB limits (less than 0.5 mA I think). The devices conform to USB
    2.0 specs (full speed).

    My question is generally what should we do to support runtime power
    management. I've read all the docs you pointed out, understand the general
    concept but don't see consequences for our drivers.

    BTW, I have a SoC platform where I can (hopefully) test S0i3 state in Intel
    terminology (if it is the same thing as I hope).

    Thanks,

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506762-
    > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > Sent: Thursday, June 28, 2012 2:33 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Runtime power management in Windows 8
    >
    > The links at the bottom of this thread were intended to explain what it
    > means for a device driver. I'm happy to elaborate, but I'd rather do that
    > from a specific question, rather than try to write a dissertation that
    > recapitulates the MSDN content.
    >
    > I will say, though, that Windows itself isn't structured around the notion
    > of "USB" or "SPB" drivers. It's structured around the notion of storage
    > drivers, input drivers, sensor drivers, etc. So when you ask "should a
    > USB
    > driver receive a Dx IRP in S0," the answer has to come in the context of
    > "what kind of USB device are we talking about?" In general, the answer to
    > your question is yes, extra-SoC devices (those not integrated on the
    > processor itself) need to shut themselves off when they are not being
    > actively used. SoC-integrated devices need runtime power management
    > too,
    > but their usage model is somewhat more complicated. Exactly who is the
    > power policy owner for each stack, which is to say who sends that Dx IRP,
    > varies a lot by device class.
    >
    > Care to ask a specific question?
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    >
    > Hi Jake,
    >
    > Can you elaborate a bit?
    >
    > > Connected Standby is an attribute of an entire system. Each individual
    > > device may be in a variety of states. For devices that are not within a
    > > system-on-chip (SoC) the usual D-states apply
    >
    > What exactly it means for a device driver? My interest are mainly USB and
    > SPB UMDF drivers. Should they receive Dx IRP in S0 state or how is it
    > expected to work?
    >
    > Thanks,
    >
    > Michal
    >
    > > -----Original Message-----
    > > From: xxxxx@lists.osr.com [mailto:bounce-504675-
    > > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > > Sent: Monday, June 04, 2012 1:02 AM
    > > To: Windows System Software Devs Interest List
    > > Subject: Re:[ntdev] Runtime power management in Windows 8
    > >
    > > AOAC requirements are spelled out in ACPI 5.0:
    > > http://acpi.info/spec50.htm
    > >
    > > Microsoft requires more than that, however. We're working with the
    > OEMs
    > > brining tablets to market to ensure that the machines have the
    > > attributes
    > > that they need to work for users in this mode, like low-latency storage
    > > devices, suitable NICs that can remain connected to WiFi while in D3,
    > > audio
    > > devices which can work largely without the main processor, etc.
    > >
    > > Connected Standby is an attribute of an entire system. Each individual
    > > device may be in a variety of states. For devices that are not within a
    > > system-on-chip (SoC) the usual D-states apply, with the addition of
    > > runtime
    > > D3cold support, where power is removed so entirely that the device
    > > actually
    > > disconnects from the bus. A device with no associated wake signal will
    > > typically idle in D3cold. A device with a wake signal will typically
    > > idle
    > > in the lowest D-state where that wake signal can be triggered.
    > >
    > > For a device within a SoC, there is more ambiguity about which state the
    > > device may be in while the machine is in Connected Standby. There is a
    > > negotiation between the device driver and the Power Engine Plug-in (a
    > > device
    > > driver supplied by the SoC vendor.) The device may move, as a whole, to
    > > D3,
    > > or it may move some or all of its components to lower-power states
    > > within
    > > D0.
    > >
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > > "SoquelDude" wrote in message news:xxxxx@ntdev...
    > >
    > > Thanks again, Jake!
    > >
    > > WRT AOAC: Is there a BIOS dependency for this? How can a system be
    > > queried
    > > to determine whether it supports AOAC?
    > >
    > > WRT ConnectedStandby: This appears to be unrelated to device power
    > > states
    > > (e.g., D0, D3). What classes of devices (e.g., USB) typically support
    > > this
    > > mode under Win8?
    > >
    > >
    > > "Jake Oshins" wrote in message news:xxxxx@ntdev...
    > >
    > > Good point. I'll ask the doc writer to link to definitions of these.
    > >
    > > AOAC => Always On, Always Connected. It's a usage model for a machine.
    > > It's never entirely off and never disconnected from networks, unless you
    > > want it to be. Today's phones and tablets already do this.
    > >
    > > Connected Standby is a state that an AOAC machine idles in. The screen
    > > is
    > > off and the machine appears off to the user, but background computation
    > > can
    > > occasionally occur, particularly when data is received from a network.
    > > Thus
    > > your e-mail can be immediately available when you turn the screen on,
    > > Skype
    > > might be in a mode to answer a call, etc.
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > > "SoquelDude" wrote in message news:xxxxx@ntdev...
    > >
    > > Thanks, Jake!
    > >
    > > Are there definitions for AOAC and Connected Standby? As with most
    > things,
    > > I'm confused as to what these are exactly.
    > >
    > > "Jake Oshins" wrote in message news:xxxxx@ntdev...
    > >
    > > As all of you know, Microsoft has shifted it's policies in the last few
    > > years, asking us not to discuss upcoming products. It's nice, at this
    > > point, to be able to tell you what we've been working on. For no reason
    > > in
    > > particular, here are some links to the just-updated docs on runtime
    > > power
    > > management in Windows 8, which is what I've been working on for the last
    > > year or so. It includes support for D3cold in PCI and other buses, as
    > > well
    > > as sub-device, component-level power management.
    > >
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/ff543162(v=vs.85).aspx
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/ff543186(v=vs.85).aspx
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/hh967706(v=vs.85).aspx
    > > http://msdn.microsoft.com/en-
    > > us/library/windows/hardware/hh406637(v=vs.85).aspx
    > >
    > > I'm happy to discuss any of this as it pertains to writing drivers.
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > >
    > > ---
    > > NTDEV is sponsored by OSR
    > >
    > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > http://www.osr.com/seminars
    > >
    > > To unsubscribe, visit the List Server section of OSR Online at
    > > http://www.osronline.com/page.cfm?name=ListServer
    >
    > NOTE: The information in this message is intended for the personal and
    > confidential use of the designated recipient(s) named above. To the extent
    > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > agreement that contains an obligation of confidentiality, with AuthenTec,
    > then this message and/or any attachments shall be considered confidential
    > information and subject to the confidentiality terms of that agreement.
    > If
    > the reader of this message is not the intended recipient named above, you
    > are notified that you have received this document in error, and any
    > review,
    > dissemination, distribution or copying of this message is strictly
    > prohibited. If you have received this document in error, please delete the
    > original message and notify the sender immediately.
    > Thank You!
    > AuthenTec, Inc. http://www.authentec.com/
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and
    confidential use of the designated recipient(s) named above. To the extent
    the recipient(s) is/are bound by a non-disclosure agreement, or other
    agreement that contains an obligation of confidentiality, with AuthenTec,
    then this message and/or any attachments shall be considered confidential
    information and subject to the confidentiality terms of that agreement. If
    the reader of this message is not the intended recipient named above, you
    are notified that you have received this document in error, and any review,
    dissemination, distribution or copying of this message is strictly
    prohibited. If you have received this document in error, please delete the
    original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/


    ---
    NTDEV is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,265
    <ASIDE>
    This (the SPB/GPIO sensor on SoC issue) is a nice clear and specific, question. I'm not answering here because I'm looking forward to Jake's answer to test *my* understanding of how this is supposed to be done.

    Peter
    OSR
    </ASIDE>

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    What I find strange is the fact it isn't clearly described in docs. I'm glad for general description of concept in the links Jake originally posted but I'm missing solution for specific cases/stacks. It looks like very important topic and how is driver developer expected to implement it correctly when doesn't know what should be done? We should know at least the designer/architect intentions.

    For example I found I'm quite unsure who should be power policy owner for SPB stack. It differs from other stacks because there is SPB controller driver and function device driver opens it as remote target.

    Well, maybe I'm missing something. Unfortunately, there is a lot of acronyms related to runtime power management (connected standby, AOAC, runtime D3...) which were probably created by marketing and their meaning and relations are unclear and in turn searching docs may not return desired results.

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506829-
    > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    > Sent: Thursday, June 28, 2012 5:57 PM
    > To: Windows System Software Devs Interest List
    > Subject: RE:[ntdev] Runtime power management in Windows 8
    >
    > <ASIDE>
    > This (the SPB/GPIO sensor on SoC issue) is a nice clear and specific, question.
    > I'm not answering here because I'm looking forward to Jake's answer to test
    > *my* understanding of how this is supposed to be done.
    >
    > Peter
    > OSR
    > </ASIDE>
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,265
    <quote>
    It differs from other stacks because there is SPB controller driver and
    function device driver opens it as remote target
    </quote>

    This is tied to what I think is one of the most interesting and significant architectural changes in Win8 in my mind.

    Prior to Win8, we always had devices in a branch of the device tree that terminated in a single place. A device got its data, its power, and its interrupts from a single place. The model, really, was PCI. Your bus driver is responsible for giving you your interrupts, provides the hardware resources from which you receive your data, and can manipulate the power on the slot into which your device is plugged. All relatively simple.

    Sure, we've attempted to deal with cross-branch power dependencies and such things, but never truly successfully.

    Enter Win8. NOW, your device can get its data from the I2C bus, gets its interrupts from one ore more GPIO lines, and the power? Well, the power for your device is probably controlled by somebody entirely different. And possibly, but not necessarily, the power for the I2C (where you get your data) and the power for the GPIO (where you get your interrupt) is supplied by somebody else yet.

    You get a very interesting set of relationships, especially regarding power.

    When you combine this with the fact that your device can have multiple "functional" power states within D0, and very rapidly transition into and outof these functional power states, you get some very interesting power management capabilities and issues.

    THEN you need to factor-in WAKE, which is what you're (mostly) asking about here.

    Whew!

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > You get a very interesting set of relationships, especially regarding power.

    Yes, this is what I mean. Interesting and it is unclear who is responsible for what. Currently I have SPI device but it is the same for I2C, data lines are separate from power ones.

    As a side note I like SPB architecture. One driver can be used for both I2C and SPI devices with almost no additional work.

    > THEN you need to factor-in WAKE, which is what you're (mostly) asking about here.

    Actually, wake is only part of the question. First I'd need to know how should my driver decide when to power off the device. When user of phone/tablet presses power button, the system should remain in S0 and minimize power consumption. Turn off display and all unnecessary devices. One of my questions is how is the driver notified about this event? Well, I'm just preparing experiment which could reveal it but I have a feeling it isn't the right way how to get such an info ;-)

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506849-
    > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    > Sent: Thursday, June 28, 2012 8:32 PM
    > To: Windows System Software Devs Interest List
    > Subject: RE:[ntdev] Runtime power management in Windows 8
    >
    > <quote>
    > It differs from other stacks because there is SPB controller driver and
    > function device driver opens it as remote target
    > </quote>
    >
    > This is tied to what I think is one of the most interesting and significant
    > architectural changes in Win8 in my mind.
    >
    > Prior to Win8, we always had devices in a branch of the device tree that
    > terminated in a single place. A device got its data, its power, and its
    > interrupts from a single place. The model, really, was PCI. Your bus driver is
    > responsible for giving you your interrupts, provides the hardware resources
    > from which you receive your data, and can manipulate the power on the slot
    > into which your device is plugged. All relatively simple.
    >
    > Sure, we've attempted to deal with cross-branch power dependencies and
    > such things, but never truly successfully.
    >
    > Enter Win8. NOW, your device can get its data from the I2C bus, gets its
    > interrupts from one ore more GPIO lines, and the power? Well, the power
    > for your device is probably controlled by somebody entirely different. And
    > possibly, but not necessarily, the power for the I2C (where you get your
    > data) and the power for the GPIO (where you get your interrupt) is supplied
    > by somebody else yet.
    >
    > You get a very interesting set of relationships, especially regarding power.
    >
    > When you combine this with the fact that your device can have multiple
    > "functional" power states within D0, and very rapidly transition into and
    > outof these functional power states, you get some very interesting power
    > management capabilities and issues.
    >
    > THEN you need to factor-in WAKE, which is what you're (mostly) asking about
    > here.
    >
    > Whew!
    >
    > Peter
    > OSR
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    You're looking at it in a way that I would have recommended against even
    before Windows 8. You seem to think "system is leaving S0" meant "turn off
    my device." I do admit that most people viewed it that way, and furthermore
    that before WDF, that was the only reasonable view to take.

    But since the introduction of WDF, we've tried to enable you to think about
    the problem differently. Leave your device turned off except when it needs
    to be turned on, even when the system is in S0. Using KMDF as an example,
    call WdfDeviceAssignS0IdleSettings and then configure one or more power
    managed queues. Your device will remain turned on when there is actual work
    to do. If the reasons that it needs to be turned on can't be represented
    with WDFREQUESTs, then use WdfDeviceStopIdle and WdfDeviceResumeIdle.

    When you're targeting very aggressive runtime power management in machines
    that support an always-on, always-connected model, use
    WdfDeviceAssignS0IdleSettings with a "system managed idle timeout." It's
    one of the parameters to the KMDF 1.11 version of the parameter struct.

    Furthermore, you can integrate with the new runtime power framework, PoFx,
    by calling WdfDeviceWdmAssignPowerFrameworkSettings. This will enable an
    even lighter-weight power management model, one which is also available
    through WDM, though I won't cover that here. The basic idea is that you
    mark your device as necessary or not necessary by calling WdfDeviceStopIdle
    and WdfResumeIdle. If your device has multiple independently manageable
    components, you can add or remove references from them by calling through to
    the underlying WDM layer, using PoFxActivateComponent and PoFxIdleComponent.
    These are lightweight calls that indicate how many reasons there are to keep
    your components turned on.

    PoFx, sometimes in conjunction with a "Power Engine Plugin" which is a
    module supplied by the System-on-Chip vendor (Intel, AMD, Nvidia, Qualcomm,
    TI, etc.), will listen to your requests to keep components powered on. When
    a functional group of things has no reasons to be turned on, PoFx will
    direct them to move to specific idle states, F0 through Fx. When all
    components within a device may be moved out of F0, then the entire device
    may also be moved out of F0. This is indicated by a callback from PoFx to
    your driver, which if you're smart will be KMDF, handling this part for you.
    (See the use of WdfDeviceWdmAssignPowerFrameworkSettings above.)

    Many, many devices have no real states between "on" and "off." For these
    devices, it makes sense to report one component with one F-state, F0. When
    it's idle, PoFx will tell the entire device that it can leave D0. The
    target D-state depends entirely on whether you need active wake signals.

    So imagine that you're writing the driver for a sensor. It needs to be
    turned on when you're taking measurements. It probably also needs to be
    turned on in a calibration phase. For these things, if possible, I would
    just use a power managed queue and let the device be turned off when you're
    not using it.

    The exact conditions for when a device must be turned on vary greatly from
    device class to device class. If you want to ask about specific classes,
    I'll try to help.

    To answer your specific question about whether a driver can know when the
    screen got turned off, the answer is yet, but that's rarely the right
    question to be asking.

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------

    "Vodicka, Michal" wrote in message news:xxxxx@ntdev...

    > You get a very interesting set of relationships, especially regarding
    > power.

    Yes, this is what I mean. Interesting and it is unclear who is responsible
    for what. Currently I have SPI device but it is the same for I2C, data lines
    are separate from power ones.

    As a side note I like SPB architecture. One driver can be used for both I2C
    and SPI devices with almost no additional work.

    > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > about here.

    Actually, wake is only part of the question. First I'd need to know how
    should my driver decide when to power off the device. When user of
    phone/tablet presses power button, the system should remain in S0 and
    minimize power consumption. Turn off display and all unnecessary devices.
    One of my questions is how is the driver notified about this event? Well,
    I'm just preparing experiment which could reveal it but I have a feeling it
    isn't the right way how to get such an info ;-)

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506849-
    > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    > Sent: Thursday, June 28, 2012 8:32 PM
    > To: Windows System Software Devs Interest List
    > Subject: RE:[ntdev] Runtime power management in Windows 8
    >
    > <quote>
    > It differs from other stacks because there is SPB controller driver and
    > function device driver opens it as remote target
    > </quote>
    >
    > This is tied to what I think is one of the most interesting and
    > significant
    > architectural changes in Win8 in my mind.
    >
    > Prior to Win8, we always had devices in a branch of the device tree that
    > terminated in a single place. A device got its data, its power, and its
    > interrupts from a single place. The model, really, was PCI. Your bus
    > driver is
    > responsible for giving you your interrupts, provides the hardware
    > resources
    > from which you receive your data, and can manipulate the power on the slot
    > into which your device is plugged. All relatively simple.
    >
    > Sure, we've attempted to deal with cross-branch power dependencies and
    > such things, but never truly successfully.
    >
    > Enter Win8. NOW, your device can get its data from the I2C bus, gets its
    > interrupts from one ore more GPIO lines, and the power? Well, the power
    > for your device is probably controlled by somebody entirely different.
    > And
    > possibly, but not necessarily, the power for the I2C (where you get your
    > data) and the power for the GPIO (where you get your interrupt) is
    > supplied
    > by somebody else yet.
    >
    > You get a very interesting set of relationships, especially regarding
    > power.
    >
    > When you combine this with the fact that your device can have multiple
    > "functional" power states within D0, and very rapidly transition into and
    > outof these functional power states, you get some very interesting power
    > management capabilities and issues.
    >
    > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > about
    > here.
    >
    > Whew!
    >
    > Peter
    > OSR
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and
    confidential use of the designated recipient(s) named above. To the extent
    the recipient(s) is/are bound by a non-disclosure agreement, or other
    agreement that contains an obligation of confidentiality, with AuthenTec,
    then this message and/or any attachments shall be considered confidential
    information and subject to the confidentiality terms of that agreement. If
    the reader of this message is not the intended recipient named above, you
    are notified that you have received this document in error, and any review,
    dissemination, distribution or copying of this message is strictly
    prohibited. If you have received this document in error, please delete the
    original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Thank you for detailed description. In the meantime I found AssignS0IdleSettings() and was wondering if it is what I'm expected to use. Will try. It is new for me because for USB devices I used selective suspend and IWDFUsbTargetDevice UMDF methods to control it.

    My specific device is Biometric class SPB device. It is used by WinBio service which keeps capture request there for a long time (it means "wait until somebody touches sensor and then scan finger"). It probably means I should use explicit StopIdle/ResumeIdle calls instead of power managed queues. I can enable idle when the device is configured to wait for a finger but it shouldn't be completely turned off. OTOH when there is no request, it can be turned off.

    > To answer your specific question about whether a driver can know when the
    > screen got turned off, the answer is yet, but that's rarely the right
    > question to be asking.

    Well, the motivation is following. User can run an application which switches our device to a mode when it consumes relatively a lot of power. Then user presses power button and expects that OS remains in S0 but all unnecessary devices are turned off. Our device is unnecessary now but continues to consume power because was instructed before to do it (there is an active request). If the driver is notified, it can cancel the request and lower the power consumption. But it needs to know about it (and shouldn't rely on app).

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506883-
    > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > Sent: Friday, June 29, 2012 1:53 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Runtime power management in Windows 8
    >
    > You're looking at it in a way that I would have recommended against even
    > before Windows 8. You seem to think "system is leaving S0" meant "turn off
    > my device." I do admit that most people viewed it that way, and
    > furthermore
    > that before WDF, that was the only reasonable view to take.
    >
    > But since the introduction of WDF, we've tried to enable you to think about
    > the problem differently. Leave your device turned off except when it needs
    > to be turned on, even when the system is in S0. Using KMDF as an example,
    > call WdfDeviceAssignS0IdleSettings and then configure one or more power
    > managed queues. Your device will remain turned on when there is actual
    > work
    > to do. If the reasons that it needs to be turned on can't be represented
    > with WDFREQUESTs, then use WdfDeviceStopIdle and
    > WdfDeviceResumeIdle.
    >
    > When you're targeting very aggressive runtime power management in
    > machines
    > that support an always-on, always-connected model, use
    > WdfDeviceAssignS0IdleSettings with a "system managed idle timeout." It's
    > one of the parameters to the KMDF 1.11 version of the parameter struct.
    >
    > Furthermore, you can integrate with the new runtime power framework,
    > PoFx,
    > by calling WdfDeviceWdmAssignPowerFrameworkSettings. This will enable
    > an
    > even lighter-weight power management model, one which is also available
    > through WDM, though I won't cover that here. The basic idea is that you
    > mark your device as necessary or not necessary by calling WdfDeviceStopIdle
    > and WdfResumeIdle. If your device has multiple independently manageable
    > components, you can add or remove references from them by calling
    > through to
    > the underlying WDM layer, using PoFxActivateComponent and
    > PoFxIdleComponent.
    > These are lightweight calls that indicate how many reasons there are to keep
    > your components turned on.
    >
    > PoFx, sometimes in conjunction with a "Power Engine Plugin" which is a
    > module supplied by the System-on-Chip vendor (Intel, AMD, Nvidia,
    > Qualcomm,
    > TI, etc.), will listen to your requests to keep components powered on. When
    > a functional group of things has no reasons to be turned on, PoFx will
    > direct them to move to specific idle states, F0 through Fx. When all
    > components within a device may be moved out of F0, then the entire device
    > may also be moved out of F0. This is indicated by a callback from PoFx to
    > your driver, which if you're smart will be KMDF, handling this part for you.
    > (See the use of WdfDeviceWdmAssignPowerFrameworkSettings above.)
    >
    > Many, many devices have no real states between "on" and "off." For these
    > devices, it makes sense to report one component with one F-state, F0.
    > When
    > it's idle, PoFx will tell the entire device that it can leave D0. The
    > target D-state depends entirely on whether you need active wake signals.
    >
    > So imagine that you're writing the driver for a sensor. It needs to be
    > turned on when you're taking measurements. It probably also needs to be
    > turned on in a calibration phase. For these things, if possible, I would
    > just use a power managed queue and let the device be turned off when
    > you're
    > not using it.
    >
    > The exact conditions for when a device must be turned on vary greatly from
    > device class to device class. If you want to ask about specific classes,
    > I'll try to help.
    >
    > To answer your specific question about whether a driver can know when the
    > screen got turned off, the answer is yet, but that's rarely the right
    > question to be asking.
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    >
    > > You get a very interesting set of relationships, especially regarding
    > > power.
    >
    > Yes, this is what I mean. Interesting and it is unclear who is responsible
    > for what. Currently I have SPI device but it is the same for I2C, data lines
    > are separate from power ones.
    >
    > As a side note I like SPB architecture. One driver can be used for both I2C
    > and SPI devices with almost no additional work.
    >
    > > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > > about here.
    >
    > Actually, wake is only part of the question. First I'd need to know how
    > should my driver decide when to power off the device. When user of
    > phone/tablet presses power button, the system should remain in S0 and
    > minimize power consumption. Turn off display and all unnecessary devices.
    > One of my questions is how is the driver notified about this event? Well,
    > I'm just preparing experiment which could reveal it but I have a feeling it
    > isn't the right way how to get such an info ;-)
    >
    > Michal
    >
    > > -----Original Message-----
    > > From: xxxxx@lists.osr.com [mailto:bounce-506849-
    > > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    > > Sent: Thursday, June 28, 2012 8:32 PM
    > > To: Windows System Software Devs Interest List
    > > Subject: RE:[ntdev] Runtime power management in Windows 8
    > >
    > > <quote>
    > > It differs from other stacks because there is SPB controller driver and
    > > function device driver opens it as remote target
    > > </quote>
    > >
    > > This is tied to what I think is one of the most interesting and
    > > significant
    > > architectural changes in Win8 in my mind.
    > >
    > > Prior to Win8, we always had devices in a branch of the device tree that
    > > terminated in a single place. A device got its data, its power, and its
    > > interrupts from a single place. The model, really, was PCI. Your bus
    > > driver is
    > > responsible for giving you your interrupts, provides the hardware
    > > resources
    > > from which you receive your data, and can manipulate the power on the
    > slot
    > > into which your device is plugged. All relatively simple.
    > >
    > > Sure, we've attempted to deal with cross-branch power dependencies and
    > > such things, but never truly successfully.
    > >
    > > Enter Win8. NOW, your device can get its data from the I2C bus, gets its
    > > interrupts from one ore more GPIO lines, and the power? Well, the power
    > > for your device is probably controlled by somebody entirely different.
    > > And
    > > possibly, but not necessarily, the power for the I2C (where you get your
    > > data) and the power for the GPIO (where you get your interrupt) is
    > > supplied
    > > by somebody else yet.
    > >
    > > You get a very interesting set of relationships, especially regarding
    > > power.
    > >
    > > When you combine this with the fact that your device can have multiple
    > > "functional" power states within D0, and very rapidly transition into and
    > > outof these functional power states, you get some very interesting power
    > > management capabilities and issues.
    > >
    > > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > > about
    > > here.
    > >
    > > Whew!
    > >
    > > Peter
    > > OSR
    > >
    > > ---
    > > NTDEV is sponsored by OSR
    > >
    > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > http://www.osr.com/seminars
    > >
    > > To unsubscribe, visit the List Server section of OSR Online at
    > > http://www.osronline.com/page.cfm?name=ListServer
    >
    > NOTE: The information in this message is intended for the personal and
    > confidential use of the designated recipient(s) named above. To the extent
    > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > agreement that contains an obligation of confidentiality, with AuthenTec,
    > then this message and/or any attachments shall be considered confidential
    > information and subject to the confidentiality terms of that agreement. If
    > the reader of this message is not the intended recipient named above, you
    > are notified that you have received this document in error, and any review,
    > dissemination, distribution or copying of this message is strictly
    > prohibited. If you have received this document in error, please delete the
    > original message and notify the sender immediately.
    > Thank You!
    > AuthenTec, Inc. http://www.authentec.com/
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    For Metro apps, we should (I say without actually looking up this specific
    example) make sure that all handles are closed to sensor devices like these
    before the machine goes into connected standby. Your driver should be
    tracking handles and requests, not whole machine state.

    For Win32 apps, one can only hope they close their handles when they get
    suspend notifications. We expect that having Win32 apps open will reduce
    your battery life. This is one reason that we're only supporting Metro apps
    on ARM machines.

    (I'll go look up the specifics on biometrics.)

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------

    "Vodicka, Michal" wrote in message news:xxxxx@ntdev...

    Thank you for detailed description. In the meantime I found
    AssignS0IdleSettings() and was wondering if it is what I'm expected to use.
    Will try. It is new for me because for USB devices I used selective suspend
    and IWDFUsbTargetDevice UMDF methods to control it.

    My specific device is Biometric class SPB device. It is used by WinBio
    service which keeps capture request there for a long time (it means "wait
    until somebody touches sensor and then scan finger"). It probably means I
    should use explicit StopIdle/ResumeIdle calls instead of power managed
    queues. I can enable idle when the device is configured to wait for a finger
    but it shouldn't be completely turned off. OTOH when there is no request, it
    can be turned off.

    > To answer your specific question about whether a driver can know when the
    > screen got turned off, the answer is yet, but that's rarely the right
    > question to be asking.

    Well, the motivation is following. User can run an application which
    switches our device to a mode when it consumes relatively a lot of power.
    Then user presses power button and expects that OS remains in S0 but all
    unnecessary devices are turned off. Our device is unnecessary now but
    continues to consume power because was instructed before to do it (there is
    an active request). If the driver is notified, it can cancel the request and
    lower the power consumption. But it needs to know about it (and shouldn't
    rely on app).

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506883-
    > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > Sent: Friday, June 29, 2012 1:53 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Runtime power management in Windows 8
    >
    > You're looking at it in a way that I would have recommended against even
    > before Windows 8. You seem to think "system is leaving S0" meant "turn
    > off
    > my device." I do admit that most people viewed it that way, and
    > furthermore
    > that before WDF, that was the only reasonable view to take.
    >
    > But since the introduction of WDF, we've tried to enable you to think
    > about
    > the problem differently. Leave your device turned off except when it
    > needs
    > to be turned on, even when the system is in S0. Using KMDF as an example,
    > call WdfDeviceAssignS0IdleSettings and then configure one or more power
    > managed queues. Your device will remain turned on when there is actual
    > work
    > to do. If the reasons that it needs to be turned on can't be represented
    > with WDFREQUESTs, then use WdfDeviceStopIdle and
    > WdfDeviceResumeIdle.
    >
    > When you're targeting very aggressive runtime power management in
    > machines
    > that support an always-on, always-connected model, use
    > WdfDeviceAssignS0IdleSettings with a "system managed idle timeout." It's
    > one of the parameters to the KMDF 1.11 version of the parameter struct.
    >
    > Furthermore, you can integrate with the new runtime power framework,
    > PoFx,
    > by calling WdfDeviceWdmAssignPowerFrameworkSettings. This will enable
    > an
    > even lighter-weight power management model, one which is also available
    > through WDM, though I won't cover that here. The basic idea is that you
    > mark your device as necessary or not necessary by calling
    > WdfDeviceStopIdle
    > and WdfResumeIdle. If your device has multiple independently manageable
    > components, you can add or remove references from them by calling
    > through to
    > the underlying WDM layer, using PoFxActivateComponent and
    > PoFxIdleComponent.
    > These are lightweight calls that indicate how many reasons there are to
    > keep
    > your components turned on.
    >
    > PoFx, sometimes in conjunction with a "Power Engine Plugin" which is a
    > module supplied by the System-on-Chip vendor (Intel, AMD, Nvidia,
    > Qualcomm,
    > TI, etc.), will listen to your requests to keep components powered on.
    > When
    > a functional group of things has no reasons to be turned on, PoFx will
    > direct them to move to specific idle states, F0 through Fx. When all
    > components within a device may be moved out of F0, then the entire device
    > may also be moved out of F0. This is indicated by a callback from PoFx to
    > your driver, which if you're smart will be KMDF, handling this part for
    > you.
    > (See the use of WdfDeviceWdmAssignPowerFrameworkSettings above.)
    >
    > Many, many devices have no real states between "on" and "off." For these
    > devices, it makes sense to report one component with one F-state, F0.
    > When
    > it's idle, PoFx will tell the entire device that it can leave D0. The
    > target D-state depends entirely on whether you need active wake signals.
    >
    > So imagine that you're writing the driver for a sensor. It needs to be
    > turned on when you're taking measurements. It probably also needs to be
    > turned on in a calibration phase. For these things, if possible, I would
    > just use a power managed queue and let the device be turned off when
    > you're
    > not using it.
    >
    > The exact conditions for when a device must be turned on vary greatly from
    > device class to device class. If you want to ask about specific classes,
    > I'll try to help.
    >
    > To answer your specific question about whether a driver can know when the
    > screen got turned off, the answer is yet, but that's rarely the right
    > question to be asking.
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    >
    > > You get a very interesting set of relationships, especially regarding
    > > power.
    >
    > Yes, this is what I mean. Interesting and it is unclear who is responsible
    > for what. Currently I have SPI device but it is the same for I2C, data
    > lines
    > are separate from power ones.
    >
    > As a side note I like SPB architecture. One driver can be used for both
    > I2C
    > and SPI devices with almost no additional work.
    >
    > > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > > about here.
    >
    > Actually, wake is only part of the question. First I'd need to know how
    > should my driver decide when to power off the device. When user of
    > phone/tablet presses power button, the system should remain in S0 and
    > minimize power consumption. Turn off display and all unnecessary devices.
    > One of my questions is how is the driver notified about this event? Well,
    > I'm just preparing experiment which could reveal it but I have a feeling
    > it
    > isn't the right way how to get such an info ;-)
    >
    > Michal
    >
    > > -----Original Message-----
    > > From: xxxxx@lists.osr.com [mailto:bounce-506849-
    > > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    > > Sent: Thursday, June 28, 2012 8:32 PM
    > > To: Windows System Software Devs Interest List
    > > Subject: RE:[ntdev] Runtime power management in Windows 8
    > >
    > > <quote>
    > > It differs from other stacks because there is SPB controller driver and
    > > function device driver opens it as remote target
    > > </quote>
    > >
    > > This is tied to what I think is one of the most interesting and
    > > significant
    > > architectural changes in Win8 in my mind.
    > >
    > > Prior to Win8, we always had devices in a branch of the device tree that
    > > terminated in a single place. A device got its data, its power, and its
    > > interrupts from a single place. The model, really, was PCI. Your bus
    > > driver is
    > > responsible for giving you your interrupts, provides the hardware
    > > resources
    > > from which you receive your data, and can manipulate the power on the
    > slot
    > > into which your device is plugged. All relatively simple.
    > >
    > > Sure, we've attempted to deal with cross-branch power dependencies and
    > > such things, but never truly successfully.
    > >
    > > Enter Win8. NOW, your device can get its data from the I2C bus, gets
    > > its
    > > interrupts from one ore more GPIO lines, and the power? Well, the power
    > > for your device is probably controlled by somebody entirely different.
    > > And
    > > possibly, but not necessarily, the power for the I2C (where you get your
    > > data) and the power for the GPIO (where you get your interrupt) is
    > > supplied
    > > by somebody else yet.
    > >
    > > You get a very interesting set of relationships, especially regarding
    > > power.
    > >
    > > When you combine this with the fact that your device can have multiple
    > > "functional" power states within D0, and very rapidly transition into
    > > and
    > > outof these functional power states, you get some very interesting power
    > > management capabilities and issues.
    > >
    > > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > > about
    > > here.
    > >
    > > Whew!
    > >
    > > Peter
    > > OSR
    > >
    > > ---
    > > NTDEV is sponsored by OSR
    > >
    > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > http://www.osr.com/seminars
    > >
    > > To unsubscribe, visit the List Server section of OSR Online at
    > > http://www.osronline.com/page.cfm?name=ListServer
    >
    > NOTE: The information in this message is intended for the personal and
    > confidential use of the designated recipient(s) named above. To the extent
    > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > agreement that contains an obligation of confidentiality, with AuthenTec,
    > then this message and/or any attachments shall be considered confidential
    > information and subject to the confidentiality terms of that agreement.
    > If
    > the reader of this message is not the intended recipient named above, you
    > are notified that you have received this document in error, and any
    > review,
    > dissemination, distribution or copying of this message is strictly
    > prohibited. If you have received this document in error, please delete the
    > original message and notify the sender immediately.
    > Thank You!
    > AuthenTec, Inc. http://www.authentec.com/
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and
    confidential use of the designated recipient(s) named above. To the extent
    the recipient(s) is/are bound by a non-disclosure agreement, or other
    agreement that contains an obligation of confidentiality, with AuthenTec,
    then this message and/or any attachments shall be considered confidential
    information and subject to the confidentiality terms of that agreement. If
    the reader of this message is not the intended recipient named above, you
    are notified that you have received this document in error, and any review,
    dissemination, distribution or copying of this message is strictly
    prohibited. If you have received this document in error, please delete the
    original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I just made few experiments and although Win8 behavior is improved against Win7 there is a problem specific to biometry.

    The requests to our driver are sent by WinBio service. It does it on behalf of apps and when we're under control, we can close handles when necessary. However, one of client is Windows logon. I just verified that there is always pending request when logon screen is active. Which also means locked screen. The request remains pending even when I press the power button and screen, keyboard and mouse are turned off. It isn't a desired behavior, IMO.

    I understand your argument we should track requests and handles instead of machine state but WinBio is open API and we may not have control over application. If Windows logon breaks it, what we can expect from 3rd party app writers? Isn't it better if driver tracks machine state, cancels active requests and powers the device off?

    > For Win32 apps, one can only hope they close their handles when they get
    > suspend notifications.

    Do you mean Win32 apps are notified when system is going to connected standby state? We will need it for our apps. The next problem with biometry is it isn't supported by WinRT (if something didn't change).

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506889-
    > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > Sent: Friday, June 29, 2012 4:34 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Runtime power management in Windows 8
    >
    > For Metro apps, we should (I say without actually looking up this specific
    > example) make sure that all handles are closed to sensor devices like these
    > before the machine goes into connected standby. Your driver should be
    > tracking handles and requests, not whole machine state.
    >
    > For Win32 apps, one can only hope they close their handles when they get
    > suspend notifications. We expect that having Win32 apps open will reduce
    > your battery life. This is one reason that we're only supporting Metro apps
    > on ARM machines.
    >
    > (I'll go look up the specifics on biometrics.)
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    >
    > Thank you for detailed description. In the meantime I found
    > AssignS0IdleSettings() and was wondering if it is what I'm expected to use.
    > Will try. It is new for me because for USB devices I used selective suspend
    > and IWDFUsbTargetDevice UMDF methods to control it.
    >
    > My specific device is Biometric class SPB device. It is used by WinBio
    > service which keeps capture request there for a long time (it means "wait
    > until somebody touches sensor and then scan finger"). It probably means I
    > should use explicit StopIdle/ResumeIdle calls instead of power managed
    > queues. I can enable idle when the device is configured to wait for a finger
    > but it shouldn't be completely turned off. OTOH when there is no request, it
    > can be turned off.
    >
    > > To answer your specific question about whether a driver can know when
    > the
    > > screen got turned off, the answer is yet, but that's rarely the right
    > > question to be asking.
    >
    > Well, the motivation is following. User can run an application which
    > switches our device to a mode when it consumes relatively a lot of power.
    > Then user presses power button and expects that OS remains in S0 but all
    > unnecessary devices are turned off. Our device is unnecessary now but
    > continues to consume power because was instructed before to do it (there is
    > an active request). If the driver is notified, it can cancel the request and
    > lower the power consumption. But it needs to know about it (and shouldn't
    > rely on app).
    >
    > Michal
    >
    > > -----Original Message-----
    > > From: xxxxx@lists.osr.com [mailto:bounce-506883-
    > > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > > Sent: Friday, June 29, 2012 1:53 AM
    > > To: Windows System Software Devs Interest List
    > > Subject: Re:[ntdev] Runtime power management in Windows 8
    > >
    > > You're looking at it in a way that I would have recommended against even
    > > before Windows 8. You seem to think "system is leaving S0" meant "turn
    > > off
    > > my device." I do admit that most people viewed it that way, and
    > > furthermore
    > > that before WDF, that was the only reasonable view to take.
    > >
    > > But since the introduction of WDF, we've tried to enable you to think
    > > about
    > > the problem differently. Leave your device turned off except when it
    > > needs
    > > to be turned on, even when the system is in S0. Using KMDF as an
    > example,
    > > call WdfDeviceAssignS0IdleSettings and then configure one or more power
    > > managed queues. Your device will remain turned on when there is actual
    > > work
    > > to do. If the reasons that it needs to be turned on can't be represented
    > > with WDFREQUESTs, then use WdfDeviceStopIdle and
    > > WdfDeviceResumeIdle.
    > >
    > > When you're targeting very aggressive runtime power management in
    > > machines
    > > that support an always-on, always-connected model, use
    > > WdfDeviceAssignS0IdleSettings with a "system managed idle timeout." It's
    > > one of the parameters to the KMDF 1.11 version of the parameter struct.
    > >
    > > Furthermore, you can integrate with the new runtime power framework,
    > > PoFx,
    > > by calling WdfDeviceWdmAssignPowerFrameworkSettings. This will enable
    > > an
    > > even lighter-weight power management model, one which is also available
    > > through WDM, though I won't cover that here. The basic idea is that you
    > > mark your device as necessary or not necessary by calling
    > > WdfDeviceStopIdle
    > > and WdfResumeIdle. If your device has multiple independently
    > manageable
    > > components, you can add or remove references from them by calling
    > > through to
    > > the underlying WDM layer, using PoFxActivateComponent and
    > > PoFxIdleComponent.
    > > These are lightweight calls that indicate how many reasons there are to
    > > keep
    > > your components turned on.
    > >
    > > PoFx, sometimes in conjunction with a "Power Engine Plugin" which is a
    > > module supplied by the System-on-Chip vendor (Intel, AMD, Nvidia,
    > > Qualcomm,
    > > TI, etc.), will listen to your requests to keep components powered on.
    > > When
    > > a functional group of things has no reasons to be turned on, PoFx will
    > > direct them to move to specific idle states, F0 through Fx. When all
    > > components within a device may be moved out of F0, then the entire
    > device
    > > may also be moved out of F0. This is indicated by a callback from PoFx to
    > > your driver, which if you're smart will be KMDF, handling this part for
    > > you.
    > > (See the use of WdfDeviceWdmAssignPowerFrameworkSettings above.)
    > >
    > > Many, many devices have no real states between "on" and "off." For
    > these
    > > devices, it makes sense to report one component with one F-state, F0.
    > > When
    > > it's idle, PoFx will tell the entire device that it can leave D0. The
    > > target D-state depends entirely on whether you need active wake signals.
    > >
    > > So imagine that you're writing the driver for a sensor. It needs to be
    > > turned on when you're taking measurements. It probably also needs to be
    > > turned on in a calibration phase. For these things, if possible, I would
    > > just use a power managed queue and let the device be turned off when
    > > you're
    > > not using it.
    > >
    > > The exact conditions for when a device must be turned on vary greatly
    > from
    > > device class to device class. If you want to ask about specific classes,
    > > I'll try to help.
    > >
    > > To answer your specific question about whether a driver can know when
    > the
    > > screen got turned off, the answer is yet, but that's rarely the right
    > > question to be asking.
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    > >
    > > > You get a very interesting set of relationships, especially regarding
    > > > power.
    > >
    > > Yes, this is what I mean. Interesting and it is unclear who is responsible
    > > for what. Currently I have SPI device but it is the same for I2C, data
    > > lines
    > > are separate from power ones.
    > >
    > > As a side note I like SPB architecture. One driver can be used for both
    > > I2C
    > > and SPI devices with almost no additional work.
    > >
    > > > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > > > about here.
    > >
    > > Actually, wake is only part of the question. First I'd need to know how
    > > should my driver decide when to power off the device. When user of
    > > phone/tablet presses power button, the system should remain in S0 and
    > > minimize power consumption. Turn off display and all unnecessary devices.
    > > One of my questions is how is the driver notified about this event? Well,
    > > I'm just preparing experiment which could reveal it but I have a feeling
    > > it
    > > isn't the right way how to get such an info ;-)
    > >
    > > Michal
    > >
    > > > -----Original Message-----
    > > > From: xxxxx@lists.osr.com [mailto:bounce-506849-
    > > > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    > > > Sent: Thursday, June 28, 2012 8:32 PM
    > > > To: Windows System Software Devs Interest List
    > > > Subject: RE:[ntdev] Runtime power management in Windows 8
    > > >
    > > > <quote>
    > > > It differs from other stacks because there is SPB controller driver and
    > > > function device driver opens it as remote target
    > > > </quote>
    > > >
    > > > This is tied to what I think is one of the most interesting and
    > > > significant
    > > > architectural changes in Win8 in my mind.
    > > >
    > > > Prior to Win8, we always had devices in a branch of the device tree that
    > > > terminated in a single place. A device got its data, its power, and its
    > > > interrupts from a single place. The model, really, was PCI. Your bus
    > > > driver is
    > > > responsible for giving you your interrupts, provides the hardware
    > > > resources
    > > > from which you receive your data, and can manipulate the power on the
    > > slot
    > > > into which your device is plugged. All relatively simple.
    > > >
    > > > Sure, we've attempted to deal with cross-branch power dependencies
    > and
    > > > such things, but never truly successfully.
    > > >
    > > > Enter Win8. NOW, your device can get its data from the I2C bus, gets
    > > > its
    > > > interrupts from one ore more GPIO lines, and the power? Well, the
    > power
    > > > for your device is probably controlled by somebody entirely different.
    > > > And
    > > > possibly, but not necessarily, the power for the I2C (where you get your
    > > > data) and the power for the GPIO (where you get your interrupt) is
    > > > supplied
    > > > by somebody else yet.
    > > >
    > > > You get a very interesting set of relationships, especially regarding
    > > > power.
    > > >
    > > > When you combine this with the fact that your device can have multiple
    > > > "functional" power states within D0, and very rapidly transition into
    > > > and
    > > > outof these functional power states, you get some very interesting
    > power
    > > > management capabilities and issues.
    > > >
    > > > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > > > about
    > > > here.
    > > >
    > > > Whew!
    > > >
    > > > Peter
    > > > OSR
    > > >
    > > > ---
    > > > NTDEV is sponsored by OSR
    > > >
    > > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > > http://www.osr.com/seminars
    > > >
    > > > To unsubscribe, visit the List Server section of OSR Online at
    > > > http://www.osronline.com/page.cfm?name=ListServer
    > >
    > > NOTE: The information in this message is intended for the personal and
    > > confidential use of the designated recipient(s) named above. To the extent
    > > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > > agreement that contains an obligation of confidentiality, with AuthenTec,
    > > then this message and/or any attachments shall be considered confidential
    > > information and subject to the confidentiality terms of that agreement.
    > > If
    > > the reader of this message is not the intended recipient named above, you
    > > are notified that you have received this document in error, and any
    > > review,
    > > dissemination, distribution or copying of this message is strictly
    > > prohibited. If you have received this document in error, please delete the
    > > original message and notify the sender immediately.
    > > Thank You!
    > > AuthenTec, Inc. http://www.authentec.com/
    > >
    > >
    > > ---
    > > NTDEV is sponsored by OSR
    > >
    > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > http://www.osr.com/seminars
    > >
    > > To unsubscribe, visit the List Server section of OSR Online at
    > > http://www.osronline.com/page.cfm?name=ListServer
    >
    > NOTE: The information in this message is intended for the personal and
    > confidential use of the designated recipient(s) named above. To the extent
    > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > agreement that contains an obligation of confidentiality, with AuthenTec,
    > then this message and/or any attachments shall be considered confidential
    > information and subject to the confidentiality terms of that agreement. If
    > the reader of this message is not the intended recipient named above, you
    > are notified that you have received this document in error, and any review,
    > dissemination, distribution or copying of this message is strictly
    > prohibited. If you have received this document in error, please delete the
    > original message and notify the sender immediately.
    > Thank You!
    > AuthenTec, Inc. http://www.authentec.com/
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    Michal,

    In addition to the other stuff that I told you already on this thread, you
    might want to consider registering for notification when the screen turns
    off. Treat that as an appropriate time to mark your device as unnecessary,
    thereby letting it fall asleep.

    To find out when the screen is off, register a callback using
    PoRegisterPowerSettingCallback, passing in GUID_CONSOLE_DISPLAY_STATE.

    Jake Oshins
    Windows Kernel Team

    This message offers no warranties and confers no rights.

    -----------------------------------------------------------

    "Vodicka, Michal" wrote in message news:xxxxx@ntdev...

    I just made few experiments and although Win8 behavior is improved against
    Win7 there is a problem specific to biometry.

    The requests to our driver are sent by WinBio service. It does it on behalf
    of apps and when we're under control, we can close handles when necessary.
    However, one of client is Windows logon. I just verified that there is
    always pending request when logon screen is active. Which also means locked
    screen. The request remains pending even when I press the power button and
    screen, keyboard and mouse are turned off. It isn't a desired behavior, IMO.

    I understand your argument we should track requests and handles instead of
    machine state but WinBio is open API and we may not have control over
    application. If Windows logon breaks it, what we can expect from 3rd party
    app writers? Isn't it better if driver tracks machine state, cancels active
    requests and powers the device off?

    > For Win32 apps, one can only hope they close their handles when they get
    > suspend notifications.

    Do you mean Win32 apps are notified when system is going to connected
    standby state? We will need it for our apps. The next problem with biometry
    is it isn't supported by WinRT (if something didn't change).

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506889-
    > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > Sent: Friday, June 29, 2012 4:34 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Runtime power management in Windows 8
    >
    > For Metro apps, we should (I say without actually looking up this specific
    > example) make sure that all handles are closed to sensor devices like
    > these
    > before the machine goes into connected standby. Your driver should be
    > tracking handles and requests, not whole machine state.
    >
    > For Win32 apps, one can only hope they close their handles when they get
    > suspend notifications. We expect that having Win32 apps open will reduce
    > your battery life. This is one reason that we're only supporting Metro
    > apps
    > on ARM machines.
    >
    > (I'll go look up the specifics on biometrics.)
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    >
    > Thank you for detailed description. In the meantime I found
    > AssignS0IdleSettings() and was wondering if it is what I'm expected to
    > use.
    > Will try. It is new for me because for USB devices I used selective
    > suspend
    > and IWDFUsbTargetDevice UMDF methods to control it.
    >
    > My specific device is Biometric class SPB device. It is used by WinBio
    > service which keeps capture request there for a long time (it means "wait
    > until somebody touches sensor and then scan finger"). It probably means I
    > should use explicit StopIdle/ResumeIdle calls instead of power managed
    > queues. I can enable idle when the device is configured to wait for a
    > finger
    > but it shouldn't be completely turned off. OTOH when there is no request,
    > it
    > can be turned off.
    >
    > > To answer your specific question about whether a driver can know when
    > the
    > > screen got turned off, the answer is yet, but that's rarely the right
    > > question to be asking.
    >
    > Well, the motivation is following. User can run an application which
    > switches our device to a mode when it consumes relatively a lot of power.
    > Then user presses power button and expects that OS remains in S0 but all
    > unnecessary devices are turned off. Our device is unnecessary now but
    > continues to consume power because was instructed before to do it (there
    > is
    > an active request). If the driver is notified, it can cancel the request
    > and
    > lower the power consumption. But it needs to know about it (and shouldn't
    > rely on app).
    >
    > Michal
    >
    > > -----Original Message-----
    > > From: xxxxx@lists.osr.com [mailto:bounce-506883-
    > > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > > Sent: Friday, June 29, 2012 1:53 AM
    > > To: Windows System Software Devs Interest List
    > > Subject: Re:[ntdev] Runtime power management in Windows 8
    > >
    > > You're looking at it in a way that I would have recommended against even
    > > before Windows 8. You seem to think "system is leaving S0" meant "turn
    > > off
    > > my device." I do admit that most people viewed it that way, and
    > > furthermore
    > > that before WDF, that was the only reasonable view to take.
    > >
    > > But since the introduction of WDF, we've tried to enable you to think
    > > about
    > > the problem differently. Leave your device turned off except when it
    > > needs
    > > to be turned on, even when the system is in S0. Using KMDF as an
    > example,
    > > call WdfDeviceAssignS0IdleSettings and then configure one or more power
    > > managed queues. Your device will remain turned on when there is actual
    > > work
    > > to do. If the reasons that it needs to be turned on can't be
    > > represented
    > > with WDFREQUESTs, then use WdfDeviceStopIdle and
    > > WdfDeviceResumeIdle.
    > >
    > > When you're targeting very aggressive runtime power management in
    > > machines
    > > that support an always-on, always-connected model, use
    > > WdfDeviceAssignS0IdleSettings with a "system managed idle timeout."
    > > It's
    > > one of the parameters to the KMDF 1.11 version of the parameter struct.
    > >
    > > Furthermore, you can integrate with the new runtime power framework,
    > > PoFx,
    > > by calling WdfDeviceWdmAssignPowerFrameworkSettings. This will enable
    > > an
    > > even lighter-weight power management model, one which is also available
    > > through WDM, though I won't cover that here. The basic idea is that you
    > > mark your device as necessary or not necessary by calling
    > > WdfDeviceStopIdle
    > > and WdfResumeIdle. If your device has multiple independently
    > manageable
    > > components, you can add or remove references from them by calling
    > > through to
    > > the underlying WDM layer, using PoFxActivateComponent and
    > > PoFxIdleComponent.
    > > These are lightweight calls that indicate how many reasons there are to
    > > keep
    > > your components turned on.
    > >
    > > PoFx, sometimes in conjunction with a "Power Engine Plugin" which is a
    > > module supplied by the System-on-Chip vendor (Intel, AMD, Nvidia,
    > > Qualcomm,
    > > TI, etc.), will listen to your requests to keep components powered on.
    > > When
    > > a functional group of things has no reasons to be turned on, PoFx will
    > > direct them to move to specific idle states, F0 through Fx. When all
    > > components within a device may be moved out of F0, then the entire
    > device
    > > may also be moved out of F0. This is indicated by a callback from PoFx
    > > to
    > > your driver, which if you're smart will be KMDF, handling this part for
    > > you.
    > > (See the use of WdfDeviceWdmAssignPowerFrameworkSettings above.)
    > >
    > > Many, many devices have no real states between "on" and "off." For
    > these
    > > devices, it makes sense to report one component with one F-state, F0.
    > > When
    > > it's idle, PoFx will tell the entire device that it can leave D0. The
    > > target D-state depends entirely on whether you need active wake signals.
    > >
    > > So imagine that you're writing the driver for a sensor. It needs to be
    > > turned on when you're taking measurements. It probably also needs to be
    > > turned on in a calibration phase. For these things, if possible, I
    > > would
    > > just use a power managed queue and let the device be turned off when
    > > you're
    > > not using it.
    > >
    > > The exact conditions for when a device must be turned on vary greatly
    > from
    > > device class to device class. If you want to ask about specific
    > > classes,
    > > I'll try to help.
    > >
    > > To answer your specific question about whether a driver can know when
    > the
    > > screen got turned off, the answer is yet, but that's rarely the right
    > > question to be asking.
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    > >
    > > > You get a very interesting set of relationships, especially regarding
    > > > power.
    > >
    > > Yes, this is what I mean. Interesting and it is unclear who is
    > > responsible
    > > for what. Currently I have SPI device but it is the same for I2C, data
    > > lines
    > > are separate from power ones.
    > >
    > > As a side note I like SPB architecture. One driver can be used for both
    > > I2C
    > > and SPI devices with almost no additional work.
    > >
    > > > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > > > about here.
    > >
    > > Actually, wake is only part of the question. First I'd need to know how
    > > should my driver decide when to power off the device. When user of
    > > phone/tablet presses power button, the system should remain in S0 and
    > > minimize power consumption. Turn off display and all unnecessary
    > > devices.
    > > One of my questions is how is the driver notified about this event?
    > > Well,
    > > I'm just preparing experiment which could reveal it but I have a feeling
    > > it
    > > isn't the right way how to get such an info ;-)
    > >
    > > Michal
    > >
    > > > -----Original Message-----
    > > > From: xxxxx@lists.osr.com [mailto:bounce-506849-
    > > > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    > > > Sent: Thursday, June 28, 2012 8:32 PM
    > > > To: Windows System Software Devs Interest List
    > > > Subject: RE:[ntdev] Runtime power management in Windows 8
    > > >
    > > > <quote>
    > > > It differs from other stacks because there is SPB controller driver
    > > > and
    > > > function device driver opens it as remote target
    > > > </quote>
    > > >
    > > > This is tied to what I think is one of the most interesting and
    > > > significant
    > > > architectural changes in Win8 in my mind.
    > > >
    > > > Prior to Win8, we always had devices in a branch of the device tree
    > > > that
    > > > terminated in a single place. A device got its data, its power, and
    > > > its
    > > > interrupts from a single place. The model, really, was PCI. Your bus
    > > > driver is
    > > > responsible for giving you your interrupts, provides the hardware
    > > > resources
    > > > from which you receive your data, and can manipulate the power on the
    > > slot
    > > > into which your device is plugged. All relatively simple.
    > > >
    > > > Sure, we've attempted to deal with cross-branch power dependencies
    > and
    > > > such things, but never truly successfully.
    > > >
    > > > Enter Win8. NOW, your device can get its data from the I2C bus, gets
    > > > its
    > > > interrupts from one ore more GPIO lines, and the power? Well, the
    > power
    > > > for your device is probably controlled by somebody entirely different.
    > > > And
    > > > possibly, but not necessarily, the power for the I2C (where you get
    > > > your
    > > > data) and the power for the GPIO (where you get your interrupt) is
    > > > supplied
    > > > by somebody else yet.
    > > >
    > > > You get a very interesting set of relationships, especially regarding
    > > > power.
    > > >
    > > > When you combine this with the fact that your device can have multiple
    > > > "functional" power states within D0, and very rapidly transition into
    > > > and
    > > > outof these functional power states, you get some very interesting
    > power
    > > > management capabilities and issues.
    > > >
    > > > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > > > about
    > > > here.
    > > >
    > > > Whew!
    > > >
    > > > Peter
    > > > OSR
    > > >
    > > > ---
    > > > NTDEV is sponsored by OSR
    > > >
    > > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > > http://www.osr.com/seminars
    > > >
    > > > To unsubscribe, visit the List Server section of OSR Online at
    > > > http://www.osronline.com/page.cfm?name=ListServer
    > >
    > > NOTE: The information in this message is intended for the personal and
    > > confidential use of the designated recipient(s) named above. To the
    > > extent
    > > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > > agreement that contains an obligation of confidentiality, with
    > > AuthenTec,
    > > then this message and/or any attachments shall be considered
    > > confidential
    > > information and subject to the confidentiality terms of that agreement.
    > > If
    > > the reader of this message is not the intended recipient named above,
    > > you
    > > are notified that you have received this document in error, and any
    > > review,
    > > dissemination, distribution or copying of this message is strictly
    > > prohibited. If you have received this document in error, please delete
    > > the
    > > original message and notify the sender immediately.
    > > Thank You!
    > > AuthenTec, Inc. http://www.authentec.com/
    > >
    > >
    > > ---
    > > NTDEV is sponsored by OSR
    > >
    > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > http://www.osr.com/seminars
    > >
    > > To unsubscribe, visit the List Server section of OSR Online at
    > > http://www.osronline.com/page.cfm?name=ListServer
    >
    > NOTE: The information in this message is intended for the personal and
    > confidential use of the designated recipient(s) named above. To the extent
    > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > agreement that contains an obligation of confidentiality, with AuthenTec,
    > then this message and/or any attachments shall be considered confidential
    > information and subject to the confidentiality terms of that agreement.
    > If
    > the reader of this message is not the intended recipient named above, you
    > are notified that you have received this document in error, and any
    > review,
    > dissemination, distribution or copying of this message is strictly
    > prohibited. If you have received this document in error, please delete the
    > original message and notify the sender immediately.
    > Thank You!
    > AuthenTec, Inc. http://www.authentec.com/
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and
    confidential use of the designated recipient(s) named above. To the extent
    the recipient(s) is/are bound by a non-disclosure agreement, or other
    agreement that contains an obligation of confidentiality, with AuthenTec,
    then this message and/or any attachments shall be considered confidential
    information and subject to the confidentiality terms of that agreement. If
    the reader of this message is not the intended recipient named above, you
    are notified that you have received this document in error, and any review,
    dissemination, distribution or copying of this message is strictly
    prohibited. If you have received this document in error, please delete the
    original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Hi Jake,

    Thanks, it looks like a good idea. I have UMDF driver, thought, which is the only reasonable approach for biometric driver (a lot of sensor related and image processing code not suitable for kernel mode). Also, I think it is MS requirement or at least strong recommendation for Biometric driver class.

    Is there a direct PoRegisterPowerSettingCallback equivalent for UMDF driver? If not I guess I should looks for a similar broadcast for apps and services.

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-506975-
    > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > Sent: Saturday, June 30, 2012 1:32 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Runtime power management in Windows 8
    >
    > Michal,
    >
    > In addition to the other stuff that I told you already on this thread, you
    > might want to consider registering for notification when the screen turns
    > off. Treat that as an appropriate time to mark your device as unnecessary,
    > thereby letting it fall asleep.
    >
    > To find out when the screen is off, register a callback using
    > PoRegisterPowerSettingCallback, passing in
    > GUID_CONSOLE_DISPLAY_STATE.
    >
    > Jake Oshins
    > Windows Kernel Team
    >
    > This message offers no warranties and confers no rights.
    >
    > -----------------------------------------------------------
    >
    > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    >
    > I just made few experiments and although Win8 behavior is improved against
    > Win7 there is a problem specific to biometry.
    >
    > The requests to our driver are sent by WinBio service. It does it on behalf
    > of apps and when we're under control, we can close handles when
    > necessary.
    > However, one of client is Windows logon. I just verified that there is
    > always pending request when logon screen is active. Which also means
    > locked
    > screen. The request remains pending even when I press the power button
    > and
    > screen, keyboard and mouse are turned off. It isn't a desired behavior, IMO.
    >
    > I understand your argument we should track requests and handles instead of
    > machine state but WinBio is open API and we may not have control over
    > application. If Windows logon breaks it, what we can expect from 3rd party
    > app writers? Isn't it better if driver tracks machine state, cancels active
    > requests and powers the device off?
    >
    > > For Win32 apps, one can only hope they close their handles when they get
    > > suspend notifications.
    >
    > Do you mean Win32 apps are notified when system is going to connected
    > standby state? We will need it for our apps. The next problem with biometry
    > is it isn't supported by WinRT (if something didn't change).
    >
    > Michal
    >
    > > -----Original Message-----
    > > From: xxxxx@lists.osr.com [mailto:bounce-506889-
    > > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > > Sent: Friday, June 29, 2012 4:34 AM
    > > To: Windows System Software Devs Interest List
    > > Subject: Re:[ntdev] Runtime power management in Windows 8
    > >
    > > For Metro apps, we should (I say without actually looking up this specific
    > > example) make sure that all handles are closed to sensor devices like
    > > these
    > > before the machine goes into connected standby. Your driver should be
    > > tracking handles and requests, not whole machine state.
    > >
    > > For Win32 apps, one can only hope they close their handles when they get
    > > suspend notifications. We expect that having Win32 apps open will reduce
    > > your battery life. This is one reason that we're only supporting Metro
    > > apps
    > > on ARM machines.
    > >
    > > (I'll go look up the specifics on biometrics.)
    > >
    > > Jake Oshins
    > > Windows Kernel Team
    > >
    > > This message offers no warranties and confers no rights.
    > >
    > > -----------------------------------------------------------
    > >
    > > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    > >
    > > Thank you for detailed description. In the meantime I found
    > > AssignS0IdleSettings() and was wondering if it is what I'm expected to
    > > use.
    > > Will try. It is new for me because for USB devices I used selective
    > > suspend
    > > and IWDFUsbTargetDevice UMDF methods to control it.
    > >
    > > My specific device is Biometric class SPB device. It is used by WinBio
    > > service which keeps capture request there for a long time (it means "wait
    > > until somebody touches sensor and then scan finger"). It probably means I
    > > should use explicit StopIdle/ResumeIdle calls instead of power managed
    > > queues. I can enable idle when the device is configured to wait for a
    > > finger
    > > but it shouldn't be completely turned off. OTOH when there is no request,
    > > it
    > > can be turned off.
    > >
    > > > To answer your specific question about whether a driver can know when
    > > the
    > > > screen got turned off, the answer is yet, but that's rarely the right
    > > > question to be asking.
    > >
    > > Well, the motivation is following. User can run an application which
    > > switches our device to a mode when it consumes relatively a lot of power.
    > > Then user presses power button and expects that OS remains in S0 but all
    > > unnecessary devices are turned off. Our device is unnecessary now but
    > > continues to consume power because was instructed before to do it (there
    > > is
    > > an active request). If the driver is notified, it can cancel the request
    > > and
    > > lower the power consumption. But it needs to know about it (and shouldn't
    > > rely on app).
    > >
    > > Michal
    > >
    > > > -----Original Message-----
    > > > From: xxxxx@lists.osr.com [mailto:bounce-506883-
    > > > xxxxx@lists.osr.com] On Behalf Of Jake Oshins
    > > > Sent: Friday, June 29, 2012 1:53 AM
    > > > To: Windows System Software Devs Interest List
    > > > Subject: Re:[ntdev] Runtime power management in Windows 8
    > > >
    > > > You're looking at it in a way that I would have recommended against even
    > > > before Windows 8. You seem to think "system is leaving S0" meant "turn
    > > > off
    > > > my device." I do admit that most people viewed it that way, and
    > > > furthermore
    > > > that before WDF, that was the only reasonable view to take.
    > > >
    > > > But since the introduction of WDF, we've tried to enable you to think
    > > > about
    > > > the problem differently. Leave your device turned off except when it
    > > > needs
    > > > to be turned on, even when the system is in S0. Using KMDF as an
    > > example,
    > > > call WdfDeviceAssignS0IdleSettings and then configure one or more
    > power
    > > > managed queues. Your device will remain turned on when there is actual
    > > > work
    > > > to do. If the reasons that it needs to be turned on can't be
    > > > represented
    > > > with WDFREQUESTs, then use WdfDeviceStopIdle and
    > > > WdfDeviceResumeIdle.
    > > >
    > > > When you're targeting very aggressive runtime power management in
    > > > machines
    > > > that support an always-on, always-connected model, use
    > > > WdfDeviceAssignS0IdleSettings with a "system managed idle timeout."
    > > > It's
    > > > one of the parameters to the KMDF 1.11 version of the parameter struct.
    > > >
    > > > Furthermore, you can integrate with the new runtime power framework,
    > > > PoFx,
    > > > by calling WdfDeviceWdmAssignPowerFrameworkSettings. This will
    > enable
    > > > an
    > > > even lighter-weight power management model, one which is also
    > available
    > > > through WDM, though I won't cover that here. The basic idea is that you
    > > > mark your device as necessary or not necessary by calling
    > > > WdfDeviceStopIdle
    > > > and WdfResumeIdle. If your device has multiple independently
    > > manageable
    > > > components, you can add or remove references from them by calling
    > > > through to
    > > > the underlying WDM layer, using PoFxActivateComponent and
    > > > PoFxIdleComponent.
    > > > These are lightweight calls that indicate how many reasons there are to
    > > > keep
    > > > your components turned on.
    > > >
    > > > PoFx, sometimes in conjunction with a "Power Engine Plugin" which is a
    > > > module supplied by the System-on-Chip vendor (Intel, AMD, Nvidia,
    > > > Qualcomm,
    > > > TI, etc.), will listen to your requests to keep components powered on.
    > > > When
    > > > a functional group of things has no reasons to be turned on, PoFx will
    > > > direct them to move to specific idle states, F0 through Fx. When all
    > > > components within a device may be moved out of F0, then the entire
    > > device
    > > > may also be moved out of F0. This is indicated by a callback from PoFx
    > > > to
    > > > your driver, which if you're smart will be KMDF, handling this part for
    > > > you.
    > > > (See the use of WdfDeviceWdmAssignPowerFrameworkSettings above.)
    > > >
    > > > Many, many devices have no real states between "on" and "off." For
    > > these
    > > > devices, it makes sense to report one component with one F-state, F0.
    > > > When
    > > > it's idle, PoFx will tell the entire device that it can leave D0. The
    > > > target D-state depends entirely on whether you need active wake
    > signals.
    > > >
    > > > So imagine that you're writing the driver for a sensor. It needs to be
    > > > turned on when you're taking measurements. It probably also needs to
    > be
    > > > turned on in a calibration phase. For these things, if possible, I
    > > > would
    > > > just use a power managed queue and let the device be turned off when
    > > > you're
    > > > not using it.
    > > >
    > > > The exact conditions for when a device must be turned on vary greatly
    > > from
    > > > device class to device class. If you want to ask about specific
    > > > classes,
    > > > I'll try to help.
    > > >
    > > > To answer your specific question about whether a driver can know when
    > > the
    > > > screen got turned off, the answer is yet, but that's rarely the right
    > > > question to be asking.
    > > >
    > > > Jake Oshins
    > > > Windows Kernel Team
    > > >
    > > > This message offers no warranties and confers no rights.
    > > >
    > > > -----------------------------------------------------------
    > > >
    > > > "Vodicka, Michal" wrote in message news:xxxxx@ntdev...
    > > >
    > > > > You get a very interesting set of relationships, especially regarding
    > > > > power.
    > > >
    > > > Yes, this is what I mean. Interesting and it is unclear who is
    > > > responsible
    > > > for what. Currently I have SPI device but it is the same for I2C, data
    > > > lines
    > > > are separate from power ones.
    > > >
    > > > As a side note I like SPB architecture. One driver can be used for both
    > > > I2C
    > > > and SPI devices with almost no additional work.
    > > >
    > > > > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > > > > about here.
    > > >
    > > > Actually, wake is only part of the question. First I'd need to know how
    > > > should my driver decide when to power off the device. When user of
    > > > phone/tablet presses power button, the system should remain in S0 and
    > > > minimize power consumption. Turn off display and all unnecessary
    > > > devices.
    > > > One of my questions is how is the driver notified about this event?
    > > > Well,
    > > > I'm just preparing experiment which could reveal it but I have a feeling
    > > > it
    > > > isn't the right way how to get such an info ;-)
    > > >
    > > > Michal
    > > >
    > > > > -----Original Message-----
    > > > > From: xxxxx@lists.osr.com [mailto:bounce-506849-
    > > > > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    > > > > Sent: Thursday, June 28, 2012 8:32 PM
    > > > > To: Windows System Software Devs Interest List
    > > > > Subject: RE:[ntdev] Runtime power management in Windows 8
    > > > >
    > > > > <quote>
    > > > > It differs from other stacks because there is SPB controller driver
    > > > > and
    > > > > function device driver opens it as remote target
    > > > > </quote>
    > > > >
    > > > > This is tied to what I think is one of the most interesting and
    > > > > significant
    > > > > architectural changes in Win8 in my mind.
    > > > >
    > > > > Prior to Win8, we always had devices in a branch of the device tree
    > > > > that
    > > > > terminated in a single place. A device got its data, its power, and
    > > > > its
    > > > > interrupts from a single place. The model, really, was PCI. Your bus
    > > > > driver is
    > > > > responsible for giving you your interrupts, provides the hardware
    > > > > resources
    > > > > from which you receive your data, and can manipulate the power on
    > the
    > > > slot
    > > > > into which your device is plugged. All relatively simple.
    > > > >
    > > > > Sure, we've attempted to deal with cross-branch power dependencies
    > > and
    > > > > such things, but never truly successfully.
    > > > >
    > > > > Enter Win8. NOW, your device can get its data from the I2C bus, gets
    > > > > its
    > > > > interrupts from one ore more GPIO lines, and the power? Well, the
    > > power
    > > > > for your device is probably controlled by somebody entirely different.
    > > > > And
    > > > > possibly, but not necessarily, the power for the I2C (where you get
    > > > > your
    > > > > data) and the power for the GPIO (where you get your interrupt) is
    > > > > supplied
    > > > > by somebody else yet.
    > > > >
    > > > > You get a very interesting set of relationships, especially regarding
    > > > > power.
    > > > >
    > > > > When you combine this with the fact that your device can have multiple
    > > > > "functional" power states within D0, and very rapidly transition into
    > > > > and
    > > > > outof these functional power states, you get some very interesting
    > > power
    > > > > management capabilities and issues.
    > > > >
    > > > > THEN you need to factor-in WAKE, which is what you're (mostly) asking
    > > > > about
    > > > > here.
    > > > >
    > > > > Whew!
    > > > >
    > > > > Peter
    > > > > OSR
    > > > >
    > > > > ---
    > > > > NTDEV is sponsored by OSR
    > > > >
    > > > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > > > http://www.osr.com/seminars
    > > > >
    > > > > To unsubscribe, visit the List Server section of OSR Online at
    > > > > http://www.osronline.com/page.cfm?name=ListServer
    > > >
    > > > NOTE: The information in this message is intended for the personal and
    > > > confidential use of the designated recipient(s) named above. To the
    > > > extent
    > > > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > > > agreement that contains an obligation of confidentiality, with
    > > > AuthenTec,
    > > > then this message and/or any attachments shall be considered
    > > > confidential
    > > > information and subject to the confidentiality terms of that agreement.
    > > > If
    > > > the reader of this message is not the intended recipient named above,
    > > > you
    > > > are notified that you have received this document in error, and any
    > > > review,
    > > > dissemination, distribution or copying of this message is strictly
    > > > prohibited. If you have received this document in error, please delete
    > > > the
    > > > original message and notify the sender immediately.
    > > > Thank You!
    > > > AuthenTec, Inc. http://www.authentec.com/
    > > >
    > > >
    > > > ---
    > > > NTDEV is sponsored by OSR
    > > >
    > > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > > http://www.osr.com/seminars
    > > >
    > > > To unsubscribe, visit the List Server section of OSR Online at
    > > > http://www.osronline.com/page.cfm?name=ListServer
    > >
    > > NOTE: The information in this message is intended for the personal and
    > > confidential use of the designated recipient(s) named above. To the extent
    > > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > > agreement that contains an obligation of confidentiality, with AuthenTec,
    > > then this message and/or any attachments shall be considered confidential
    > > information and subject to the confidentiality terms of that agreement.
    > > If
    > > the reader of this message is not the intended recipient named above, you
    > > are notified that you have received this document in error, and any
    > > review,
    > > dissemination, distribution or copying of this message is strictly
    > > prohibited. If you have received this document in error, please delete the
    > > original message and notify the sender immediately.
    > > Thank You!
    > > AuthenTec, Inc. http://www.authentec.com/
    > >
    > >
    > > ---
    > > NTDEV is sponsored by OSR
    > >
    > > For our schedule of WDF, WDM, debugging and other seminars visit:
    > > http://www.osr.com/seminars
    > >
    > > To unsubscribe, visit the List Server section of OSR Online at
    > > http://www.osronline.com/page.cfm?name=ListServer
    >
    > NOTE: The information in this message is intended for the personal and
    > confidential use of the designated recipient(s) named above. To the extent
    > the recipient(s) is/are bound by a non-disclosure agreement, or other
    > agreement that contains an obligation of confidentiality, with AuthenTec,
    > then this message and/or any attachments shall be considered confidential
    > information and subject to the confidentiality terms of that agreement. If
    > the reader of this message is not the intended recipient named above, you
    > are notified that you have received this document in error, and any review,
    > dissemination, distribution or copying of this message is strictly
    > prohibited. If you have received this document in error, please delete the
    > original message and notify the sender immediately.
    > Thank You!
    > AuthenTec, Inc. http://www.authentec.com/
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    >Is there a direct PoRegisterPowerSettingCallback equivalent for UMDF driver?

    Try RegisterPowerSettingNotification

    Don't know whether window-based notifications will be sent to UMDF driver.

    --
    Maxim S. Shatskih
    Windows DDK MVP
    xxxxx@storagecraft.com
    http://www.storagecraft.com
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Thanks. I don't know it, too, will have to try. Hopefully yes, driver is running in a context of a normal process, not a service.

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-507062-
    > xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
    > Sent: Sunday, July 01, 2012 9:36 PM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Re:Runtime power management in Windows 8
    >
    > >Is there a direct PoRegisterPowerSettingCallback equivalent for UMDF
    > driver?
    >
    > Try RegisterPowerSettingNotification
    >
    > Don't know whether window-based notifications will be sent to UMDF
    > driver.
    >
    > --
    > Maxim S. Shatskih
    > Windows DDK MVP
    > xxxxx@storagecraft.com
    > http://www.storagecraft.com
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    >process, not a service.

    This "normal process" is a child of a service.

    --
    Maxim S. Shatskih
    Windows DDK MVP
    xxxxx@storagecraft.com
    http://www.storagecraft.com
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    That's right, I forgot...

    Michal

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-507161-
    > xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
    > Sent: Tuesday, July 03, 2012 12:30 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] Re:Re:Runtime power management in Windows 8
    >
    > >process, not a service.
    >
    > This "normal process" is a child of a service.
    >
    > --
    > Maxim S. Shatskih
    > Windows DDK MVP
    > xxxxx@storagecraft.com
    > http://www.storagecraft.com
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer

    NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
    Thank You!
    AuthenTec, Inc. http://www.authentec.com/
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA