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