Power Management in Cypress EZ USB FX

NTDEV
1

Hi,
I am implementing Power Management in my driver for Cypress EZUSB FX
based device on windows 2000. (I have put a firmware on the board, where
“remote wakeup” bit has been enabled)

I receive following values for device capabilities in my driver.

Array of SystemState
SystemUndefined DeviceUndefined
S0 D2
S1 D2
S2 D3
S3 D3
S4 D3
S5 D3

DeviceWake D2
SystemWake S1
WakeFromD2 1

My Questions:

  1. Where is the working Device Power State “PowerDeviceD0”?

  2. This device does support remote wakeup (DDK says that if DeviceWake
    and SystemWake are both NON zero, then remote wakeup is supported).
    However, on going to StandBy, I receive power IRP for S3 state. Should
    the device be allowed to go to StandBy, even though SystemWake is S1.

  3. When I send my host to standby which is S3 state on my host, I have
    to request a Power IRP for device state D3.
    On Resume (From the Standby button on host), I power up my host to S0
    and the device to D2 (as per mapping).
    But the device is not fully powered up and hence cannot be accessed.
    Should I set my device state to D0, even when the deviceCap does not
    support D0.

TIA

Rahul

2

You device always supports D0. The D states in the mapping table are
the *deepest* D states the device can go into for that state, not the
lightest states. This means that when you get an S0 irp, you should map
it to a D0 state. As a general rule, you should only need to look at
DeviceWake and SystemWake. The table is the raw information from which
these 2 values are set for you.

As for denying S3 because you can’t wake the machine, this is a
dangerous game to play. Imagine that there is another driver on the
machine that can only wake from S3 and not S1 and it has the same logic
as yours (deny S1 so that it can wake from S3). Now the machine can’t
go into any sleep state b/c both of the drivers are mutually exclusive
in terms of their power needs. (As an aside, if you are going to fail
system states, you need to do this in query power, not set power. Once
you get a set power you *must* respect it).

So, what you should do is register the GUID_POWER_DEVICE_WAKE_ENABLE.
It’s buffer is a BOOLEAN. This guid corresponds to the Power management
tab in device manager. This allows a user to control if your device
wake’s the machine or not. This way, a user can get out of the stuck
situation.

Your system state power management code looks like this

If (query system S state is deeper then wake S state && wake enabled)
Fail query

If (set S state is deeper then wake S state)
Request D3 irp
Else if (set s State is = or lighter then wake s state)
If (wake enabled)
Request wait wake irp
Request D2 (or whatever DeviceWake is)
Else
Request D3

Now you will also have to deal with canceling the wake request when you
come back into D0 and you didn’t wake the machine.

D

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of rahul gupta
Sent: Wednesday, February 11, 2004 6:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Power Management in Cypress EZ USB FX

Hi,
I am implementing Power Management in my driver for Cypress EZUSB FX
based device on windows 2000. (I have put a firmware on the board, where
“remote wakeup” bit has been enabled)

I receive following values for device capabilities in my driver.

Array of SystemState
SystemUndefined DeviceUndefined
S0 D2
S1 D2
S2 D3
S3 D3
S4 D3
S5 D3

DeviceWake D2
SystemWake S1
WakeFromD2 1

My Questions:

  1. Where is the working Device Power State “PowerDeviceD0”?

  2. This device does support remote wakeup (DDK says that if DeviceWake
    and SystemWake are both NON zero, then remote wakeup is supported).
    However, on going to StandBy, I receive power IRP for S3 state. Should
    the device be allowed to go to StandBy, even though SystemWake is S1.

  3. When I send my host to standby which is S3 state on my host, I have
    to request a Power IRP for device state D3.
    On Resume (From the Standby button on host), I power up my host to S0
    and the device to D2 (as per mapping).
    But the device is not fully powered up and hence cannot be accessed.
    Should I set my device state to D0, even when the deviceCap does not
    support D0.

TIA

Rahul

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

> ----------

From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Wednesday, February 11, 2004 6:12 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

