KMDF system power state to device power state mapping

Hi,

I have been looking a little deeper into the reasons why my FX2 cannot wake
the system from standby.
I do the following thing in the function:
WDF_DEVICE_POWER_POLICY_WAKE_SETTINGS_INIT(&wakeSettings);
wakeSettings.DxState = PowerDeviceD2;
wakeSettings.Enabled = WdfTrue;
status = WdfDeviceAssignSxWakeSettings(Device, &wakeSettings);

NT_SUCCESS(status)) == TRUE after the function call.

If I understand it correctly then this should insure that the lowest DxState
for any given Sx except S5 is PowerDeviceD3. However, as soon as the system
goes to standby the device drops to D3.

In the device manager under device details i see that the Power mappings
are:
S0 -> D0
S1 -> D2
S2 -> D3
S3 -> D3
S4 -> D3
S5 -> D3
which is definitly not what I configured. What could be the cause of this?
Incidently, I noticed that my root hub has the same mappings. could it be
that this is a limitation of my root hub that forces the mappings of my
driver?
If so, I thought the fact that my driver is a power policy owner meant that
it was the one who determined which S state matched which D state?

slightly related to this: when i look at the capabilities, i see:
PDCAP_D0_SUPPORTED
PDCAP_D1_SUPPORTED
PDCAP_D2_SUPPORTED
PDCAP_D3_SUPPORTED
PDCAP_WAKE_FROM_D0_SUPPORTED
PDCAP_WAKE_FROM_D1_SUPPORTED
PDCAP_WAKE_FROM_D2_SUPPORTED
where do these capabilities come from? How does the framework know that my
device supports this, and not wake from D3?

kind regards,
Bruno.

Instead of assigning the DxState explicitly, you should just leave it as
is and KMDF will figure it out for you based on the caps reported by the
PDO. The call to AssignSxWakeSettings will tell KMDF to arm the device
for wake if the Sx state that the machine is going into is a state in
which the device can wake itself up. If the Sx state is deeper then the
deepest Sx state that the device can wake from, you will not be armed
for wake.

What this means is

  1. your device can wake from D0/D1/D2
  2. the deepest D state for S1 is D2, you can wake from this state
  3. the deepest D state for any other Sx state is D3, you cannot wake
    from any of these states.

Calling AssignSxWakeSettings will not change the reported capabilities
of your device, it will use the caps to determine when wake is
appropriate.

These flags
PDCAP_D0_SUPPORTED
PDCAP_D1_SUPPORTED
PDCAP_D2_SUPPORTED
PDCAP_D3_SUPPORTED
PDCAP_WAKE_FROM_D0_SUPPORTED
PDCAP_WAKE_FROM_D1_SUPPORTED
PDCAP_WAKE_FROM_D2_SUPPORTED

are based on the DEVICE_CAPABILITIES that is reported by the stack. By
default, the PDO fills these in for you and the FDO does not change
them. You can change them by calling WdfDeviceSetPnpCapabilities and
WdfDeviceSetPowerCapabilities. These specific flags are based on the
values placed in the following fields in DEVICE_CAPABILITIES

PDCAP_D0_SUPPORTED -> always present
PDCAP_D1_SUPPORTED -> DeviceD1
PDCAP_D2_SUPPORTED -> DeviceD2
PDCAP_D3_SUPPORTED -> always present
PDCAP_WAKE_FROM_D0_SUPPORTED -> WakeFromD0
PDCAP_WAKE_FROM_D1_SUPPORTED -> WakeFromD1
PDCAP_WAKE_FROM_D2_SUPPORTED -> WakeFromD2

In conclusion, the reason you can’t wake from a sleep state is that the
underlying usb core does not support wake from that sleep state.
Changing the reported caps will give the illusion that you can wake from
those settings, but underneath it all, that is not possible.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruno van Dooren
Sent: Thursday, March 02, 2006 1:03 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF system power state to device power state mapping

Hi,

I have been looking a little deeper into the reasons why my FX2 cannot
wake
the system from standby.
I do the following thing in the function:
WDF_DEVICE_POWER_POLICY_WAKE_SETTINGS_INIT(&wakeSettings);
wakeSettings.DxState = PowerDeviceD2;
wakeSettings.Enabled = WdfTrue;
status = WdfDeviceAssignSxWakeSettings(Device, &wakeSettings);

