Question about D3 state

Hi guys,

I’m confused about D3 state concepts. Could you help me to correct my
understanding? Thanks in advance.

  1. In my understanding, when system enter S3 state, all he device will enter
    D3 state automatically. Is it right?
  2. how to test D3 support of my driver? Choose “stand by” from “shut down
    windows” dialog? Is there any tool to test it?
  3. Idle vs D3. I find snippet code from pcidrv(WDK example) below. If there
    no IRP transfer of this driver more than 10 seconds, it will enter idel
    state? But where is Idle callback funciton? Is it right that after 10
    seconds, system will make your driver enter D3 state?

WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS_INIT(&idleSettings,
IdleCanWakeFromS0);
idleSettings.IdleTimeout = 10000; // 10-sec

status = WdfDeviceAssignS0IdleSettings(FdoData->WdfDevice,
&idleSettings);

Marvin

Hi,

  1. It depends on what the power mappings are for each device. At the
    moment I am trying some stuff out where I have mapped my USB devices’
    S3 power state to D2, hence my device will enter D2 state.

  2. Not sure I understand you but your driver knows about the power
    mappings and hence when it receives a S3 request you will issue a
    power request where the D state corresponds to what your S3 state maps
    to.

  3. AFAIK being idle is mapped to D2 state. And yes those settings in
    that code snippet means that the device will enter Idle state when
    there is no IO for it for 10 seconds. There is no idle callback
    function since WDF handles this for you, you just tell it that you
    would like to selectivly suspend your device after some tiem of no IO
    to your device. No the system will not make your driver enter D3 state
    after 10 seconds.

/Faik

On Fri, Jan 21, 2011 at 11:22 AM, Marvin(Fan) Zhang wrote:
> Hi guys,
>
> I’m confused about D3 state concepts. Could you help me to correct my
> understanding? Thanks in advance.
>
> 1. In my understanding, when system enter S3 state, all he device will enter
> D3 state automatically. Is it right?
> 2. how to test D3 support of my driver? Choose “stand by” from “shut down
> windows” dialog? Is there any tool to test it?
> 3. Idle vs D3. I find snippet code from pcidrv(WDK example) below.? If there
> no IRP transfer of this driver more than 10 seconds, it will enter idel
> state? But where is Idle callback funciton? Is it right that after 10
> seconds, system will make your driver enter D3 state?
>
> ??? WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS_INIT(&idleSettings,
> IdleCanWakeFromS0);
> ??? idleSettings.IdleTimeout = 10000; // 10-sec
>
> ??? status = WdfDeviceAssignS0IdleSettings(FdoData->WdfDevice,
> &idleSettings);
>
> Marvin
> — 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

>1. In my understanding, when system enter S3 state, all he device will enter D3 state automatically.

Read MSDN on these states. It describes on what parts of the computer are powered and what are not at S3. IIRC only memory is powered at S3.

I know that laptops with external USB mice allow you to wake the machine from this mouse, but sorry, they just don’t go to S3 in this case, “sleep” maps to S2 (power LED is always on and not blinking).

  1. how to test D3 support of my driver? Choose “stand by” from “shut down windows” dialog? Is there
    any tool to test it?

The tool is called PWRTEST and is included to DTM test suites (together with PNPDTEST and DevPathExer).

And USB SS is actually a must for any good USB device. Without this support, the USB host controller will not be able to suspend, and, since it runs the DMA chain over and over, the north bridge/memory controllers also will not.

This is a major reduction of laptop’s battery life.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

“Marvin(Fan) Zhang” wrote in message
news:xxxxx@ntdev…

> 1. In my understanding, when system enter S3 state, all he device will
> enter
> D3 state automatically. Is it right?

Not automatically. Each driver will be called and given opportunity to
prepare
for the state transition.

–pa

Exactly as described by Pavel, Mr. Shatskih, and Mr. Roumenov.

One of the main jobs of the device’s power policy owner is to decide the D-state the device will be in, given a particular S-state. This is entirely up the the power policy owner. So, S3 = D3 is definitely not automatic (though it is common).

Peter
OSR

Also, NICs are getting VAUX in S3 state. Actually, every PCI device can use VAUX. Legacy keyboard/mouse controller is powered, too. USB host may be partially powered, just to detect wakeup request.

But isn’t supplying VAUX (to the bus slot) technically optional?

Similarly… 3.3Vaux on PCI-Express? I seem to recall at least one mainboard it’s configurable for certain S-States.

Peter
OSR

> Also, NICs are getting VAUX in S3 state. Actually, every PCI device can use VAUX.

On some machines, PCI devices have VAUX even on switched-off machine with the OS being shut down, not only in S3.

Legacy keyboard/mouse controller is powered, too.

Looks like so. Laptop definitely can awaken from S3 (blinking power LED) by a key press on its embedded keyboard. With external USB keyboard, it also can, but from S2 - with such keyboard with wait/wake enabled, the laptop only goes to S2 on Sleep (power LED on).


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Actually, I had a (separate) bone to pick with all of those answers.

When your whole system moves to an S-state like S3, the power manager asks
all the devices to move to the appropriate D-state by sending an S-IRP
through the stack. The power policy manager in each stack looks at the
negotiated power capabilities struct and moves to the appropriate D-state.