As for denying S3 because you can’t wake the machine, this is a
dangerous game to play. Imagine that there is another driver on the
machine that can only wake from S3 and not S1 and it has the same logic
as yours (deny S1 so that it can wake from S3). Now the machine can’t
go into any sleep state b/c both of the drivers are mutually exclusive
in terms of their power needs.

It is even worse. Ordinal user has no choice if S1 or S3 is used for OS
suspend so if driver denies one Sx state, it can effectively disable machine
suspend. IMHO it is pretty arrogant from driver to deny Sx state just
because device can’t wake machine from it.

So, what you should do is register the GUID_POWER_DEVICE_WAKE_ENABLE.
It’s buffer is a BOOLEAN. This guid corresponds to the Power management
tab in device manager. This allows a user to control if your device
wake’s the machine or not. This way, a user can get out of the stuck
situation.

Supporting this GUID is a good idea but not for this reason. You’re right it
can be used to avoid this problem but try to explain it to users.
Appropriate checkbox is named “Allow this device to bring the computer out
of standby” and there is no obvious connection to the situation when device
denied suspend.

Your system state power management code looks like this

If (query system S state is deeper then wake S state && wake enabled)
Fail query

This logic is used in BulkUsb DDK sample and is IMHO flawed for above
reasons. I wrote a driver based on this sample and had to change it because
of bad users’ experience. There was a laptop which could be normally
suspended with no problem but when our USB device was plugged in, nice
dialog claiming our device denied suspend was displayed instead. User’s
impression was our device is wrong and he was right.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

4

All true, the error reporting is pretty bad in terms of this behavior.
There is one twist on the denying system power. If you knew the
lightest machine sleep state and always succeeded the query for this
power state, no matter if you could wake or not, then denying deeper
states would work. Obviously all drivers would need to follow this
philosophy for this to work.

As for why to deny a system state b/c you can’t wake the machine, you
have the same error reporting problem. Let’s say I as a user check the
box for my keyboard so that it can wake the machine (but only from S1).
The machine goes to S3 and the user hits the keyboard to try to wake the
machine, but it doesn’t work. The user has no idea why the thing they
explicitly enabled doesn’t work. Denying the system state where you
can’t wake the machine is currently the only available recourse a driver
has.

D

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, February 11, 2004 11:00 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Wednesday, February 11, 2004 6:12 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

As for denying S3 because you can’t wake the machine, this is a
dangerous game to play. Imagine that there is another driver on the
machine that can only wake from S3 and not S1 and it has the same
logic
as yours (deny S1 so that it can wake from S3). Now the machine can’t
go into any sleep state b/c both of the drivers are mutually exclusive
in terms of their power needs.

It is even worse. Ordinal user has no choice if S1 or S3 is used for OS
suspend so if driver denies one Sx state, it can effectively disable
machine
suspend. IMHO it is pretty arrogant from driver to deny Sx state just
because device can’t wake machine from it.

So, what you should do is register the GUID_POWER_DEVICE_WAKE_ENABLE.
It’s buffer is a BOOLEAN. This guid corresponds to the Power
management
tab in device manager. This allows a user to control if your device
wake’s the machine or not. This way, a user can get out of the stuck
situation.

Supporting this GUID is a good idea but not for this reason. You’re
right it
can be used to avoid this problem but try to explain it to users.
Appropriate checkbox is named “Allow this device to bring the computer
out
of standby” and there is no obvious connection to the situation when
device
denied suspend.

Your system state power management code looks like this

If (query system S state is deeper then wake S state && wake enabled)
Fail query

This logic is used in BulkUsb DDK sample and is IMHO flawed for above
reasons. I wrote a driver based on this sample and had to change it
because
of bad users’ experience. There was a laptop which could be normally
suspended with no problem but when our USB device was plugged in, nice
dialog claiming our device denied suspend was displayed instead. User’s
impression was our device is wrong and he was right.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

> ----------

From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Wednesday, February 11, 2004 8:15 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