NT_SUCCESS(status)) == TRUE after the function call.

If I understand it correctly then this should insure that the lowest
DxState
for any given Sx except S5 is PowerDeviceD3. However, as soon as the
system
goes to standby the device drops to D3.

In the device manager under device details i see that the Power mappings

are:
S0 -> D0
S1 -> D2
S2 -> D3
S3 -> D3
S4 -> D3
S5 -> D3
which is definitly not what I configured. What could be the cause of
this?
Incidently, I noticed that my root hub has the same mappings. could it
be
that this is a limitation of my root hub that forces the mappings of my
driver?
If so, I thought the fact that my driver is a power policy owner meant
that
it was the one who determined which S state matched which D state?

slightly related to this: when i look at the capabilities, i see:
PDCAP_D0_SUPPORTED
PDCAP_D1_SUPPORTED
PDCAP_D2_SUPPORTED
PDCAP_D3_SUPPORTED
PDCAP_WAKE_FROM_D0_SUPPORTED
PDCAP_WAKE_FROM_D1_SUPPORTED
PDCAP_WAKE_FROM_D2_SUPPORTED
where do these capabilities come from? How does the framework know that
my
device supports this, and not wake from D3?

kind regards,
Bruno.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Hi,
Thanks for your fast reply.

Instead of assigning the DxState explicitly, you should just leave it as
is and KMDF will figure it out for you based on the caps reported by the
PDO.
That means I cannot prevent D3 from happening in a given Sx state if I
understand you correctly.

In conclusion, the reason you can’t wake from a sleep state is that the
underlying usb core does not support wake from that sleep state.
Changing the reported caps will give the illusion that you can wake from
those settings, but underneath it all, that is not possible.

I suspected something like this, but in that case, what is the point of
being able to change the
DxState when configuring AssignSxWakeSettings, and why would I ever need to
use
WdfDeviceSetPowerCapabilities if they should not be changed? perhaps it is
only used
when trying to hide capabilities?

kind regards,
Bruno.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruno van Dooren
Sent: Thursday, March 02, 2006 1:03 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF system power state to device power state mapping

Hi,

I have been looking a little deeper into the reasons why my FX2 cannot
wake
the system from standby.
I do the following thing in the function:
WDF_DEVICE_POWER_POLICY_WAKE_SETTINGS_INIT(&wakeSettings);
wakeSettings.DxState = PowerDeviceD2;
wakeSettings.Enabled = WdfTrue;
status = WdfDeviceAssignSxWakeSettings(Device, &wakeSettings);

NT_SUCCESS(status)) == TRUE after the function call.

If I understand it correctly then this should insure that the lowest
DxState
for any given Sx except S5 is PowerDeviceD3. However, as soon as the
system
goes to standby the device drops to D3.

In the device manager under device details i see that the Power mappings

are:
S0 -> D0
S1 -> D2
S2 -> D3
S3 -> D3
S4 -> D3
S5 -> D3
which is definitly not what I configured. What could be the cause of
this?
Incidently, I noticed that my root hub has the same mappings. could it
be
that this is a limitation of my root hub that forces the mappings of my
driver?
If so, I thought the fact that my driver is a power policy owner meant
that
it was the one who determined which S state matched which D state?

slightly related to this: when i look at the capabilities, i see:
PDCAP_D0_SUPPORTED
PDCAP_D1_SUPPORTED
PDCAP_D2_SUPPORTED
PDCAP_D3_SUPPORTED
PDCAP_WAKE_FROM_D0_SUPPORTED
PDCAP_WAKE_FROM_D1_SUPPORTED
PDCAP_WAKE_FROM_D2_SUPPORTED
where do these capabilities come from? How does the framework know that
my
device supports this, and not wake from D3?

kind regards,
Bruno.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

You can supply DxState if the reported caps are wrong or if you want to
*lighten* the sleep state (let’s say force D1 instead of the default
D2). By default KMDF will do the right thing based on the reported
caps, the field is there to override that behavior.