In most cases, the appropriate D-state is as close to “off” as it can be.
So the choice is almost always D3(hot). Whether the device can be placed in
some higher-powered D-state during the system sleep depends on the bus
capabilities and the motherboard. In some cases, motherboards can provide
Vaux during S3, for instance, to allow devices to wake. The motherboard
BIOS reports this through ACPI and this is reflected in the power
capabilities struct.

If the motherboard supports Vaux in the requested S-state and if the device
is armed for wake and if the device requires Vaux to wake, then the power
policy owner may choose to put the device in, for instance, D2. This would
be a common thing when a USB device is armed for wake, since the architects
of the Windows USB stack decided that D2 meant “armed for wake” in USB.

If the device is armed for wake and Vaux is not available, then the power
policy owner can reject the requested S-state, hoping for a higher-powered
S-state that does supply Vaux, like S1.

Note that the definitions of S1, S2 and S3 are pretty loose. They can be
very different between motherboards. ACPI BIOSes describe the aspects of
each and this informs the behavior of the ACPI driver. It’s not true that
“only memory is preserved in S3,” though that may be a common implementation
on a laptop.

In general, S1 powers the processor (which will be halted) and memory any
Vaux. S2 is almost never implemented, but when it is, it’s S3 plus Vaux for
some key devices. S3 turns off the processor completely and leaves memory
intact, in self-refresh. Vaux in S3 may or may not be available. S4
removes power to memory, and the OS is responsible for preserving it by
writing it out to disk. In S4, Vaux may still be available, and commonly is
on wall-powered machines.

D3(hot) becomes D3(cold) if Vcc and Vaux are both lost. In general, if you
are writing a bus driver, you need to know that you map D3(hot) to D3 and
D3(cold) to “not present on the bus, as I can’t verify that I can enumerate
the device.”

Jake Oshins
Hyper-V I/O Architect (former power management and ACPI guy)
Windows Kernel Group

This post implies no warranties and confers no rights.


wrote in message news:xxxxx@ntdev…

Exactly as described by Pavel, Mr. Shatskih, and Mr. Roumenov.

One of the main jobs of the device’s power policy owner is to decide the
D-state the device will be in, given a particular S-state. This is entirely
up the the power policy owner. So, S3 = D3 is definitely not automatic
(though it is common).

Peter
OSR

Yes. See my other answer. Almost all of the answers on this thread have
had technical problems.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.


wrote in message news:xxxxx@ntdev…

But isn’t supplying VAUX (to the bus slot) technically optional?

Similarly… 3.3Vaux on PCI-Express? I seem to recall at least one
mainboard it’s configurable for certain S-States.

Peter
OSR

@Jake O:

Is there a separate S-state for hybrid sleep?

No. It’s a variant of S3, which it had to be for compatibility reasons.
Your driver will prepare for S3 and then, if power is removed from the
machine while it is asleep, your device will lose Vaux, if it was present.
This means that any attempt to wake the system will probably fail.

In any case, that’s usually okay from a user’s perspective. They put their
machine to sleep and it woke up, even though the power failed during the
night. The fact that they had to push the power button didn’t bother them.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.


wrote in message news:xxxxx@ntdev…

@Jake O:

Is there a separate S-state for hybrid sleep?

> if power is removed from the

machine while it is asleep, your device will lose Vaux, if it was present.

Are you saying laptop on DC will cut off VAUX in hybrid sleep mode?

Thanks,
Calvin

“Are you saying laptop on DC will cut off VAUX in hybrid sleep mode?”

Laptop on DC is not exactly the case of “if the power is removed”.

???

You meant S4 there, right?

For hybrid sleep, your device is told it’s doing a transition to S4, so that you do all the necessary preparations you would need to restore from disk if necessary. THEN the system only transitions to S3, and if necessary later directly to S4 without first going through S0.

You can tell the difference between an request for Hybrid Sleep from a “regular” attempt for S4 by looking at the SYSTEM_POWER_STATE_CONTEXT structure: For transitions to hybrid sleep, TargetSystemState is set to S3. For transitions to hybrid sleep, EffectiveSystemState is set to S4. For transitions to hibernate, both are set to S4.

Peter
OSR

I’m saying that the motherboard implementer gets to make that decision and
the information is reflected in the ACPI namespace.

With that said, we don’t enable hybrid sleep by default on machines with a
battery, so the question is somewhat moot. If you rephrased it for an
AC-powered machine, the answer would be yes. You can also force hybrid
sleep to be used, even when it’s redundant.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.


wrote in message news:xxxxx@ntdev…

if power is removed from the
machine while it is asleep, your device will lose Vaux, if it was present.

Are you saying laptop on DC will cut off VAUX in hybrid sleep mode?

Thanks,
Calvin

Yes, sorry. I did mean S4. (Actually, my memory said S3, since that’s the
way that we originally thought about implementing it. Now I’ve looked up
the final implementation.)

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.


wrote in message news:xxxxx@ntdev…

???

You meant S4 there, right?

For hybrid sleep, your device is told it’s doing a transition to S4, so that
you do all the necessary preparations you would need to restore from disk if
necessary. THEN the system only transitions to S3, and if necessary later
directly to S4 without first going through S0.

You can tell the difference between an request for Hybrid Sleep from a
“regular” attempt for S4 by looking at the SYSTEM_POWER_STATE_CONTEXT
structure: For transitions to hybrid sleep, TargetSystemState is set to S3.
For transitions to hybrid sleep, EffectiveSystemState is set to S4. For
transitions to hibernate, both are set to S4.

Peter
OSR