All true, the error reporting is pretty bad in terms of this behavior.
There is one twist on the denying system power. If you knew the
lightest machine sleep state and always succeeded the query for this
power state, no matter if you could wake or not, then denying deeper
states would work. Obviously all drivers would need to follow this
philosophy for this to work.

I’m not sure if understand. Does it mean if deeper states are denied, OS
tries the lightest one? My experience is different but I haven’t examined it
very closely and can be wrong.

BTW, HCT test would fail if above is applied. It requires both S1 and S3
support and device must not deny any state. So the result depends on machine
configuration; if device can wake machine from both S1 and S3 test would
pass and fail otherwise.

As for why to deny a system state b/c you can’t wake the machine, you
have the same error reporting problem. Let’s say I as a user check the
box for my keyboard so that it can wake the machine (but only from S1).
The machine goes to S3 and the user hits the keyboard to try to wake the
machine, but it doesn’t work. The user has no idea why the thing they
explicitly enabled doesn’t work. Denying the system state where you
can’t wake the machine is currently the only available recourse a driver
has.

If driver is able to distinguish if S1 or S3 state is used for system
suspend, it could enable or disable the checkbox (GUID) to indicate wake is
or isn’t supported. Is there a way how to find it? It is possible to find
which Sx states are supported but if both S1 and S3 are available, which one
OS chooses? SetSuspendState() API doesn’t allow to select, only
NtInitiatePowerAction() (used by HCT tests) does.

You’re right above is a problem but as an user I’d prefer unavailable wake
against drained notebook batteries. The strategy can depend on device type.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

6

The system will cycle backwards from deepest to lightest sleep states in
the query phase of sleep. The function which tells you which S states
the machine is capable of is currently not documented. I will ask the
API owner if this is something we should doc and expose.

D

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, February 11, 2004 12:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Wednesday, February 11, 2004 8:15 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

All true, the error reporting is pretty bad in terms of this behavior.
There is one twist on the denying system power. If you knew the
lightest machine sleep state and always succeeded the query for this
power state, no matter if you could wake or not, then denying deeper
states would work. Obviously all drivers would need to follow this
philosophy for this to work.

I’m not sure if understand. Does it mean if deeper states are denied, OS
tries the lightest one? My experience is different but I haven’t
examined it
very closely and can be wrong.

BTW, HCT test would fail if above is applied. It requires both S1 and S3
support and device must not deny any state. So the result depends on
machine
configuration; if device can wake machine from both S1 and S3 test would
pass and fail otherwise.

As for why to deny a system state b/c you can’t wake the machine, you
have the same error reporting problem. Let’s say I as a user check
the
box for my keyboard so that it can wake the machine (but only from
S1).
The machine goes to S3 and the user hits the keyboard to try to wake
the
machine, but it doesn’t work. The user has no idea why the thing they
explicitly enabled doesn’t work. Denying the system state where you
can’t wake the machine is currently the only available recourse a
driver
has.

If driver is able to distinguish if S1 or S3 state is used for system
suspend, it could enable or disable the checkbox (GUID) to indicate wake
is
or isn’t supported. Is there a way how to find it? It is possible to
find
which Sx states are supported but if both S1 and S3 are available, which
one
OS chooses? SetSuspendState() API doesn’t allow to select, only
NtInitiatePowerAction() (used by HCT tests) does.

You’re right above is a problem but as an user I’d prefer unavailable
wake
against drained notebook batteries. The strategy can depend on device
type.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

> ----------

From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Wednesday, February 11, 2004 9:46 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

The system will cycle backwards from deepest to lightest sleep states in
the query phase of sleep. The function which tells you which S states
the machine is capable of is currently not documented. I will ask the
API owner if this is something we should doc and expose.

I guess you mean ZwPowerInformation(); yes, it would be nice if it is
documented. There should be no reason against it if there are user mode
equivalents (as GetPwrCapabilities()).

It would be also nice if DDK samples are updated accordingly. But there is
still a problem with HCT; anyway, BulkUsb doesn’t pass as written today.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

8