Same for SetPowerCaps(). You can always lighten any of the settings
without issue. Alternatively, some folks have used it to deepen
settings b/c they new their hardware reported the wrong caps but
underneath it really could wake from a deeper state. Using the caps to
deepen the settings is not support AFAIK, but it does work in limited
cases.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruno van Dooren
Sent: Thursday, March 02, 2006 1:52 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] KMDF system power state to device power state
mapping

Hi,
Thanks for your fast reply.

Instead of assigning the DxState explicitly, you should just leave it
as
is and KMDF will figure it out for you based on the caps reported by
the
PDO.
That means I cannot prevent D3 from happening in a given Sx state if I
understand you correctly.

In conclusion, the reason you can’t wake from a sleep state is that
the
underlying usb core does not support wake from that sleep state.
Changing the reported caps will give the illusion that you can wake
from
those settings, but underneath it all, that is not possible.

I suspected something like this, but in that case, what is the point of
being able to change the
DxState when configuring AssignSxWakeSettings, and why would I ever need
to
use
WdfDeviceSetPowerCapabilities if they should not be changed? perhaps it
is
only used
when trying to hide capabilities?

kind regards,
Bruno.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruno van Dooren
Sent: Thursday, March 02, 2006 1:03 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF system power state to device power state mapping

Hi,

I have been looking a little deeper into the reasons why my FX2 cannot
wake
the system from standby.
I do the following thing in the function:
WDF_DEVICE_POWER_POLICY_WAKE_SETTINGS_INIT(&wakeSettings);
wakeSettings.DxState = PowerDeviceD2;
wakeSettings.Enabled = WdfTrue;
status = WdfDeviceAssignSxWakeSettings(Device, &wakeSettings);

NT_SUCCESS(status)) == TRUE after the function call.

If I understand it correctly then this should insure that the lowest
DxState
for any given Sx except S5 is PowerDeviceD3. However, as soon as the
system
goes to standby the device drops to D3.

In the device manager under device details i see that the Power mappings

are:
S0 -> D0
S1 -> D2
S2 -> D3
S3 -> D3
S4 -> D3
S5 -> D3
which is definitly not what I configured. What could be the cause of
this?
Incidently, I noticed that my root hub has the same mappings. could it
be
that this is a limitation of my root hub that forces the mappings of my
driver?
If so, I thought the fact that my driver is a power policy owner meant
that
it was the one who determined which S state matched which D state?

slightly related to this: when i look at the capabilities, i see:
PDCAP_D0_SUPPORTED
PDCAP_D1_SUPPORTED
PDCAP_D2_SUPPORTED
PDCAP_D3_SUPPORTED
PDCAP_WAKE_FROM_D0_SUPPORTED
PDCAP_WAKE_FROM_D1_SUPPORTED
PDCAP_WAKE_FROM_D2_SUPPORTED
where do these capabilities come from? How does the framework know that
my
device supports this, and not wake from D3?

kind regards,
Bruno.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

“Doron Holan” wrote in message
news:xxxxx@ntdev…
You can supply DxState if the reported caps are wrong or if you want to
lighten the sleep state (let’s say force D1 instead of the default
D2). By default KMDF will do the right thing based on the reported
caps, the field is there to override that behavior.

Same for SetPowerCaps(). You can always lighten any of the settings
without issue. Alternatively, some folks have used it to deepen
settings b/c they new their hardware reported the wrong caps but
underneath it really could wake from a deeper state. Using the caps to
deepen the settings is not support AFAIK, but it does work in limited
cases.

Hello,

sorry to resurrect this topic again, but i want to make sure I finally
understand what you are saying.

Contrary to what I originally thought, WdfDeviceAssignSxWakeSettings does
NOT change which power level the device will fall to when the system enters
a wakeable state like S3 or S4.

rather, it can be used to prevent a device from being armed for wake in all
its wakeable states. for example:
if it is wakeable in D1 and D2, I can prevent it from being armed for wake
in D2.

If I have a device that only supports WAKE_FROM_D2, I can use
WdfDeviceSetPowerCapabilities to change the Sx mappings from D3 to D2, so
that the device will only drop to D2 on S3 or S4. That way it can be armed
for wakeup after all. The only snag is that this may still fail IF the USB
core driver does not allow me to do so.

