Power management

Dear, ALL!

I have a question concerning power management issues on Windows
platforms. As far as I understand there are two types of power IRPs,
one for setting system power state and another one for setting device
power state. Further investigation reveals that only device driver
itself can be the source of device-oriented power IRPs. It still need
to call PoRequestPowerIrp() function, but no one in system care about
this IRP, except the originator device driver. More of that, I redo my
driver for our USB device to do all power-management handling within
system power IRPs and everything was working fine, at least on XP
platform with different service pack options. So, there is the catch
here?


With best regards,
Vladimir S. Mirgorodsky

pavel_a
Wed Jun 01 11:49:17 CDT 2005

"v_mirgorodsky@yahoo.com" wrote:
> Dear, ALL!
>
> I have a question concerning power management issues on Windows
> platforms. As far as I understand there are two types of power IRPs,
> one for setting system power state and another one for setting device
> power state. Further investigation reveals that only device driver
> itself can be the source of device-oriented power IRPs. It still need
> to call PoRequestPowerIrp() function, but no one in system care about
> this IRP, except the originator device driver. More of that, I redo my
> driver for our USB device to do all power-management handling within
> system power IRPs and everything was working fine, at least on XP
> platform with different service pack options. So, there is the catch
> here?
>
>
> With best regards,
> Vladimir S. Mirgorodsky

Hi,

If only I understood you right, you're missing the whole idea
of power policy ownership.

Sometimes the function driver is also the power policy owner of it's device,
sometimes it isn't.

Regards,
--PA

v_mirgorodsky
Wed Jun 01 12:40:34 CDT 2005

Hi,

Thanks a lot for you attention and for your answer.

So, if on top of my driver would be another filter driver this approach
may cause problems to whole system, right? Since filter driver on top
of my driver may not allowing me to sleep my device, even if it is okay
from my point of view to do that.

But, as I understood from documentation, filter driver gets the system
IRP first, and, if it wants to deny sleep my device it may safely fail
it and my driver will not even see it. What is the problem with that?
Or system sends power IRPs to each driver separately? Why than should I
send them down the stack?

I got my idea about power management from Water Oney's book about WDM
drivers. I played a lot with his power handler and eventually rewrote
it for my USB camera driver to accommodate my specific issues and got
it working. During my debugging session I made a mistake in code,
effectively excluding path with device IRP processing. Everything was
working fine. All of this made me curious why anyone should bother with
device power IRPs? I corrected the mistyping in my sources and brought
whole cycle back to life, but I would like to figure out if there is a
good reason to keep another hundred of lines of C++ code in power
handler. Unfortunately, all other books I read on topic just states
that everything suppose to be this way, without going into any details.

With best regards,
Vladimir S. Mirgorodsky

Calvin
Wed Jun 01 13:39:26 CDT 2005

> But, as I understood from documentation, filter driver gets the system
> IRP first, and, if it wants to deny sleep my device it may safely fail
> it and my driver will not even see it. What is the problem with that?
> Or system sends power IRPs to each driver separately? Why than should I
> send them down the stack?


Filter driver sitting below your driver can act as power policy owner too.
System sends S-Irp to the stack top. It's the responsibility of EACH driver
in the stack to pass down the IRP so that everyone has a chance to play.
This makes perfect sense since no one wants to change the power state
without letting the bus driver know about it. The only exception is the
driver had passed an MN_REMOVE_DEV down, you don't send power irps down in
such case since there may be no lowers.

--
Calvin Guan Windows DDK MVP
Staff SW Engineer, NetXtreme MINIPORT
Enterprise Network Controller Engineering
Broadcom Corporation www.broadcom.com

Maxim
Thu Jun 02 01:51:45 CDT 2005

> Or system sends power IRPs to each driver separately?

To each devnode. You cannot fail the set power IRPs - neither the system nor
the device ones. Failing the system query IRP means - imposing a veto on the
whole system. You can complete the power IRP in the filter and not allow it
down the stack though.

> working fine. All of this made me curious why anyone should bother with
> device power IRPs?

Device power IRP triggers the exact hardware actions. System power IRP only
triggers the state transition in the Power Policy Owner, which can force it to
send the device power IRP.

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

v_mirgorodsky
Thu Jun 02 07:34:32 CDT 2005

Okay, let me explain it in greater details. My driver is "Imaging"
class, and my camera has an Ethernet connection to the computer. The
driver is loaded into system, creates the interface in its AddDevice()
routine and registers itself with NDIS. I am developing this driver
using NDISPROT driver sample, except I need to export certain interface
out of my driver to make use of all existing software. For now all
functionality to interact with NDIS is disabled for debugging purposes.

I described my driver HW-ID in inf file as *SMXA300, set its class as
being "Imaging" device and directed *ntkern to load it when
appropriate. Eventually I got my AddDevice() handler called with some
sort of device object. First of all, who's this device object? There
is no hardware yet bellow this driver... I have a DriverUnload()
handler registered, but it never get called. I tried to uninstall the
driver and always got positive response from driver manager. It never
tries to reboot my computer to update or uninstall this driver, so, it
is able to unload/deactivate it somehow, but I can not figure the way
it does that. Disabling and then enabling this driver triggers
DriverEntry()/AddDevice() function invocation, but never
DriverUnload(). I tried to add simple PNP handler, but OS does not
bother to call it either.

With my old USB driver I was able to update my driver binary by
disabling/enabling the device or by disconnecting/connecting hardware,
for this driver it does not work.

With best regards,
Vladimir S. Mirgorodsky

v_mirgorodsky
Thu Jun 02 08:42:25 CDT 2005

Thank a lot for your attention and for your comments. All of this is
making me better understand power management.

I have one more question. I have a USB device driver, as I said. It
normally participates in USB stack power management and everything is
fine with it. At the other hand I need to develop another driver to
grab images from existing driver and send them across DirectX system to
allow my camera to function as a streaming device. This way my driver
would not control any existing piece of hardware. In the same time
registering with kernel streaming requires providing power management
handler. What that handler should do? Does it need to silently agree on
any power transition? Should it exist at all? What if driver interacts
with several Windows systems? Should it participate in each sub-system
power management?

Max
Tue Jun 07 11:57:49 CDT 2005

If you choose to implement streaming driver (i.e. use the class driver, KS)
then you conviniently escape all those gory details of power management as
the class driver does it for you.
All you need to do is to take care of your device before it loses power
after it gets powered back up.
What some choose to do is to dump the state of the device upon power down to
restore it back after the device is powerd up and initialized properly.

-- Max.


<v_mirgorodsky@yahoo.com> wrote in message
news:1117719745.003476.300570@g49g2000cwa.googlegroups.com...
> Thank a lot for your attention and for your comments. All of this is
> making me better understand power management.
>
> I have one more question. I have a USB device driver, as I said. It
> normally participates in USB stack power management and everything is
> fine with it. At the other hand I need to develop another driver to
> grab images from existing driver and send them across DirectX system to
> allow my camera to function as a streaming device. This way my driver
> would not control any existing piece of hardware. In the same time
> registering with kernel streaming requires providing power management
> handler. What that handler should do? Does it need to silently agree on
> any power transition? Should it exist at all? What if driver interacts
> with several Windows systems? Should it participate in each sub-system
> power management?
>