Which almost suggests that we need some user interface phycologists to get
involved here, and come up with a clear and understandable way of describing
‘light sleep’ and ‘deeper sleep’ to a user at the time they need to know.
Ie: they have keyboard wakeup checked (which will only work in S1) and they
implicitly have the wakeup button enabled, which works in any state
including S5. They are on a cross-country flight, know the battery is
getting low, and want to leave some for New york when they get there, so
they click ‘go to sleep’.

Maybe then would be a good time to pop up a box that says
_ Keyboard can wake the machine, but batteries run down quick
_ Batteries last a long time, but keybaord can’t wake the machine
_ Batteries last a really long time, but modem (which isn’t
connected) can’t wake the machine
_ Don’t ask me this stupid question again!

Loren

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, February 11, 2004 11:15 AM
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

All true, the error reporting is pretty bad in terms of this behavior.
There is one twist on the denying system power. If you knew the
lightest machine sleep state and always succeeded the query for this
power state, no matter if you could wake or not, then denying deeper
states would work. Obviously all drivers would need to follow this
philosophy for this to work.

As for why to deny a system state b/c you can’t wake the machine, you
have the same error reporting problem. Let’s say I as a user check the
box for my keyboard so that it can wake the machine (but only from S1).
The machine goes to S3 and the user hits the keyboard to try to wake the
machine, but it doesn’t work. The user has no idea why the thing they
explicitly enabled doesn’t work. Denying the system state where you
can’t wake the machine is currently the only available recourse a driver
has.

9

Thanks !!
for such a great discussion.

Since my device is furhter connected to a transducer it can get data
anytime and hence should always be enabled to remotely wake up host.
I will have to stop my system to go in power states deeper than the
systemwake.
(As Doran suggested).

Rahul Gupta

On Wed, 2004-02-11 at 22:42, Doron Holan wrote:

You device always supports D0. The D states in the mapping table are
the *deepest* D states the device can go into for that state, not the
lightest states. This means that when you get an S0 irp, you should map
it to a D0 state. As a general rule, you should only need to look at
DeviceWake and SystemWake. The table is the raw information from which
these 2 values are set for you.

As for denying S3 because you can’t wake the machine, this is a
dangerous game to play. Imagine that there is another driver on the
machine that can only wake from S3 and not S1 and it has the same logic
as yours (deny S1 so that it can wake from S3). Now the machine can’t
go into any sleep state b/c both of the drivers are mutually exclusive
in terms of their power needs. (As an aside, if you are going to fail
system states, you need to do this in query power, not set power. Once
you get a set power you *must* respect it).

So, what you should do is register the GUID_POWER_DEVICE_WAKE_ENABLE.
It’s buffer is a BOOLEAN. This guid corresponds to the Power management
tab in device manager. This allows a user to control if your device
wake’s the machine or not. This way, a user can get out of the stuck
situation.

Your system state power management code looks like this

If (query system S state is deeper then wake S state && wake enabled)
Fail query

If (set S state is deeper then wake S state)
Request D3 irp
Else if (set s State is = or lighter then wake s state)
If (wake enabled)
Request wait wake irp
Request D2 (or whatever DeviceWake is)
Else
Request D3

Now you will also have to deal with canceling the wake request when you
come back into D0 and you didn’t wake the machine.

D

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of rahul gupta
Sent: Wednesday, February 11, 2004 6:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Power Management in Cypress EZ USB FX

Hi,
I am implementing Power Management in my driver for Cypress EZUSB FX
based device on windows 2000. (I have put a firmware on the board, where
“remote wakeup” bit has been enabled)

I receive following values for device capabilities in my driver.

Array of SystemState
SystemUndefined DeviceUndefined
S0 D2
S1 D2
S2 D3
S3 D3
S4 D3
S5 D3

DeviceWake D2
SystemWake S1
WakeFromD2 1