Is this summary correct?

If this summary of the intention of WdfDeviceAssignSxWakeSettings is
correct, then the KMDF documentation is a bit ambiguous. The documentation
does not explain its meaning in much detail.
the explanation of the WDF_DEVICE_POWER_POLICY_WAKE_SETTINGS structure
DxState member says :
“A DEVICE_POWER_STATE-typed enumerator that identifies the low device power
state that the device will enter when the system power state drops to a
wakeable low-power state.”

This explanation seems to mean what I originally thought it meant, instead
of what I now think you tried to explain to me.

If you agree about this ambiguitiy I will send the feedback to the KMDF
team, but I wanted to make sure first that I now actually understand the
issue.

Thanks for your time.



Kind regards,
Bruno.
xxxxx@hotmail.com
Remove only “_nos_pam”

Yes that is what it means. I fwd’ed the feedback to the doc writer.

Lightening the Sx -> Dx mappings to get yourself armed for wake won’t
work. If the underlying core can support it wake from a particular Sx
state, the mappings will indicate that. By changing just your self of
the reported caps, you have the illusion that you can arm yourself for
wake, but you really won’t be able to.

Also, the Sx->Dx mapping array is the raw data about the bus, you will
also need to set DeviceWake and SystemWake to the appropriately adjusted
values b/c those “cooked” values are based off of the raw mapping array.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruno van Dooren
Sent: Tuesday, March 07, 2006 1:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] KMDF system power state to device power state
mapping

“Doron Holan” wrote in message
news:xxxxx@ntdev…
You can supply DxState if the reported caps are wrong or if you want to
lighten the sleep state (let’s say force D1 instead of the default
D2). By default KMDF will do the right thing based on the reported
caps, the field is there to override that behavior.

Same for SetPowerCaps(). You can always lighten any of the settings
without issue. Alternatively, some folks have used it to deepen
settings b/c they new their hardware reported the wrong caps but
underneath it really could wake from a deeper state. Using the caps to
deepen the settings is not support AFAIK, but it does work in limited
cases.

Hello,

sorry to resurrect this topic again, but i want to make sure I finally
understand what you are saying.

Contrary to what I originally thought, WdfDeviceAssignSxWakeSettings
does
NOT change which power level the device will fall to when the system
enters
a wakeable state like S3 or S4.

rather, it can be used to prevent a device from being armed for wake in
all
its wakeable states. for example:
if it is wakeable in D1 and D2, I can prevent it from being armed for
wake
in D2.

If I have a device that only supports WAKE_FROM_D2, I can use
WdfDeviceSetPowerCapabilities to change the Sx mappings from D3 to D2,
so
that the device will only drop to D2 on S3 or S4. That way it can be
armed
for wakeup after all. The only snag is that this may still fail IF the
USB
core driver does not allow me to do so.

Is this summary correct?

If this summary of the intention of WdfDeviceAssignSxWakeSettings is
correct, then the KMDF documentation is a bit ambiguous. The
documentation
does not explain its meaning in much detail.
the explanation of the WDF_DEVICE_POWER_POLICY_WAKE_SETTINGS structure
DxState member says :
“A DEVICE_POWER_STATE-typed enumerator that identifies the low device
power
state that the device will enter when the system power state drops to a
wakeable low-power state.”

This explanation seems to mean what I originally thought it meant,
instead
of what I now think you tried to explain to me.

If you agree about this ambiguitiy I will send the feedback to the KMDF
team, but I wanted to make sure first that I now actually understand the

issue.

Thanks for your time.



Kind regards,
Bruno.
xxxxx@hotmail.com
Remove only “_nos_pam”


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Yes that is what it means. I fwd’ed the feedback to the doc writer.

Lightening the Sx -> Dx mappings to get yourself armed for wake won’t
work. If the underlying core can support it wake from a particular Sx
state, the mappings will indicate that. By changing just your self of
the reported caps, you have the illusion that you can arm yourself for
wake, but you really won’t be able to.

Excellent.
Thanks a lot for this clear explanation.

Kind regards,
Bruno.
xxxxx@hotmail.com
Remove only “_nos_pam”