>First, USB defines a wake mechanism that is contained within USB. So it’s
entirely possible that USB may power down a single
port in response to a keyboard stack sending IRP_MN_WAIT_WAKE. Since the
other ports are still active, the controller will remain active, not sending
an IRP to its
parent. (This is the ‘may’ case we were talking about before.) If the
user touches the keyboard, then the keyboard device will signal for wakeup
using the USB
mechanism, and the controller (root hub) driver will complete the keyboard
driver’s IRP.
Jake ACPI filter driver doesnot play any role in above mention case Right
since it is not waking up the whole system?
-----Original Message-----
From: Jake Oshins [mailto:xxxxx@windows.microsoft.com]
Sent: Sunday, July 14, 2002 11:44 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Path of IRP_MN_WAIT_WAKE
I’ll try to answer both Max and Bill in one message.
It was very much the intent of the WDM architects (and everyone, like
myself, who has come after them) to enable devices to be placed in low power
states while the machine is in the S0 state. While this may not seem very
meaningful for desktop and server machines, it’s critical in laptops.
I currently use two laptops in my everyday life. One is a huge sixteen-inch
screen and the kitchen sink variety that I use for my everyday coding and
development. The other is a low-power Tualatin processor based ultra-slim
that I use when traveling. (They are the IBM Thinkpad A21p and the IBM
Thinkpad s30 for those who are overly
interested.) The big one has (I think) a fourteen-cell battery pack and a
typical power budget somewhere upwards of 25W.
We took a machine that was identical to the little one once and evicerated a
battery pack for it, hooking up test leads. We found that, at idle, the
little one used between 1.0W and 1.5W. Remember that this is a machine
around four pounds with a 4 hour battery life. Intel tells us that the
processor is responsible for about .6W at idle. The rest of the power is
consumed mostly by the backlight, the ethernet PHY and the 1394 PHY. (It’s
a Japanese-market machine, which is why it has both built in.) Before we
added code to USB to put it into a low-power state at idle, the power budget
would have been around a watt higher. As you can see, in this type of
machine, 300mW can be an extra half-hour of battery time, which is very
significant.
Let’s take the ethernet as an example. It’s rarely in use when the machine
is running on batteries. So you’d really like to shut it down. But you’d
still want it to come back on line as soon as you plugged it into a hub.
This is accomplishable using the very IRP_MN_WAIT_WAKE mechanisms that are
in WDM. The NDIS stack sends IRP_MN_WAIT_WAKE to its PDO, which is PCI.sys.
PCI.sys then sends another to its parent, which in this case is ACPI.sys.
The NDIS driver then moves the NIC out of D0 and shuts down the PHY, which
is the power-hungry part. When the ethernet cable is plugged back in, it
triggers PME# and the series of IRPs is completed, causing the NDIS stack to
bring the NIC back into D0.
USB is a similar case, though it has a couple of interesting
particularities. First, USB defines a wake mechanism that is contained
within USB. So it’s entirely possible that USB may power down a single port
in response to a keyboard stack sending IRP_MN_WAIT_WAKE. Since the other
ports are still active, the controller will remain active, not sending an
IRP to its parent. (This is the ‘may’ case we were talking about before.)
If the user touches the keyboard, then the keyboard device will signal for
wakeup using the USB mechanism, and the controller (root hub) driver will
complete the keyboard driver’s IRP. Of course, if all ports have been
powered down, then the root hub will power itself down, which will require
an IRP to its parent to enable wakeup.
USB is also interesting because, when active, it requires periodic DMA
traffic. While this doesn’t require much power in the USB controller or the
memory controller, it forces the processor to stay in an active state, so
that the processor caches are kept coherent. This means that USB, or any
other device that you guys may be working with which uses a lot of DMA, can
cause a machine like my small laptop to add another watt, (sometimes 2 or 3
watts,) to its active power usage. That’s a huge reduction in battery life.
And, yes Max, the USB controller has got to be prepared to pend a separate
IRP_MN_WAIT_WAKE from each of its child devices. It only has to send one to
its parent in response, and only if the parent isn’t capable of handling the
children’s IRPs by itself. (To review, this would either be because it
can’t detect a wakeup signal from its child, probably because the child is
just triggering PME# directly. Or it could be because the parent itself has
been moved out of D0, meaning that it will trigger wakeup when its child
does, probably through PME#.)
If you want more information, I wrote a white paper a couple of years ago
that was intended to help motherboard manufacturers deal route wakeup
signals in ways that could actually work. It also covers some issues that
you’ve touched on. It’s at:
http://www.microsoft.com/hwdev/tech/onnow/GPE_routing.asp
Postscript: NDIS and other miniport stacks hide the details of WDM. So you
have to get them to do run-time power management in ways that may seem
strange. If you want or need details about a particular port model, I’ll
pass your questions along to the owners.
Hope this helps. Please ask more questions if it’s still not clear.
Jake Oshins
Windows Kernel Group
This posting is provided “AS IS” with no warranties, and confers no rights.
-----Original Message-----
Subject: Re: Path of IRP_MN_WAIT_WAKE
From: “Bill McKenzie”
Date: Sun, 14 Jul 2002 02:16:14 -0500
X-Message-Number: 3
> Sorry. I didn’t mean to imply that the bus driver could re-use the
IRP
> sent to it by the device’s FDO. The ‘may’ was only there because some
> wakeup scenarios can be handled without sending an IRP through the
> parent stacks.
This is completely unclear from the docs. From the DDK, it appears to me
that only the ACPI bus and ACPI filter drivers can handle a wake signal, in
that only those drivers can detect the wake signal, properly bring the
system into a working state, and signal other drivers to wake their devices
by completing the correct wake IRPs. Can you explain how wake works really?
Especially how a stack could skip sending the wake IRP to an ACPI agent?
> I’m guessing that I’ll get a lot of responses from people who think
that
> they should design with the system state in mind. Please send them.
> Let’s talk them out.
Well, while I agree that only the device power state is of any concern to
the driver of a particular device, it is the waking of the system that the
IRP_MN_WAIT_WAKE IRP is primarily there for yes? I can’t imagine that a NIC
is concerned with waking the NIC. The NIC is concerned with waking the
system due to appropriate network traffic. A device driver will never send
a system power state, but that doesn’t mean it isn’t concerned with the
state of the system, right?
Your suggesting that the wake mechanism be used to bring an individual
device back to life is interesting, but probably not very common. I can’t
imagine what type of device could handle this, and how much power it would
save if it could. Most devices that can power down when idle can and
probably should power all the way down and power back up when a handle is
open or some such. Like a COM port usage model. I imagine that most
devices could handle this model. Using some standby state that allowed wake
signalling would require more power, and seem unneccesary for most devices.
I would only design a device like this if it needed to wake the system. So,
what types of devices do this and why?
–
Bill McKenzie
“Jake Oshins” wrote in message
news:xxxxx@ntdev…
Sorry. I didn’t mean to imply that the bus driver could re-use the IRP sent
to it by the device’s FDO. The ‘may’ was only there because some wakeup
scenarios can be handled without sending an IRP through the parent stacks.
About the intention of IRP_MN_WAIT_WAKE, the DDK is (again) misleading.
You’ll end up designing yourself into a corner if you design with the system
state in mind. Drivers should only concern themselves with whether or not
their devices are in D0. If the hardware, via a wakeup signal, requests
that a device be moved into D0, then the system power manager (which is not
in your driver stacks) will guarantee that the system brought into S0.
The confusion is understandable, as many drivers never put take their
devices out of D0 unless the system leaves S0.
Also, the DDK was written before people really understood the ramifications
of wakeup. The people who were my immediate predecessors designed WDM. And
wakeup was the last and least-well-understood thing that they did. (You
might argue that a few of the dark corners of PnP were of the same standing,
but I think that wakeup was the worst case.) In their defense, plug and play
and power management hardware existed before WDM. But the concept of a
general mechanism to support waking a single device while the system is in
S0 didn’t exist beforehand. It took a while before this began to appear.
I then spent three years figure out how to make it work coherently, and I
strongly believe that you need to work only in terms of device power states
when you send IRP_MN_WAIT_WAKE.
I’m guessing that I’ll get a lot of responses from people who think that
they should design with the system state in mind. Please send them. Let’s
talk them out.
Jake Oshins
Windows Kernel Group
This posting is provided “AS IS” with no warranties, and confers no rights.
-----Original Message-----
Subject: Re: Path of IRP_MN_WAIT_WAKE
From: “Bill McKenzie”
Date: Sat, 13 Jul 2002 01:20:44 -0500
X-Message-Number: 2
It didn’t know that the bus driver ‘may’ create a new IRP for the parent
stack, I thought it was a ‘must’. Otherwise, cancelling this IRP could get
really screwy yes? As in a driver could potentially need to cancel an IRP
it didn’t create.
>Remember that WDM deals in the sleeping and waking of
>devices, not the entire machine. Waking the machine may be a side
>effect of bringing your device into D0. But the primary action of a
>wakeup signal is to request that a specific device enter the working
>state.
The documentation clearly makes it sound more than a side effect, at least
as I read it in the DDK. For instance in the docs for IRP_MN_WAIT_WAKE
under Input, what does this mean:
“Parameters.WaitWake.SystemWake contains the lowest (least-powered) system
power state from which the device should be allowed to awaken the system.”
Or how about this:
"Operation
A driver sends IRP_MN_WAIT_WAKE for either of two reasons:
1… To enable its device to awaken a sleeping system in response to an
external wake-up signal.
2… To enable its device to awaken from a device sleep state in response
to an external wake-up signal. " It appears waking the system was an intent
of this IRP, or at least one possible intent, no?
–
Bill McKenzie
“Jake Oshins” wrote in message
news:xxxxx@ntdev…
Actually, while ACPI does filter any device that is described in the ACPI
BIOS, the filters don’t have much to do with IRP_MN_WAIT_WAKE in most cases.
It’s also worth noting that the IRP_MN_WAIT_WAKE that you send from the
power policy manager (probably your FDO) always stops at the PDO. The bus
driver that owns the PDO may create a completely separate IRP_MN_WAIT_WAKE
which it sends down the parent stack to arm the bus for wakeup. That parent
may create yet another one to send down the grandparent’s stack. This
always continues until it reaches a driver that can arm the machine for
wakeup. This is the ACPI driver in all machines that we care about, though
architecturally, it could be something else.
Additionally, the sending of these IRPs and their completion may have
nothing to do with waking the entire machine. You may take your device out
of the D0 while the machine is still in S0, so that the machine uses less
electricity (which is particularly important while running on
batteries.) Remember that WDM deals in the sleeping and waking of devices,
not the entire machine. Waking the machine may be a side effect of bringing
your device into D0. But the primary action of a wakeup signal is to
request that a specific device enter the working state.
In this case, the ACPI driver’s only role is to notify the PCI driver that
the PME# signal has been triggered.
Jake Oshins
Windows Kernel Group
The one exception to this statement occurs when the ACPI BIOS describes
a machine wherein the wake signal for a specific device is directly wired to
the chipset power management logic, rather than the PCI-standard PME#.
This posting is provided “AS IS” with no warranties, and confers no rights.
-----Original Message-----
Subject: Re: Path of IRP_MN_WAIT_WAKE
From: “Bill McKenzie”
Date: Fri, 12 Jul 2002 17:42:09 -0500
X-Message-Number: 19
> Is there any scenario in which IRP_MN_WAIT_WAKE doesn’t need to
propogate
to
> ACPI driver.
Yes, ACPI has filter drivers that handle this as well. Actually for
something like a USB device the stack would be something like:
USB device driver ->USB hub driver->USB Controller driver->ACPI filter
driver
But, all IRP_MN_WAIT_WAKE IRPs will end at an ACPI driver at some point in
the stack. ACPI is responsible for wake signal detection and IRP completion
at the bottom. At least as I understand it.
–
Bill McKenzie
—
You are currently subscribed to ntdev as: xxxxx@itronix.com
To unsubscribe send a blank email to %%email.unsub%%