My Questions:

  1. Where is the working Device Power State “PowerDeviceD0”?

  2. This device does support remote wakeup (DDK says that if DeviceWake
    and SystemWake are both NON zero, then remote wakeup is supported).
    However, on going to StandBy, I receive power IRP for S3 state. Should
    the device be allowed to go to StandBy, even though SystemWake is S1.

  3. When I send my host to standby which is S3 state on my host, I have
    to request a Power IRP for device state D3.
    On Resume (From the Standby button on host), I power up my host to S0
    and the device to D2 (as per mapping).
    But the device is not fully powered up and hence cannot be accessed.
    Should I set my device state to D0, even when the deviceCap does not
    support D0.

TIA

Rahul

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@dcmtech.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com

10

> It is even worse. Ordinal user has no choice if S1 or S3 is used for OS

suspend so if driver denies one Sx state, it can effectively disable machine
suspend. IMHO it is pretty arrogant from driver to deny Sx state just
because device can’t wake machine from it.

USB mouse does this on regular basis. The system just suspends to a higher
state. If S3 is vetoed - it suspends to S2.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

11

> You’re right above is a problem but as an user I’d prefer unavailable wake

against drained notebook batteries. The strategy can depend on device type.

No device must veto hibernate, and notebook hibernates on low batteries.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

12

Again, please expose this through the WMI guid so a user has a way to
disable this behavior (denying the S state b/c you can’t wake). What
external impetus causes the wake? Is this something that the user truly
needs? Will data be lost forever that cannot be lost?

The ability to wake the machine purely for the sake of waking the
machine is not reason enough to do it.

D

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of rahul gupta
Sent: Thursday, February 12, 2004 10:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

Thanks !!
for such a great discussion.

Since my device is furhter connected to a transducer it can get data
anytime and hence should always be enabled to remotely wake up host.
I will have to stop my system to go in power states deeper than the
systemwake.
(As Doran suggested).

Rahul Gupta

On Wed, 2004-02-11 at 22:42, Doron Holan wrote:

You device always supports D0. The D states in the mapping table are
the *deepest* D states the device can go into for that state, not the
lightest states. This means that when you get an S0 irp, you should
map
it to a D0 state. As a general rule, you should only need to look at
DeviceWake and SystemWake. The table is the raw information from
which
these 2 values are set for you.

As for denying S3 because you can’t wake the machine, this is a
dangerous game to play. Imagine that there is another driver on the
machine that can only wake from S3 and not S1 and it has the same
logic
as yours (deny S1 so that it can wake from S3). Now the machine can’t
go into any sleep state b/c both of the drivers are mutually exclusive
in terms of their power needs. (As an aside, if you are going to fail
system states, you need to do this in query power, not set power.
Once
you get a set power you *must* respect it).

So, what you should do is register the GUID_POWER_DEVICE_WAKE_ENABLE.
It’s buffer is a BOOLEAN. This guid corresponds to the Power
management
tab in device manager. This allows a user to control if your device
wake’s the machine or not. This way, a user can get out of the stuck
situation.

Your system state power management code looks like this

If (query system S state is deeper then wake S state && wake enabled)
Fail query

If (set S state is deeper then wake S state)
Request D3 irp
Else if (set s State is = or lighter then wake s state)
If (wake enabled)
Request wait wake irp
Request D2 (or whatever DeviceWake is)
Else
Request D3

Now you will also have to deal with canceling the wake request when
you
come back into D0 and you didn’t wake the machine.

D

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of rahul gupta
Sent: Wednesday, February 11, 2004 6:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Power Management in Cypress EZ USB FX

Hi,
I am implementing Power Management in my driver for Cypress EZUSB FX
based device on windows 2000. (I have put a firmware on the board,
where
“remote wakeup” bit has been enabled)

I receive following values for device capabilities in my driver.

Array of SystemState
SystemUndefined DeviceUndefined
S0 D2
S1 D2
S2 D3
S3 D3
S4 D3
S5 D3

DeviceWake D2
SystemWake S1
WakeFromD2 1

