Runtime power management in Windows 8

Jake_Oshins · May 31, 2012, 9:54pm

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.

mm1 · May 31, 2012, 10:15pm

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).aspxhttp:
> http://msdn.microsoft.com/en- us/library/windows/hardware/
> ff543186(v=vs.85).aspxhttp:
> http://msdn.microsoft.com/en- us/library/windows/hardware/
> hh967706(v=vs.85).aspxhttp:
> http://msdn.microsoft.com/en- us/library/windows/hardware/
> hh406637(v=vs.85).aspxhttp:
>
> 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=ListServerhttp:
></http:></http:></http:></http:></http:>

SoquelDude · June 1, 2012, 12:17am

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_Oshins · June 1, 2012, 12:00pm

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.

SoquelDude · June 2, 2012, 12:30pm

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_Oshins · June 3, 2012, 7:02pm

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_Rouzanov · June 7, 2012, 12:44am

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_User · June 27, 2012, 1:04pm

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_Oshins · June 27, 2012, 8:33pm

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_User · June 27, 2012, 9:00pm

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_Oshins · June 27, 2012, 9:47pm

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_User · June 27, 2012, 10:07pm

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
Sent: Thursday, June 28, 2012 3:47
To: Windows System Software Devs Interest List
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 · June 28, 2012, 11:58am

OSR_Community_User · June 28, 2012, 12:15pm

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

> 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
>

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 · June 28, 2012, 2:33pm

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

OSR_Community_User · June 28, 2012, 3:10pm

> 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

It differs from other stacks because there is SPB controller driver and
function device driver opens it as remote target

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_Oshins · June 28, 2012, 7:55pm

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

It differs from other stacks because there is SPB controller driver and
function device driver opens it as remote target

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_User · June 28, 2012, 9:09pm

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_Oshins · June 28, 2012, 10:34pm

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_User · June 28, 2012, 10:57pm

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/