My Questions:

  1. Where is the working Device Power State “PowerDeviceD0”?

  2. This device does support remote wakeup (DDK says that if DeviceWake
    and SystemWake are both NON zero, then remote wakeup is supported).
    However, on going to StandBy, I receive power IRP for S3 state. Should
    the device be allowed to go to StandBy, even though SystemWake is S1.

  3. When I send my host to standby which is S3 state on my host, I have
    to request a Power IRP for device state D3.
    On Resume (From the Standby button on host), I power up my host to S0
    and the device to D2 (as per mapping).
    But the device is not fully powered up and hence cannot be accessed.
    Should I set my device state to D0, even when the deviceCap does not
    support D0.

TIA

Rahul

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@dcmtech.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

13

This situation is rarely a problem, since it is never the case that wake
from S3 works and wake from S1 doesn’t work. There’s no way to express this
sort of situation in the ACPI spec, and nobody building hardware that would
want to express it.

–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no rights.

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> It is even worse. Ordinal user has no choice if S1 or S3 is used for OS
>> suspend so if driver denies one Sx state, it can effectively disable
>> machine
>> suspend. IMHO it is pretty arrogant from driver to deny Sx state just
>> because device can’t wake machine from it.
>
> USB mouse does this on regular basis. The system just suspends to a higher
> state. If S3 is vetoed - it suspends to S2.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

14

> ----------

From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, February 13, 2004 9:51 AM
To: xxxxx@lists.osr.com
Subject: Re: [ntdev] Power Management in Cypress EZ USB FX

> You’re right above is a problem but as an user I’d prefer unavailable
wake
> against drained notebook batteries. The strategy can depend on device
type.

No device must veto hibernate, and notebook hibernates on low batteries.

But first it usually suspends so veto will cause unnecessary battery drain.
Anyway, at least this rule should be followed.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

15

> ----------

From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, February 13, 2004 9:47 AM
To: xxxxx@lists.osr.com
Subject: Re: [ntdev] Power Management in Cypress EZ USB FX

> It is even worse. Ordinal user has no choice if S1 or S3 is used for OS
> suspend so if driver denies one Sx state, it can effectively disable
machine
> suspend. IMHO it is pretty arrogant from driver to deny Sx state just
> because device can’t wake machine from it.

USB mouse does this on regular basis. The system just suspends to a higher
state. If S3 is vetoed - it suspends to S2.

You’re right, mouclass is written this way. But bulkusb DDK sample was fixed
in the latest DDK to not veto any S state. The problem is if there is no
higher S state available. I have several computers here including notebooks
which support S1 or S3 but not both. Notebook which supports S3 only doesn’t
support wake from this state so if our device vetoes it, it would disable
suspend. Device is built-in and I believe users would like us.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

16

So if driver knows the lightest suspend state and never vetoes it as Doron
suggested, it would work. Shouldn’t be mouclass updated this way?

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, February 13, 2004 6:16 PM
To: xxxxx@lists.osr.com
Subject: Re:[ntdev] Power Management in Cypress EZ USB FX

This situation is rarely a problem, since it is never the case that wake
from S3 works and wake from S1 doesn’t work. There’s no way to express
this
sort of situation in the ACPI spec, and nobody building hardware that
would
want to express it.

–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no
rights.

“Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> >> It is even worse. Ordinal user has no choice if S1 or S3 is used for OS
> >> suspend so if driver denies one Sx state, it can effectively disable
> >> machine
> >> suspend. IMHO it is pretty arrogant from driver to deny Sx state just
> >> because device can’t wake machine from it.
> >
> > USB mouse does this on regular basis. The system just suspends to a
> higher
> > state. If S3 is vetoed - it suspends to S2.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: michal.vodicka@st.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

17

As the previous owner of mouclass, I can attest to how it works (which
is exactly the same as kbdclass) …

Basically mouclass will only automatically enable wait wake on the mouse
if the mouse can wake the machine from its deepest sleep state. If it
can’t, then wait wake is not automatically armed but the user still has
a choice to arm the device. This is XP and beyond behavior. On win2k,
no automatic arming occurred.

The mouse not being able to wake from the deepest sleep state can occur
b/c the usb controller doesn’t by default allow wake from S3 even if it
is enabled at the PCI/ACPI level. This would lead to a machine with S3
and S1 wake, but where the usb mouse would only wake from S1.

Mouclass wouldn’t really have to check for the lightest sleep state and
allow it based on the usb controller’s behavior (basically, if it can
wake the machine, we know it can do it from the lightest state)

D

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, February 13, 2004 11:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

So if driver knows the lightest suspend state and never vetoes it as
Doron
suggested, it would work. Shouldn’t be mouclass updated this way?

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, February 13, 2004 6:16 PM
To: xxxxx@lists.osr.com
Subject: Re:[ntdev] Power Management in Cypress EZ USB FX

This situation is rarely a problem, since it is never the case that
wake
from S3 works and wake from S1 doesn’t work. There’s no way to
express
this
sort of situation in the ACPI spec, and nobody building hardware that
would
want to express it.

–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no
rights.

“Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> >> It is even worse. Ordinal user has no choice if S1 or S3 is used
for OS
> >> suspend so if driver denies one Sx state, it can effectively
disable
> >> machine
> >> suspend. IMHO it is pretty arrogant from driver to deny Sx state
just
> >> because device can’t wake machine from it.
> >
> > USB mouse does this on regular basis. The system just suspends to a
> higher
> > state. If S3 is vetoed - it suspends to S2.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: michal.vodicka@st.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

18

> > USB mouse does this on regular basis. The system just suspends to a higher

> state. If S3 is vetoed - it suspends to S2.
>
You’re right, mouclass is written this way. But bulkusb DDK sample was fixed
in the latest DDK to not veto any S state. The problem is if there is no
higher S state available. I have several computers here including notebooks
which support S1 or S3 but not both. Notebook which supports S3 only doesn’t

Some notebooks suspend to S3 without the USB mouse (power LED blinks) and to S2
with the mouse (power LED is on).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

19

usb has power in all of these sleep states, it is just that the usb core
disables the controller in S3 b/c almost every single chipset out there
didn’t get it right for S3 w/regard to USB. What you are seeing (mouse
is powered on S2) is this very issue.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Friday, February 13, 2004 11:24 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Power Management in Cypress EZ USB FX

> USB mouse does this on regular basis. The system just suspends to a
higher
> state. If S3 is vetoed - it suspends to S2.
>
You’re right, mouclass is written this way. But bulkusb DDK sample was
fixed
in the latest DDK to not veto any S state. The problem is if there is
no
higher S state available. I have several computers here including
notebooks
which support S1 or S3 but not both. Notebook which supports S3 only
doesn’t

Some notebooks suspend to S3 without the USB mouse (power LED blinks)
and to S2
with the mouse (power LED is on).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

20

> ----------

From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, February 13, 2004 8:17 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] Power Management in Cypress EZ USB FX

Mouclass wouldn’t really have to check for the lightest sleep state and
allow it based on the usb controller’s behavior (basically, if it can
wake the machine, we know it can do it from the lightest state)

In other words, if system sets SystemWake in device capabilities to
something higher than S0 and DeviceWake higher than D0, device can wake
system. Right? As mouclass.h defines it:

#define WAITWAKE_SUPPORTED(port) ((port)->MinDeviceWakeState > PowerDeviceD0
&& \
(port)->MinSystemWakeState >
PowerSystemWorking)

If it is true and reliable for all USB devices, it would really simplify
things. I haven’t noticed it before because based my code on BulkUsb sample
which makes decision according to device configuration descriptor:

if(configurationDescriptor->bmAttributes & REMOTE_WAKEUP_MASK)
{
//
// this configuration supports remote wakeup
//
deviceExtension->WaitWakeEnable = 1;
}
else
{
deviceExtension->WaitWakeEnable = 0;
}

This way it is quite possible to have wait wake enabled because device
supports it and SystemWake set to S0 because system doesn’t with all
consequent problems I mentioned before.

Is the following conclusion correct? For devices which support remote wakeup
driver can safely veto S3 and S2 states if greater than
DeviceCapabilities.SystemWake only if DeviceCapabilities.SystemWake > S0
(because system will later ask for DeviceCapabilities.SystemWake).

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]