kmdf - powering down a device

Guy_Corem-2 · June 22, 2007, 3:14am

Hi All,

I need to power down my device (D3) upon user request (through IOCTL),
immediately (not through IdleTimeout value in
WdfDeviceAssignS0IdleSettings).

How can I do it ?

Best regards,
Guy

Doron_Holan · June 22, 2007, 10:33am

Why call WdfDeviceAssignS0IdleSettings and set the idle timeout to 1 ms
so you get near instaneous power down? KMDF does not support power down
*right now*, it only supports powering down after a time out given that
you are idle.

d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Guy Corem
Sent: Friday, June 22, 2007 12:14 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] kmdf - powering down a device

Hi All,

I need to power down my device (D3) upon user request (through IOCTL),
immediately (not through IdleTimeout value in
WdfDeviceAssignS0IdleSettings).

How can I do it ?

Best regards,
Guy

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

Maxim_S_Shatskih · June 22, 2007, 10:38am

Can KMDF’s PPO implementation be ordered to initiate power down “just now”?

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

“Doron Holan” wrote in message news:xxxxx@ntdev…
Why call WdfDeviceAssignS0IdleSettings and set the idle timeout to 1 ms
so you get near instaneous power down? KMDF does not support power down
right now, it only supports powering down after a time out given that
you are idle.

d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Guy Corem
Sent: Friday, June 22, 2007 12:14 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] kmdf - powering down a device

Hi All,

I need to power down my device (D3) upon user request (through IOCTL),
immediately (not through IdleTimeout value in
WdfDeviceAssignS0IdleSettings).

How can I do it ?

Best regards,
Guy

—
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

Doron_Holan · June 22, 2007, 1:14pm

By “just now” do you mean “right now at this very instant”? If that is
what you mean, no KMDF does not support this model for idling out in S0
(it does support this for powering off due to an Sx transition though).
But like I said, you can get nearly now behavior by setting an extremely
short timeout when assign s0 idle settings. Why would you need “off
right now” for S0 idle?

If you don’t want to reassign the idle timeout all the time, you could
explicitly disable idle by calling WdfDeviceStopIdle and then calling
WdfDeviceResumeIdle. Usually you control this behavior by routing i/o
through power managed queues instead of explicitly managing the idle
state with these DDIs.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Friday, June 22, 2007 7:38 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmdf - powering down a device

Can KMDF’s PPO implementation be ordered to initiate power down
“just now”?

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

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Why call WdfDeviceAssignS0IdleSettings and set the idle timeout to 1 ms
so you get near instaneous power down? KMDF does not support power down
right now, it only supports powering down after a time out given that
you are idle.

d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Guy Corem
Sent: Friday, June 22, 2007 12:14 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] kmdf - powering down a device

Hi All,

I need to power down my device (D3) upon user request (through IOCTL),
immediately (not through IdleTimeout value in
WdfDeviceAssignS0IdleSettings).

How can I do it ?

Best regards,
Guy

—
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

Guy_Corem-2 · June 22, 2007, 6:05pm

Hi Doron,

First, A little bit about my driver.

I’ve implemented a user space I/O driver: A kernel driver that maps a
PCI card memory mapped ranges to a user mode client virtual address, and
notify about interrupts and D0Entries / Exits via pending IOCTLs (which
the driver store in non power managed, manual dispatch queue).

The driver is providing the following IOCTL interface: Get memory mapped
ranges, query device property, indicate status (for pending
notifications), power down and power up.

Using power managed main queue will defeat my purposes. Consider the
following scenario:

The application is sending an indicate status IOCTL, which the driver
keeps (pend) in the secondary manual dispatch queue. The application is
sending this IOCTL asynchronously (using overlapped structure) or from a
dedicated notification thread.
Later, the application is sending power down IOCTL. The driver will
transition to D3 using (indeed) 1 timeout value in the call to
WdfDeviceAssignS0IdleSettings.
The device D3Exit event will be called.
The D3Exit event will complete the pending notification IOCTL.
The application will send another notification IOCTL, and since the
default queue is power managed, the device will transition back to D0…

After a lot of trials, I’ve settled on the following implementation:
(If you’ll suggest a better one, I’ll be happy to switch…)

I’m using a non power managed default queue.
Powering Up is setting MAXULONG as the timeout value
(WdfDeviceAssignS0IdleSettings ). This is *UGLY* since after ~49.7 days,
the device will power down automatically…
Powering Down is setting 1 as the timeout value
I don’t know why (bug?), but when resuming from hibernation, if the
device was in D0 before the hibernation and the default queue is not
power managed, the framework DOESN’T switch the device back to D0.
I’ve overcome this problem by post-process the IRP_MN_SET_POWER
transition to S0, and “powering up” the device back manually, as
described in 2.

During my trials, I’ve encountered also the following strange behavior:
Despite a call to WdfDevieStopIdle (from DeviceAdd, after setting the
idle timeout value), the framework, nevertheless, transition the device
to D3 when the timeout expire…

I’m testing on Vista64.

I’m compiling against KMDF 1.7 headers (WDK 6001), but linking against
KMDF 1.5 libraries (WDK 6000)

[My sources file contain the following lines:
KMDF_VERSION_MINOR=5
KMDF_LIB_PATH=KMDF1.5 libs path*]

Sorry for my long email, and thanks,
Guy

Doron Holan wrote:

By “just now” do you mean “right now at this very instant”? If that is
what you mean, no KMDF does not support this model for idling out in S0
(it does support this for powering off due to an Sx transition though).
But like I said, you can get nearly now behavior by setting an extremely
short timeout when assign s0 idle settings. Why would you need “off
right now” for S0 idle?

If you don’t want to reassign the idle timeout all the time, you could
explicitly disable idle by calling WdfDeviceStopIdle and then calling
WdfDeviceResumeIdle. Usually you control this behavior by routing i/o
through power managed queues instead of explicitly managing the idle
state with these DDIs.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Friday, June 22, 2007 7:38 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmdf - powering down a device

Can KMDF’s PPO implementation be ordered to initiate power down
“just now”?

Doron_Holan · June 22, 2007, 6:36pm

WdfDeviceStop/ResumeIdle are what you want to use in your current
design. They are the manual way for you to change the idle state of the
device.

Assigning the idle settting and then immediately calling
WdfDeviceStopIdle in AddDevice fails b/c the power idle state machine is
not started, that would be a bug in KMDF that we don’t respect that call
so early in device creation. To work around this issue, call
WdfDeviceStopIdle in EvtDeviceSelfManagedIoInit. By doing this in
SelfManagedInit, you can set the idle timeout to 1 ms during AddDevice
and never change the timeout value itself.

The power down will still be asynchronous. This is fine as long you
either handle STATUS_PENDING returned from WdfDeviceResumeIdle (if you
pass FALSE) or always call WdfDeviceResumeIdle with TRUE so it will
block until you return D0. Note that you will have to synchronize your
manually managed power state with an Sx power down. Remember, for an Sx
power down, the device’s idle settings do not have any effect, the
device is going to be powered down *now*. In a normal driver, the power
managed queue waits for /acknowledges in flight requests to complete
before powering down, you will have to manually stop processing requests
from your manual queue in EvtDeviceSelfManagedIoSuspend (probably by
stopping the queue, but I am not sure about that).

The device remaining in Dx after resuming from Sx is by design if there
are no outstanding power references on the device (why put the device
back into a powered up state if nothing in the driver requires it have
power?). A request in a power managed is a reference, as is a call to
WdfDeviceStopIdle. As long as you have called WdfDeviceStopIdle without
a matching WdfDeviceResumeIdle, your device will be powered on upon
returning to S0.

So that in a nutshell is how to do this in your current design. I think
though that you can leverage power managed queues more then you are
today. Instead of having one non power managed manual queue for all of
your IOCTLs, create a parallel non power managed queue as the top level
dispatching queue for your IOCTLs. You then have different sub queues
which could be power managed or not. I would think you would have one
power managed manual queue and one non power managed manual queue. You
then route the IOCTL requests from the top level parallel queue into the
appropriate subqueue. For instance, the power own IOCTL is put into the
power managed queue, as are the notifications for interrupts. The power
down ioctl would be placed in the non power managed queue. You can
divvy it up as much as you like as you see fit…

d

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 3:05 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Hi Doron,

First, A little bit about my driver.

I’ve implemented a user space I/O driver: A kernel driver that maps a
PCI card memory mapped ranges to a user mode client virtual address, and
notify about interrupts and D0Entries / Exits via pending IOCTLs (which
the driver store in non power managed, manual dispatch queue).

The driver is providing the following IOCTL interface: Get memory mapped
ranges, query device property, indicate status (for pending
notifications), power down and power up.

Using power managed main queue will defeat my purposes. Consider the
following scenario:

The application is sending an indicate status IOCTL, which the driver
keeps (pend) in the secondary manual dispatch queue. The application is
sending this IOCTL asynchronously (using overlapped structure) or from a
dedicated notification thread.
Later, the application is sending power down IOCTL. The driver will
transition to D3 using (indeed) 1 timeout value in the call to
WdfDeviceAssignS0IdleSettings.
The device D3Exit event will be called.
The D3Exit event will complete the pending notification IOCTL.
The application will send another notification IOCTL, and since the
default queue is power managed, the device will transition back to D0…

After a lot of trials, I’ve settled on the following implementation:
(If you’ll suggest a better one, I’ll be happy to switch…)

I’m using a non power managed default queue.
Powering Up is setting MAXULONG as the timeout value
(WdfDeviceAssignS0IdleSettings ). This is *UGLY* since after ~49.7 days,
the device will power down automatically…
Powering Down is setting 1 as the timeout value
I don’t know why (bug?), but when resuming from hibernation, if the
device was in D0 before the hibernation and the default queue is not
power managed, the framework DOESN’T switch the device back to D0.
I’ve overcome this problem by post-process the IRP_MN_SET_POWER
transition to S0, and “powering up” the device back manually, as
described in 2.

During my trials, I’ve encountered also the following strange behavior:
Despite a call to WdfDevieStopIdle (from DeviceAdd, after setting the
idle timeout value), the framework, nevertheless, transition the device
to D3 when the timeout expire…

I’m testing on Vista64.

I’m compiling against KMDF 1.7 headers (WDK 6001), but linking against
KMDF 1.5 libraries (WDK 6000)

[My sources file contain the following lines:
KMDF_VERSION_MINOR=5
KMDF_LIB_PATH=KMDF1.5 libs path*]

Sorry for my long email, and thanks,
Guy

Doron Holan wrote:

By “just now” do you mean “right now at this very instant”? If that
is
what you mean, no KMDF does not support this model for idling out in
S0
(it does support this for powering off due to an Sx transition
though).
But like I said, you can get nearly now behavior by setting an
extremely
short timeout when assign s0 idle settings. Why would you need “off
right now” for S0 idle?

If you don’t want to reassign the idle timeout all the time, you could
explicitly disable idle by calling WdfDeviceStopIdle and then calling
WdfDeviceResumeIdle. Usually you control this behavior by routing i/o
through power managed queues instead of explicitly managing the idle
state with these DDIs.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Friday, June 22, 2007 7:38 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmdf - powering down a device

Can KMDF’s PPO implementation be ordered to initiate power down
“just now”?

OSR_Community_User · June 22, 2007, 6:47pm

Goy Corem wrote:

I’ve implemented a user space I/O driver: A kernel driver that maps a
PCI card memory mapped ranges to a user mode client virtual address

I’m new to driver writing, but isn’t this a big mistake right here? User-mode addresses are never guaranteed to remain in memory, even if they’re “locked”. Or maybe this would work if he uses the AWE APIs?

-Steve

Tim_Roberts · June 22, 2007, 7:26pm

xxxxx@hotmail.com wrote:

Goy Corem wrote:

> I’ve implemented a user space I/O driver: A kernel driver that maps a
> PCI card memory mapped ranges to a user mode client virtual address
>

I’m new to driver writing, but isn’t this a big mistake right here? User-mode addresses are never guaranteed to remain in memory, even if they’re “locked”.

No. Well, I guess it depends on exactly what you mean. Locked pages
always remain “in memory”, in the sense that they always stay at the
same location in physical memory. When the system switches to another
process, the user-mode virtual address doesn’t mean anything any more,
but when the process comes back, those locked pages will still be
there. They will not be swapped out. As long as the kernel driver
doesn’t try to use the user-mode virtual address to access the pages,
everything is fine. This is how DirectDraw surfaces get mapped in to
user-mode applications.

Of course, since these were PCI pages to begin with, they can’t be
“swapped out” anyway. We’re talking about page table manipulations only.

Now, there are plenty of reasons why it can be a bad idea to map PCI
address spaces into user mode, but address safety isn’t one of them.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Guy_Corem-2 · June 22, 2007, 8:20pm

Doron,

Thanks(!) for clarifying the issue around WdfDeviceStopIdle and
EvtDeviceAdd.

I’ve recoded according to your advice (using
EvtDeviceSelfManagedIoInit), and it worked like charm.

I’ve enjoyed very much to delete the IRP_MN_SET_POWER post-processing
code…

Just lost a day around this issue. I should have emailed as soon as I
observed the strange WdfDeviceStopIdle behavior.

Regarding “device remaining in Dx after resuming from Sx is by design”:

Just for completion, I suspect another bug. During my trials, I’ve
encountered the following (just verify it again now):

Using power managed default queue. No request in it.
Using secondary non power managed queue. One request pending in it.
WdfDeviceStopIdle wasn’t call at all
WdfDeviceAssignS0IdleSettings wasn’t call at all.

If I understood your reply, there is no outstanding power references.

Nevertheless, upon transition back to S0, the framework calls
/EvtDeviceD0Entry/

Starting from this “baseline”, I’ve started to modify:

Switching to non-power managed default queue. The framework *does*
call /EvtDeviceD0Entry/ upon transition back to S0
Adding a call to WdfDeviceAssignS0IdleSettings with MAXULONG timeout,
non-power managed default queue. The framework *doesn’t* call
/EvtDeviceD0Entry/ upon transition back to S0
Switching back to power managed default queue, calling
WdfDeviceAssignS0IdleSettings with MAXULONG timeout. The framework
*does* call /EvtDeviceD0Entry/ upon transition back to S0

In all the above cases, there was no pending requests in the default
queue, and one pending request in the secondary non power managed queue.

If it’s “by design”, I really don’t understand the logic behind it.

Thanks again,

Guy

Doron Holan wrote:

WdfDeviceStop/ResumeIdle are what you want to use in your current
design. They are the manual way for you to change the idle state of the
device.

Assigning the idle settting and then immediately calling
WdfDeviceStopIdle in AddDevice fails b/c the power idle state machine is
not started, that would be a bug in KMDF that we don’t respect that call
so early in device creation. To work around this issue, call
WdfDeviceStopIdle in EvtDeviceSelfManagedIoInit. By doing this in
SelfManagedInit, you can set the idle timeout to 1 ms during AddDevice
and never change the timeout value itself.

The power down will still be asynchronous. This is fine as long you
either handle STATUS_PENDING returned from WdfDeviceResumeIdle (if you
pass FALSE) or always call WdfDeviceResumeIdle with TRUE so it will
block until you return D0. Note that you will have to synchronize your
manually managed power state with an Sx power down. Remember, for an Sx
power down, the device’s idle settings do not have any effect, the
device is going to be powered down *now*. In a normal driver, the power
managed queue waits for /acknowledges in flight requests to complete
before powering down, you will have to manually stop processing requests
from your manual queue in EvtDeviceSelfManagedIoSuspend (probably by
stopping the queue, but I am not sure about that).

The device remaining in Dx after resuming from Sx is by design if there
are no outstanding power references on the device (why put the device
back into a powered up state if nothing in the driver requires it have
power?). A request in a power managed is a reference, as is a call to
WdfDeviceStopIdle. As long as you have called WdfDeviceStopIdle without
a matching WdfDeviceResumeIdle, your device will be powered on upon
returning to S0.

So that in a nutshell is how to do this in your current design. I think
though that you can leverage power managed queues more then you are
today. Instead of having one non power managed manual queue for all of
your IOCTLs, create a parallel non power managed queue as the top level
dispatching queue for your IOCTLs. You then have different sub queues
which could be power managed or not. I would think you would have one
power managed manual queue and one non power managed manual queue. You
then route the IOCTL requests from the top level parallel queue into the
appropriate subqueue. For instance, the power own IOCTL is put into the
power managed queue, as are the notifications for interrupts. The power
down ioctl would be placed in the non power managed queue. You can
divvy it up as much as you like as you see fit…

d

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 3:05 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Hi Doron,

First, A little bit about my driver.

I’ve implemented a user space I/O driver: A kernel driver that maps a
PCI card memory mapped ranges to a user mode client virtual address, and
notify about interrupts and D0Entries / Exits via pending IOCTLs (which
the driver store in non power managed, manual dispatch queue).

The driver is providing the following IOCTL interface: Get memory mapped
ranges, query device property, indicate status (for pending
notifications), power down and power up.

Using power managed main queue will defeat my purposes. Consider the
following scenario:

The application is sending an indicate status IOCTL, which the driver
keeps (pend) in the secondary manual dispatch queue. The application is
sending this IOCTL asynchronously (using overlapped structure) or from a
dedicated notification thread.

Later, the application is sending power down IOCTL. The driver will
transition to D3 using (indeed) 1 timeout value in the call to
WdfDeviceAssignS0IdleSettings.

The device D3Exit event will be called.

The D3Exit event will complete the pending notification IOCTL.

The application will send another notification IOCTL, and since the
default queue is power managed, the device will transition back to D0…

After a lot of trials, I’ve settled on the following implementation:
(If you’ll suggest a better one, I’ll be happy to switch…)

I’m using a non power managed default queue.

Powering Up is setting MAXULONG as the timeout value
(WdfDeviceAssignS0IdleSettings ). This is *UGLY* since after ~49.7 days,
the device will power down automatically…

Powering Down is setting 1 as the timeout value

I don’t know why (bug?), but when resuming from hibernation, if the
device was in D0 before the hibernation and the default queue is not
power managed, the framework DOESN’T switch the device back to D0.
I’ve overcome this problem by post-process the IRP_MN_SET_POWER
transition to S0, and “powering up” the device back manually, as
described in 2.

During my trials, I’ve encountered also the following strange behavior:
Despite a call to WdfDevieStopIdle (from DeviceAdd, after setting the
idle timeout value), the framework, nevertheless, transition the device
to D3 when the timeout expire…

I’m testing on Vista64.

I’m compiling against KMDF 1.7 headers (WDK 6001), but linking against
KMDF 1.5 libraries (WDK 6000)

[My sources file contain the following lines:
KMDF_VERSION_MINOR=5
KMDF_LIB_PATH=KMDF1.5 libs path*]

Sorry for my long email, and thanks,
Guy

Doron Holan wrote:

> By “just now” do you mean “right now at this very instant”? If that
>
is

> what you mean, no KMDF does not support this model for idling out in
>
S0

> (it does support this for powering off due to an Sx transition
>
though).

> But like I said, you can get nearly now behavior by setting an
>
extremely

> short timeout when assign s0 idle settings. Why would you need “off
> right now” for S0 idle?
>
> If you don’t want to reassign the idle timeout all the time, you could
> explicitly disable idle by calling WdfDeviceStopIdle and then calling
> WdfDeviceResumeIdle. Usually you control this behavior by routing i/o
> through power managed queues instead of explicitly managing the idle
> state with these DDIs.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> Shatskih
> Sent: Friday, June 22, 2007 7:38 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] kmdf - powering down a device
>
>
> Can KMDF’s PPO implementation be ordered to initiate power down
> “just now”?
>
>

Guy_Corem-2 · June 22, 2007, 8:30pm

Tim Roberts wrote:

xxxxx@hotmail.com wrote:
> Goy Corem wrote:
>
>> I’ve implemented a user space I/O driver: A kernel driver that maps a
>> PCI card memory mapped ranges to a user mode client virtual address
>>
> I’m new to driver writing, but isn’t this a big mistake right here? User-mode addresses are never guaranteed to remain in memory, even if they’re “locked”.

No. Well, I guess it depends on exactly what you mean. Locked pages
always remain “in memory”, in the sense that they always stay at the
same location in physical memory. When the system switches to another
process, the user-mode virtual address doesn’t mean anything any more,
but when the process comes back, those locked pages will still be
there. They will not be swapped out. As long as the kernel driver
doesn’t try to use the user-mode virtual address to access the pages,
everything is fine. This is how DirectDraw surfaces get mapped in to
user-mode applications.

Of course, since these were PCI pages to begin with, they can’t be
“swapped out” anyway. We’re talking about page table manipulations only.

Now, there are plenty of reasons why it can be a bad idea to map PCI
address spaces into user mode, but address safety isn’t one of them.
There are also plenty of reasons why it’s a good idea, sometimes…

Doron_Holan · June 22, 2007, 8:33pm

Let’s see if I can condense this to one answer for all cases.

The only time you will remain in Dx after an Sx->S0 transition is if you
were idled out and in Dx when you were in S0 before the Sx occurred.
This means that if you never assign S0 idle settings, you will always be
in D0 upon Sx->S0 b/c you never told the framework the device could be
in Dx while in S0. This also means that when you set a tremendously
long timeout, the device is still in D0 when we go to Sx, so we put it
back into D0 when we come back b/c obviously the timer has not yet
expired.

Make a little more sense now?

D

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 5:20 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Doron,

Thanks(!) for clarifying the issue around WdfDeviceStopIdle and
EvtDeviceAdd.

I’ve recoded according to your advice (using
EvtDeviceSelfManagedIoInit), and it worked like charm.

I’ve enjoyed very much to delete the IRP_MN_SET_POWER post-processing
code…

Just lost a day around this issue. I should have emailed as soon as I
observed the strange WdfDeviceStopIdle behavior.

Regarding “device remaining in Dx after resuming from Sx is by design”:

Just for completion, I suspect another bug. During my trials, I’ve
encountered the following (just verify it again now):

Using power managed default queue. No request in it.
Using secondary non power managed queue. One request pending in it.
WdfDeviceStopIdle wasn’t call at all
WdfDeviceAssignS0IdleSettings wasn’t call at all.

If I understood your reply, there is no outstanding power references.

Nevertheless, upon transition back to S0, the framework calls
/EvtDeviceD0Entry/

Starting from this “baseline”, I’ve started to modify:

Switching to non-power managed default queue. The framework *does*
call /EvtDeviceD0Entry/ upon transition back to S0
Adding a call to WdfDeviceAssignS0IdleSettings with MAXULONG timeout,
non-power managed default queue. The framework *doesn’t* call
/EvtDeviceD0Entry/ upon transition back to S0
Switching back to power managed default queue, calling
WdfDeviceAssignS0IdleSettings with MAXULONG timeout. The framework
*does* call /EvtDeviceD0Entry/ upon transition back to S0

In all the above cases, there was no pending requests in the default
queue, and one pending request in the secondary non power managed queue.

If it’s “by design”, I really don’t understand the logic behind it.

Thanks again,

Guy

Doron Holan wrote:

WdfDeviceStop/ResumeIdle are what you want to use in your current
design. They are the manual way for you to change the idle state of
the
device.

Assigning the idle settting and then immediately calling
WdfDeviceStopIdle in AddDevice fails b/c the power idle state machine
is
not started, that would be a bug in KMDF that we don’t respect that
call
so early in device creation. To work around this issue, call
WdfDeviceStopIdle in EvtDeviceSelfManagedIoInit. By doing this in
SelfManagedInit, you can set the idle timeout to 1 ms during AddDevice
and never change the timeout value itself.

The power down will still be asynchronous. This is fine as long you
either handle STATUS_PENDING returned from WdfDeviceResumeIdle (if you
pass FALSE) or always call WdfDeviceResumeIdle with TRUE so it will
block until you return D0. Note that you will have to synchronize
your
manually managed power state with an Sx power down. Remember, for an
Sx
power down, the device’s idle settings do not have any effect, the
device is going to be powered down *now*. In a normal driver, the
power
managed queue waits for /acknowledges in flight requests to complete
before powering down, you will have to manually stop processing
requests
from your manual queue in EvtDeviceSelfManagedIoSuspend (probably by
stopping the queue, but I am not sure about that).

The device remaining in Dx after resuming from Sx is by design if
there
are no outstanding power references on the device (why put the device
back into a powered up state if nothing in the driver requires it have
power?). A request in a power managed is a reference, as is a call to
WdfDeviceStopIdle. As long as you have called WdfDeviceStopIdle
without
a matching WdfDeviceResumeIdle, your device will be powered on upon
returning to S0.

So that in a nutshell is how to do this in your current design. I
think
though that you can leverage power managed queues more then you are
today. Instead of having one non power managed manual queue for all
of
your IOCTLs, create a parallel non power managed queue as the top
level
dispatching queue for your IOCTLs. You then have different sub queues
which could be power managed or not. I would think you would have one
power managed manual queue and one non power managed manual queue.
You
then route the IOCTL requests from the top level parallel queue into
the
appropriate subqueue. For instance, the power own IOCTL is put into
the
power managed queue, as are the notifications for interrupts. The
power
down ioctl would be placed in the non power managed queue. You can
divvy it up as much as you like as you see fit…

d

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 3:05 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Hi Doron,

First, A little bit about my driver.

I’ve implemented a user space I/O driver: A kernel driver that maps a
PCI card memory mapped ranges to a user mode client virtual address,
and
notify about interrupts and D0Entries / Exits via pending IOCTLs
(which
the driver store in non power managed, manual dispatch queue).

The driver is providing the following IOCTL interface: Get memory
mapped
ranges, query device property, indicate status (for pending
notifications), power down and power up.

Using power managed main queue will defeat my purposes. Consider the
following scenario:

The application is sending an indicate status IOCTL, which the
driver
keeps (pend) in the secondary manual dispatch queue. The application
is
sending this IOCTL asynchronously (using overlapped structure) or from
a
dedicated notification thread.

Later, the application is sending power down IOCTL. The driver will
transition to D3 using (indeed) 1 timeout value in the call to
WdfDeviceAssignS0IdleSettings.

The device D3Exit event will be called.

The D3Exit event will complete the pending notification IOCTL.

The application will send another notification IOCTL, and since the
default queue is power managed, the device will transition back to
D0…

After a lot of trials, I’ve settled on the following implementation:
(If you’ll suggest a better one, I’ll be happy to switch…)

I’m using a non power managed default queue.

Powering Up is setting MAXULONG as the timeout value
(WdfDeviceAssignS0IdleSettings ). This is *UGLY* since after ~49.7
days,
the device will power down automatically…

Powering Down is setting 1 as the timeout value

I don’t know why (bug?), but when resuming from hibernation, if the
device was in D0 before the hibernation and the default queue is not
power managed, the framework DOESN’T switch the device back to D0.
I’ve overcome this problem by post-process the IRP_MN_SET_POWER
transition to S0, and “powering up” the device back manually, as
described in 2.

During my trials, I’ve encountered also the following strange
behavior:
Despite a call to WdfDevieStopIdle (from DeviceAdd, after setting the
idle timeout value), the framework, nevertheless, transition the
device
to D3 when the timeout expire…

I’m testing on Vista64.

I’m compiling against KMDF 1.7 headers (WDK 6001), but linking against
KMDF 1.5 libraries (WDK 6000)

[My sources file contain the following lines:
KMDF_VERSION_MINOR=5
KMDF_LIB_PATH=KMDF1.5 libs path*]

Sorry for my long email, and thanks,
Guy

Doron Holan wrote:

> By “just now” do you mean “right now at this very instant”? If that
>
is

> what you mean, no KMDF does not support this model for idling out in
>
S0

> (it does support this for powering off due to an Sx transition
>
though).

> But like I said, you can get nearly now behavior by setting an
>
extremely

> short timeout when assign s0 idle settings. Why would you need “off
> right now” for S0 idle?
>
> If you don’t want to reassign the idle timeout all the time, you
could
> explicitly disable idle by calling WdfDeviceStopIdle and then calling
> WdfDeviceResumeIdle. Usually you control this behavior by routing
i/o
> through power managed queues instead of explicitly managing the idle
> state with these DDIs.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> Shatskih
> Sent: Friday, June 22, 2007 7:38 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] kmdf - powering down a device
>
>
> Can KMDF’s PPO implementation be ordered to initiate power down
> “just now”?
>
>

Guy_Corem-2 · June 22, 2007, 8:39pm

No.

In all cases the device
was in D0 before the Sx->S0 transition.

In all cases, I observe
a call to D0Exit during the sleep transition.

Only in case 2, I don’t
observe a call to D0Entry upon S0->Sx back transition.

Guy

Doron Holan wrote:

cite="mid:xxxxx@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com"
type=“cite”>

Let’s see if I can condense this to one answer for all cases.

The only time you will remain in Dx after an Sx->S0 transition is if you
were idled out and in Dx when you were in S0 before the Sx occurred.
This means that if you never assign S0 idle settings, you will always be
in D0 upon Sx->S0 b/c you never told the framework the device could be
in Dx while in S0. This also means that when you set a tremendously
long timeout, the device is still in D0 when we go to Sx, so we put it
back into D0 when we come back b/c obviously the timer has not yet
expired.

Make a little more sense now?

D

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 5:20 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Doron,

Thanks(!) for clarifying the issue around WdfDeviceStopIdle and
EvtDeviceAdd.

I’ve recoded according to your advice (using
EvtDeviceSelfManagedIoInit), and it worked like charm.

I’ve enjoyed very much to delete the IRP_MN_SET_POWER post-processing
code…

Just lost a day around this issue. I should have emailed as soon as I
observed the strange WdfDeviceStopIdle behavior.

Regarding “device remaining in Dx after resuming from Sx is by design”:

Just for completion, I suspect another bug. During my trials, I’ve
encountered the following (just verify it again now):

Using power managed default queue. No request in it.

Using secondary non power managed queue. One request pending in it.

WdfDeviceStopIdle wasn’t call at all

WdfDeviceAssignS0IdleSettings wasn’t call at all.

If I understood your reply, there is no outstanding power references.

Nevertheless, upon transition back to S0, the framework calls
/EvtDeviceD0Entry/

Starting from this “baseline”, I’ve started to modify:

Switching to non-power managed default queue. The framework does
call /EvtDeviceD0Entry/ upon transition back to S0

Adding a call to WdfDeviceAssignS0IdleSettings with MAXULONG timeout,
non-power managed default queue. The framework doesn’t call
/EvtDeviceD0Entry/ upon transition back to S0

Switching back to power managed default queue, calling
WdfDeviceAssignS0IdleSettings with MAXULONG timeout. The framework
does call /EvtDeviceD0Entry/ upon transition back to S0

In all the above cases, there was no pending requests in the default
queue, and one pending request in the secondary non power managed queue.

If it’s “by design”, I really don’t understand the logic behind it.

Thanks again,

Guy

Doron Holan wrote:

WdfDeviceStop/ResumeIdle are what you want to use in your current
design. They are the manual way for you to change the idle state of

the

device.

Assigning the idle settting and then immediately calling
WdfDeviceStopIdle in AddDevice fails b/c the power idle state machine

is

not started, that would be a bug in KMDF that we don’t respect that

call

so early in device creation. To work around this issue, call
WdfDeviceStopIdle in EvtDeviceSelfManagedIoInit. By doing this in
SelfManagedInit, you can set the idle timeout to 1 ms during AddDevice
and never change the timeout value itself.

The power down will still be asynchronous. This is fine as long you
either handle STATUS_PENDING returned from WdfDeviceResumeIdle (if you
pass FALSE) or always call WdfDeviceResumeIdle with TRUE so it will
block until you return D0. Note that you will have to synchronize

your

manually managed power state with an Sx power down. Remember, for an

Sx

power down, the device’s idle settings do not have any effect, the
device is going to be powered down now. In a normal driver, the

power

managed queue waits for /acknowledges in flight requests to complete
before powering down, you will have to manually stop processing

requests

from your manual queue in EvtDeviceSelfManagedIoSuspend (probably by
stopping the queue, but I am not sure about that).

The device remaining in Dx after resuming from Sx is by design if

there

are no outstanding power references on the device (why put the device
back into a powered up state if nothing in the driver requires it have
power?). A request in a power managed is a reference, as is a call to
WdfDeviceStopIdle. As long as you have called WdfDeviceStopIdle

without

a matching WdfDeviceResumeIdle, your device will be powered on upon
returning to S0.

So that in a nutshell is how to do this in your current design. I

think

though that you can leverage power managed queues more then you are
today. Instead of having one non power managed manual queue for all

of

your IOCTLs, create a parallel non power managed queue as the top

level

dispatching queue for your IOCTLs. You then have different sub queues
which could be power managed or not. I would think you would have one
power managed manual queue and one non power managed manual queue.

You

then route the IOCTL requests from the top level parallel queue into

the

appropriate subqueue. For instance, the power own IOCTL is put into

the

power managed queue, as are the notifications for interrupts. The

power

down ioctl would be placed in the non power managed queue. You can
divvy it up as much as you like as you see fit…

d

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 3:05 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Hi Doron,

First, A little bit about my driver.

I’ve implemented a user space I/O driver: A kernel driver that maps a
PCI card memory mapped ranges to a user mode client virtual address,

and

notify about interrupts and D0Entries / Exits via pending IOCTLs

(which

the driver store in non power managed, manual dispatch queue).

The driver is providing the following IOCTL interface: Get memory

mapped

ranges, query device property, indicate status (for pending
notifications), power down and power up.

Using power managed main queue will defeat my purposes. Consider the
following scenario:

The application is sending an indicate status IOCTL, which the

driver

keeps (pend) in the secondary manual dispatch queue. The application

is

sending this IOCTL asynchronously (using overlapped structure) or from

a

dedicated notification thread.

Later, the application is sending power down IOCTL. The driver will
transition to D3 using (indeed) 1 timeout value in the call to
WdfDeviceAssignS0IdleSettings.

The device D3Exit event will be called.

The D3Exit event will complete the pending notification IOCTL.

The application will send another notification IOCTL, and since the
default queue is power managed, the device will transition back to

D0...

After a lot of trials, I’ve settled on the following implementation:
(If you’ll suggest a better one, I’ll be happy to switch…)

I’m using a non power managed default queue.

Powering Up is setting MAXULONG as the timeout value
(WdfDeviceAssignS0IdleSettings ). This is UGLY since after ~49.7

days,

the device will power down automatically…

Powering Down is setting 1 as the timeout value

I don’t know why (bug?), but when resuming from hibernation, if the
device was in D0 before the hibernation and the default queue is not
power managed, the framework DOESN’T switch the device back to D0.
I’ve overcome this problem by post-process the IRP_MN_SET_POWER
transition to S0, and “powering up” the device back manually, as
described in 2.

During my trials, I’ve encountered also the following strange

behavior:

Despite a call to WdfDevieStopIdle (from DeviceAdd, after setting the
idle timeout value), the framework, nevertheless, transition the

device

to D3 when the timeout expire…

I’m testing on Vista64.

I’m compiling against KMDF 1.7 headers (WDK 6001), but linking against
KMDF 1.5 libraries (WDK 6000)

[My sources file contain the following lines:
KMDF_VERSION_MINOR=5
KMDF_LIB_PATH=KMDF1.5 libs path*]

Sorry for my long email, and thanks,
Guy

Doron Holan wrote:

By “just now” do you mean “right now at this very instant”? If that

is

what you mean, no KMDF does not support this model for idling out in

S0

(it does support this for powering off due to an Sx transition

though).

But like I said, you can get nearly now behavior by setting an

extremely

short timeout when assign s0 idle settings. Why would you need “off
right now” for S0 idle?

If you don’t want to reassign the idle timeout all the time, you

could

explicitly disable idle by calling WdfDeviceStopIdle and then calling
WdfDeviceResumeIdle. Usually you control this behavior by routing

i/o

through power managed queues instead of explicitly managing the idle
state with these DDIs.

d

-----Original Message-----
From:xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Friday, June 22, 2007 7:38 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmdf - powering down a device

Can KMDF’s PPO implementation be ordered to initiate power down
“just now”?

Tim_Roberts · June 22, 2007, 9:10pm

Guy Corem wrote:

Tim Roberts wrote:

>> Goy Corem wrote:
>>
>>
>>> I’ve implemented a user space I/O driver: A kernel driver that maps a
>>> PCI card memory mapped ranges to a user mode client virtual address
>>>
>>>
> Now, there are plenty of reasons why it can be a bad idea to map PCI
> address spaces into user mode, but address safety isn’t one of them.
>
There are also plenty of reasons why it’s a good idea, sometimes…

Well, we’re delving into religion here, but there many on this list who
would argue that it is never a good idea. Necessary, perhaps, but a
necessary evil.

The reason we map devices into kernel mode is that kernel mode code is
“trusted”. User mode code is assumed to be slime-filled. By mapping a
device’s address space into user mode, it’s too easy for a rogue
application to bring down the system. That is a thing to be prevented
at all costs.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Doron_Holan · June 23, 2007, 10:26am

So, the one discrepancy we have is that when the idle timer is enabled
but not yet expired and the device is still in D0 on S0 -> Sx, it is not
put back into D0 upon Sx->S0. I will go back to the code and my test
cases to see if this is true on my side.

d

From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 5:39 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

No.

In all cases the device was in D0 before the Sx->S0 transition.

In all cases, I observe a call to D0Exit during the sleep transition.

Only in case 2, I don’t observe a call to D0Entry upon S0->Sx back
transition.

Guy

Doron Holan wrote:

Let’s see if I can condense this to one answer for all cases.

The only time you will remain in Dx after an Sx->S0 transition
is if you
were idled out and in Dx when you were in S0 before the Sx
occurred.
This means that if you never assign S0 idle settings, you will
always be
in D0 upon Sx->S0 b/c you never told the framework the device
could be
in Dx while in S0. This also means that when you set a
tremendously
long timeout, the device is still in D0 when we go to Sx, so we
put it
back into D0 when we come back b/c obviously the timer has not
yet
expired.

Make a little more sense now?

D

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 5:20 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Doron,

Thanks(!) for clarifying the issue around WdfDeviceStopIdle and
EvtDeviceAdd.

I’ve recoded according to your advice (using
EvtDeviceSelfManagedIoInit), and it worked like charm.

I’ve enjoyed very much to delete the IRP_MN_SET_POWER
post-processing
code…

Just lost a day around this issue. I should have emailed as soon
as I
observed the strange WdfDeviceStopIdle behavior.

Regarding “device remaining in Dx after resuming from Sx is by
design”:

Just for completion, I suspect another bug. During my trials,
I’ve
encountered the following (just verify it again now):

Using power managed default queue. No request in it.
Using secondary non power managed queue. One request pending
in it.
WdfDeviceStopIdle wasn’t call at all
WdfDeviceAssignS0IdleSettings wasn’t call at all.

If I understood your reply, there is no outstanding power
references.

Nevertheless, upon transition back to S0, the framework calls
/EvtDeviceD0Entry/

Starting from this “baseline”, I’ve started to modify:

Switching to non-power managed default queue. The framework
*does*
call /EvtDeviceD0Entry/ upon transition back to S0
Adding a call to WdfDeviceAssignS0IdleSettings with MAXULONG
timeout,
non-power managed default queue. The framework *doesn’t* call
/EvtDeviceD0Entry/ upon transition back to S0
Switching back to power managed default queue, calling
WdfDeviceAssignS0IdleSettings with MAXULONG timeout. The
framework
*does* call /EvtDeviceD0Entry/ upon transition back to S0

In all the above cases, there was no pending requests in the
default
queue, and one pending request in the secondary non power
managed queue.

If it’s “by design”, I really don’t understand the logic behind
it.

Thanks again,

Guy

Doron Holan wrote:

WdfDeviceStop/ResumeIdle are what you want to use in
your current
design. They are the manual way for you to change the
idle state of

the

device.

Assigning the idle settting and then immediately calling
WdfDeviceStopIdle in AddDevice fails b/c the power idle
state machine

is

not started, that would be a bug in KMDF that we don’t
respect that

call

so early in device creation. To work around this issue,
call
WdfDeviceStopIdle in EvtDeviceSelfManagedIoInit. By
doing this in
SelfManagedInit, you can set the idle timeout to 1 ms
during AddDevice
and never change the timeout value itself.

The power down will still be asynchronous. This is fine
as long you
either handle STATUS_PENDING returned from
WdfDeviceResumeIdle (if you
pass FALSE) or always call WdfDeviceResumeIdle with TRUE
so it will
block until you return D0. Note that you will have to
synchronize

your

manually managed power state with an Sx power down.
Remember, for an

Sx

power down, the device’s idle settings do not have any
effect, the
device is going to be powered down *now*. In a normal
driver, the

power

managed queue waits for /acknowledges in flight requests
to complete
before powering down, you will have to manually stop
processing

requests

from your manual queue in EvtDeviceSelfManagedIoSuspend
(probably by
stopping the queue, but I am not sure about that).

The device remaining in Dx after resuming from Sx is by
design if

there

are no outstanding power references on the device (why
put the device
back into a powered up state if nothing in the driver
requires it have
power?). A request in a power managed is a reference,
as is a call to
WdfDeviceStopIdle. As long as you have called
WdfDeviceStopIdle

without

a matching WdfDeviceResumeIdle, your device will be
powered on upon
returning to S0.

So that in a nutshell is how to do this in your current
design. I

think

though that you can leverage power managed queues more
then you are
today. Instead of having one non power managed manual
queue for all

of

your IOCTLs, create a parallel non power managed queue
as the top

level

dispatching queue for your IOCTLs. You then have
different sub queues
which could be power managed or not. I would think you
would have one
power managed manual queue and one non power managed
manual queue.

You

then route the IOCTL requests from the top level
parallel queue into

the

appropriate subqueue. For instance, the power own IOCTL
is put into

the

power managed queue, as are the notifications for
interrupts. The

power

down ioctl would be placed in the non power managed
queue. You can
divvy it up as much as you like as you see fit…

d

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 3:05 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Hi Doron,

First, A little bit about my driver.

I’ve implemented a user space I/O driver: A kernel
driver that maps a
PCI card memory mapped ranges to a user mode client
virtual address,

and

notify about interrupts and D0Entries / Exits via
pending IOCTLs

(which

the driver store in non power managed, manual dispatch
queue).

The driver is providing the following IOCTL interface:
Get memory

mapped

ranges, query device property, indicate status (for
pending
notifications), power down and power up.

Using power managed main queue will defeat my purposes.
Consider the
following scenario:

The application is sending an indicate status IOCTL,
which the

driver

keeps (pend) in the secondary manual dispatch queue. The
application

is

sending this IOCTL asynchronously (using overlapped
structure) or from

a

dedicated notification thread.

Later, the application is sending power down IOCTL.
The driver will
transition to D3 using (indeed) 1 timeout value in the
call to
WdfDeviceAssignS0IdleSettings.
The device D3Exit event will be called.
The D3Exit event will complete the pending
notification IOCTL.
The application will send another notification IOCTL,
and since the
default queue is power managed, the device will
transition back to

D0…

After a lot of trials, I’ve settled on the following
implementation:
(If you’ll suggest a better one, I’ll be happy to
switch…)

I’m using a non power managed default queue.
Powering Up is setting MAXULONG as the timeout value
(WdfDeviceAssignS0IdleSettings ). This is *UGLY* since
after ~49.7

days,

the device will power down automatically…

Powering Down is setting 1 as the timeout value
I don’t know why (bug?), but when resuming from
hibernation, if the
device was in D0 before the hibernation and the default
queue is not
power managed, the framework DOESN’T switch the device
back to D0.
I’ve overcome this problem by post-process the
IRP_MN_SET_POWER
transition to S0, and “powering up” the device back
manually, as
described in 2.

During my trials, I’ve encountered also the following
strange

behavior:

Despite a call to WdfDevieStopIdle (from DeviceAdd,
after setting the
idle timeout value), the framework, nevertheless,
transition the

device

to D3 when the timeout expire…

I’m testing on Vista64.

I’m compiling against KMDF 1.7 headers (WDK 6001), but
linking against
KMDF 1.5 libraries (WDK 6000)

[My sources file contain the following lines:
KMDF_VERSION_MINOR=5
KMDF_LIB_PATH=KMDF1.5 libs path*]

Sorry for my long email, and thanks,
Guy

Doron Holan wrote:

By “just now” do you mean “right now at this
very instant”? If that

is

what you mean, no KMDF does not support this
model for idling out in

S0

(it does support this for powering off due to an
Sx transition

though).

But like I said, you can get nearly now behavior
by setting an

extremely

short timeout when assign s0 idle settings. Why
would you need “off
right now” for S0 idle?

If you don’t want to reassign the idle timeout
all the time, you

could

explicitly disable idle by calling
WdfDeviceStopIdle and then calling
WdfDeviceResumeIdle. Usually you control this
behavior by routing

i/o

through power managed queues instead of
explicitly managing the idle
state with these DDIs.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On
Behalf Of Maxim S.
Shatskih
Sent: Friday, June 22, 2007 7:38 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmdf - powering down a
device

Can KMDF’s PPO implementation be ordered to
initiate power down
“just now”?

Doron_Holan · June 23, 2007, 12:33pm

I looked at the Sx->S0 logic and I oversimplified/misspoke for one case

If (idle not enabled or idle enabled and capable of S0 Wake) {

GotoD0()

}

Else {

// idle enabled, not wake capable

If (there is a power ref) {

GotoD0()

}

Else {

RemainInDx();

}

So, we remain Dx regardless of the device power state in the previous
S0 if you are idle capable (but not able to wake) and there is no reason
to put your device back into D0. Is this not respecting the idle
timeout? Yes. Is it wrong behavior? Not entirely. One of the design
points for KMDF was to aggressively turn off the device when not in use
and this could be considered one of those cases. Like I mentioned
before, a power managed queue or a call to WdfDeviceStopIdle will fix
this for you. I will file a bug to consider only keeping the device in
Dx in the idle enabled/not wake capable case if the device was
previously in Dx in the previous S0.

d

From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 5:39 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

No.

In all cases the device was in D0 before the Sx->S0 transition.

In all cases, I observe a call to D0Exit during the sleep transition.

Only in case 2, I don’t observe a call to D0Entry upon S0->Sx back
transition.

Guy

Doron Holan wrote:

Let’s see if I can condense this to one answer for all cases.

The only time you will remain in Dx after an Sx->S0 transition
is if you
were idled out and in Dx when you were in S0 before the Sx
occurred.
This means that if you never assign S0 idle settings, you will
always be
in D0 upon Sx->S0 b/c you never told the framework the device
could be
in Dx while in S0. This also means that when you set a
tremendously
long timeout, the device is still in D0 when we go to Sx, so we
put it
back into D0 when we come back b/c obviously the timer has not
yet
expired.

Make a little more sense now?

D

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 5:20 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Doron,

Thanks(!) for clarifying the issue around WdfDeviceStopIdle and
EvtDeviceAdd.

I’ve recoded according to your advice (using
EvtDeviceSelfManagedIoInit), and it worked like charm.

I’ve enjoyed very much to delete the IRP_MN_SET_POWER
post-processing
code…

Just lost a day around this issue. I should have emailed as soon
as I
observed the strange WdfDeviceStopIdle behavior.

Regarding “device remaining in Dx after resuming from Sx is by
design”:

Just for completion, I suspect another bug. During my trials,
I’ve
encountered the following (just verify it again now):

Using power managed default queue. No request in it.
Using secondary non power managed queue. One request pending
in it.
WdfDeviceStopIdle wasn’t call at all
WdfDeviceAssignS0IdleSettings wasn’t call at all.

If I understood your reply, there is no outstanding power
references.

Nevertheless, upon transition back to S0, the framework calls
/EvtDeviceD0Entry/

Starting from this “baseline”, I’ve started to modify:

Switching to non-power managed default queue. The framework
*does*
call /EvtDeviceD0Entry/ upon transition back to S0
Adding a call to WdfDeviceAssignS0IdleSettings with MAXULONG
timeout,
non-power managed default queue. The framework *doesn’t* call
/EvtDeviceD0Entry/ upon transition back to S0
Switching back to power managed default queue, calling
WdfDeviceAssignS0IdleSettings with MAXULONG timeout. The
framework
*does* call /EvtDeviceD0Entry/ upon transition back to S0

In all the above cases, there was no pending requests in the
default
queue, and one pending request in the secondary non power
managed queue.

If it’s “by design”, I really don’t understand the logic behind
it.

Thanks again,

Guy

Doron Holan wrote:

WdfDeviceStop/ResumeIdle are what you want to use in
your current
design. They are the manual way for you to change the
idle state of

the

device.

Assigning the idle settting and then immediately calling
WdfDeviceStopIdle in AddDevice fails b/c the power idle
state machine

is

not started, that would be a bug in KMDF that we don’t
respect that

call

so early in device creation. To work around this issue,
call
WdfDeviceStopIdle in EvtDeviceSelfManagedIoInit. By
doing this in
SelfManagedInit, you can set the idle timeout to 1 ms
during AddDevice
and never change the timeout value itself.

The power down will still be asynchronous. This is fine
as long you
either handle STATUS_PENDING returned from
WdfDeviceResumeIdle (if you
pass FALSE) or always call WdfDeviceResumeIdle with TRUE
so it will
block until you return D0. Note that you will have to
synchronize

your

manually managed power state with an Sx power down.
Remember, for an

Sx

power down, the device’s idle settings do not have any
effect, the
device is going to be powered down *now*. In a normal
driver, the

power

managed queue waits for /acknowledges in flight requests
to complete
before powering down, you will have to manually stop
processing

requests

from your manual queue in EvtDeviceSelfManagedIoSuspend
(probably by
stopping the queue, but I am not sure about that).

The device remaining in Dx after resuming from Sx is by
design if

there

are no outstanding power references on the device (why
put the device
back into a powered up state if nothing in the driver
requires it have
power?). A request in a power managed is a reference,
as is a call to
WdfDeviceStopIdle. As long as you have called
WdfDeviceStopIdle

without

a matching WdfDeviceResumeIdle, your device will be
powered on upon
returning to S0.

So that in a nutshell is how to do this in your current
design. I

think

though that you can leverage power managed queues more
then you are
today. Instead of having one non power managed manual
queue for all

of

your IOCTLs, create a parallel non power managed queue
as the top

level

dispatching queue for your IOCTLs. You then have
different sub queues
which could be power managed or not. I would think you
would have one
power managed manual queue and one non power managed
manual queue.

You

then route the IOCTL requests from the top level
parallel queue into

the

appropriate subqueue. For instance, the power own IOCTL
is put into

the

power managed queue, as are the notifications for
interrupts. The

power

down ioctl would be placed in the non power managed
queue. You can
divvy it up as much as you like as you see fit…

d

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 3:05 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Hi Doron,

First, A little bit about my driver.

I’ve implemented a user space I/O driver: A kernel
driver that maps a
PCI card memory mapped ranges to a user mode client
virtual address,

and

notify about interrupts and D0Entries / Exits via
pending IOCTLs

(which

the driver store in non power managed, manual dispatch
queue).

The driver is providing the following IOCTL interface:
Get memory

mapped

ranges, query device property, indicate status (for
pending
notifications), power down and power up.

Using power managed main queue will defeat my purposes.
Consider the
following scenario:

The application is sending an indicate status IOCTL,
which the

driver

keeps (pend) in the secondary manual dispatch queue. The
application

is

sending this IOCTL asynchronously (using overlapped
structure) or from

a

dedicated notification thread.

Later, the application is sending power down IOCTL.
The driver will
transition to D3 using (indeed) 1 timeout value in the
call to
WdfDeviceAssignS0IdleSettings.
The device D3Exit event will be called.
The D3Exit event will complete the pending
notification IOCTL.
The application will send another notification IOCTL,
and since the
default queue is power managed, the device will
transition back to

D0…

After a lot of trials, I’ve settled on the following
implementation:
(If you’ll suggest a better one, I’ll be happy to
switch…)

I’m using a non power managed default queue.
Powering Up is setting MAXULONG as the timeout value
(WdfDeviceAssignS0IdleSettings ). This is *UGLY* since
after ~49.7

days,

the device will power down automatically…

Powering Down is setting 1 as the timeout value
I don’t know why (bug?), but when resuming from
hibernation, if the
device was in D0 before the hibernation and the default
queue is not
power managed, the framework DOESN’T switch the device
back to D0.
I’ve overcome this problem by post-process the
IRP_MN_SET_POWER
transition to S0, and “powering up” the device back
manually, as
described in 2.

During my trials, I’ve encountered also the following
strange

behavior:

Despite a call to WdfDevieStopIdle (from DeviceAdd,
after setting the
idle timeout value), the framework, nevertheless,
transition the

device

to D3 when the timeout expire…

I’m testing on Vista64.

I’m compiling against KMDF 1.7 headers (WDK 6001), but
linking against
KMDF 1.5 libraries (WDK 6000)

[My sources file contain the following lines:
KMDF_VERSION_MINOR=5
KMDF_LIB_PATH=KMDF1.5 libs path*]

Sorry for my long email, and thanks,
Guy

Doron Holan wrote:

By “just now” do you mean “right now at this
very instant”? If that

is

what you mean, no KMDF does not support this
model for idling out in

S0

(it does support this for powering off due to an
Sx transition

though).

But like I said, you can get nearly now behavior
by setting an

extremely

short timeout when assign s0 idle settings. Why
would you need “off
right now” for S0 idle?

If you don’t want to reassign the idle timeout
all the time, you

could

explicitly disable idle by calling
WdfDeviceStopIdle and then calling
WdfDeviceResumeIdle. Usually you control this
behavior by routing

i/o

through power managed queues instead of
explicitly managing the idle
state with these DDIs.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On
Behalf Of Maxim S.
Shatskih
Sent: Friday, June 22, 2007 7:38 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmdf - powering down a
device

Can KMDF’s PPO implementation be ordered to
initiate power down
“just now”?

Jake_Oshins · June 23, 2007, 5:50pm

The other reason for this decision was that it significantly speeds up the
computer as it’s coming out of a sleep state and back into S0. If every
device has to be put in D0 before the machine gets to S0, the whole machine
slows down. If there’s actually a reason to be in D0, i.e. there a power
reference (or an implied power reference because there’s an IRP in a
power-managed queue,) then that’s fine and the machine wakes up a little
more slowly. But if there isn’t a power reference, then wakeup speed is
more important.

Jake Oshins

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I looked at the Sx->S0 logic and I oversimplified/misspoke for one case

If (idle not enabled or idle enabled and capable of S0 Wake) {
GotoD0()
}
Else {
// idle enabled, not wake capable
If (there is a power ref) {
GotoD0()
}
Else {
RemainInDx();
}
}

So, we remain Dx regardless of the device power state in the previous S0 if
you are idle capable (but not able to wake) and there is no reason to put
your device back into D0. Is this not respecting the idle timeout? Yes. Is
it wrong behavior? Not entirely. One of the design points for KMDF was to
aggressively turn off the device when not in use and this could be
considered one of those cases. Like I mentioned before, a power managed
queue or a call to WdfDeviceStopIdle will fix this for you. I will file a
bug to consider only keeping the device in Dx in the idle enabled/not wake
capable case if the device was previously in Dx in the previous S0.

d

From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 5:39 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

No.

In all cases the device was in D0 before the Sx->S0 transition.
In all cases, I observe a call to D0Exit during the sleep transition.
Only in case 2, I don’t observe a call to D0Entry upon S0->Sx back
transition.

Guy

Doron Holan wrote:
Let’s see if I can condense this to one answer for all cases.

The only time you will remain in Dx after an Sx->S0 transition is if you
were idled out and in Dx when you were in S0 before the Sx occurred.
This means that if you never assign S0 idle settings, you will always be
in D0 upon Sx->S0 b/c you never told the framework the device could be
in Dx while in S0. This also means that when you set a tremendously
long timeout, the device is still in D0 when we go to Sx, so we put it
back into D0 when we come back b/c obviously the timer has not yet
expired.

Make a little more sense now?

D

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 5:20 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Doron,

Thanks(!) for clarifying the issue around WdfDeviceStopIdle and
EvtDeviceAdd.

I’ve recoded according to your advice (using
EvtDeviceSelfManagedIoInit), and it worked like charm.

I’ve enjoyed very much to delete the IRP_MN_SET_POWER post-processing
code…

Just lost a day around this issue. I should have emailed as soon as I
observed the strange WdfDeviceStopIdle behavior.

Regarding “device remaining in Dx after resuming from Sx is by design”:

Just for completion, I suspect another bug. During my trials, I’ve
encountered the following (just verify it again now):

1) Using power managed default queue. No request in it.

2) Using secondary non power managed queue. One request pending in it.

3) WdfDeviceStopIdle wasn’t call at all

4) WdfDeviceAssignS0IdleSettings wasn’t call at all.

If I understood your reply, there is no outstanding power references.

Nevertheless, upon transition back to S0, the framework calls
/EvtDeviceD0Entry/

Starting from this “baseline”, I’ve started to modify:

1) Switching to non-power managed default queue. The framework does
call /EvtDeviceD0Entry/ upon transition back to S0

2) Adding a call to WdfDeviceAssignS0IdleSettings with MAXULONG timeout,
non-power managed default queue. The framework doesn’t call
/EvtDeviceD0Entry/ upon transition back to S0

3) Switching back to power managed default queue, calling
WdfDeviceAssignS0IdleSettings with MAXULONG timeout. The framework
does call /EvtDeviceD0Entry/ upon transition back to S0

In all the above cases, there was no pending requests in the default
queue, and one pending request in the secondary non power managed queue.

If it’s “by design”, I really don’t understand the logic behind it.

Thanks again,

Guy

Doron Holan wrote:

WdfDeviceStop/ResumeIdle are what you want to use in your current
design. They are the manual way for you to change the idle state of

the

device.

Assigning the idle settting and then immediately calling
WdfDeviceStopIdle in AddDevice fails b/c the power idle state machine

is

not started, that would be a bug in KMDF that we don’t respect that

call

so early in device creation. To work around this issue, call
WdfDeviceStopIdle in EvtDeviceSelfManagedIoInit. By doing this in
SelfManagedInit, you can set the idle timeout to 1 ms during AddDevice
and never change the timeout value itself.

The power down will still be asynchronous. This is fine as long you
either handle STATUS_PENDING returned from WdfDeviceResumeIdle (if you
pass FALSE) or always call WdfDeviceResumeIdle with TRUE so it will
block until you return D0. Note that you will have to synchronize

your

manually managed power state with an Sx power down. Remember, for an

Sx

power down, the device’s idle settings do not have any effect, the
device is going to be powered down now. In a normal driver, the

power

managed queue waits for /acknowledges in flight requests to complete
before powering down, you will have to manually stop processing

requests

from your manual queue in EvtDeviceSelfManagedIoSuspend (probably by
stopping the queue, but I am not sure about that).

The device remaining in Dx after resuming from Sx is by design if

there

are no outstanding power references on the device (why put the device
back into a powered up state if nothing in the driver requires it have
power?). A request in a power managed is a reference, as is a call to
WdfDeviceStopIdle. As long as you have called WdfDeviceStopIdle

without

a matching WdfDeviceResumeIdle, your device will be powered on upon
returning to S0.

So that in a nutshell is how to do this in your current design. I

think

though that you can leverage power managed queues more then you are
today. Instead of having one non power managed manual queue for all

of

your IOCTLs, create a parallel non power managed queue as the top

level

dispatching queue for your IOCTLs. You then have different sub queues
which could be power managed or not. I would think you would have one
power managed manual queue and one non power managed manual queue.

You

then route the IOCTL requests from the top level parallel queue into

the

appropriate subqueue. For instance, the power own IOCTL is put into

the

power managed queue, as are the notifications for interrupts. The

power

down ioctl would be placed in the non power managed queue. You can
divvy it up as much as you like as you see fit…

d

-----Original Message-----
From: Guy Corem [mailto:xxxxx@aptocom.com]
Sent: Friday, June 22, 2007 3:05 PM
To: Doron Holan
Cc: Windows System Software Devs Interest List
Subject: Re: kmdf - powering down a device

Hi Doron,

First, A little bit about my driver.

I’ve implemented a user space I/O driver: A kernel driver that maps a
PCI card memory mapped ranges to a user mode client virtual address,

and

notify about interrupts and D0Entries / Exits via pending IOCTLs

(which

the driver store in non power managed, manual dispatch queue).

The driver is providing the following IOCTL interface: Get memory

mapped

ranges, query device property, indicate status (for pending
notifications), power down and power up.

Using power managed main queue will defeat my purposes. Consider the
following scenario:

1) The application is sending an indicate status IOCTL, which the

driver

keeps (pend) in the secondary manual dispatch queue. The application

is

sending this IOCTL asynchronously (using overlapped structure) or from

a

dedicated notification thread.

2) Later, the application is sending power down IOCTL. The driver will
transition to D3 using (indeed) 1 timeout value in the call to
WdfDeviceAssignS0IdleSettings.

3) The device D3Exit event will be called.

4) The D3Exit event will complete the pending notification IOCTL.

5) The application will send another notification IOCTL, and since the
default queue is power managed, the device will transition back to

D0…

After a lot of trials, I’ve settled on the following implementation:
(If you’ll suggest a better one, I’ll be happy to switch…)

1) I’m using a non power managed default queue.

2) Powering Up is setting MAXULONG as the timeout value
(WdfDeviceAssignS0IdleSettings ). This is UGLY since after ~49.7

days,

the device will power down automatically…

3) Powering Down is setting 1 as the timeout value

4) I don’t know why (bug?), but when resuming from hibernation, if the
device was in D0 before the hibernation and the default queue is not
power managed, the framework DOESN’T switch the device back to D0.
I’ve overcome this problem by post-process the IRP_MN_SET_POWER
transition to S0, and “powering up” the device back manually, as
described in 2.

During my trials, I’ve encountered also the following strange

behavior:

Despite a call to WdfDevieStopIdle (from DeviceAdd, after setting the
idle timeout value), the framework, nevertheless, transition the

device

to D3 when the timeout expire…

I’m testing on Vista64.

I’m compiling against KMDF 1.7 headers (WDK 6001), but linking against
KMDF 1.5 libraries (WDK 6000)

[My sources file contain the following lines:
KMDF_VERSION_MINOR=5
KMDF_LIB_PATH=KMDF1.5 libs path*]

Sorry for my long email, and thanks,
Guy

Doron Holan wrote:

By “just now” do you mean “right now at this very instant”? If that

is

what you mean, no KMDF does not support this model for idling out in

S0

(it does support this for powering off due to an Sx transition

though).

But like I said, you can get nearly now behavior by setting an

extremely

short timeout when assign s0 idle settings. Why would you need “off
right now” for S0 idle?

If you don’t want to reassign the idle timeout all the time, you

could

explicitly disable idle by calling WdfDeviceStopIdle and then calling
WdfDeviceResumeIdle. Usually you control this behavior by routing

i/o

through power managed queues instead of explicitly managing the idle
state with these DDIs.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Friday, June 22, 2007 7:38 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmdf - powering down a device

Can KMDF’s PPO implementation be ordered to initiate power down
“just now”?

OSR_Community_User · June 23, 2007, 11:29pm

Jake Oshins wrote:

The other reason for this decision was that it significantly speeds up the
computer as it’s coming out of a sleep state and back into S0. If every
device has to be put in D0 before the machine gets to S0, the whole machine
slows down. If there’s actually a reason to be in D0, i.e. there a power
reference (or an implied power reference because there’s an IRP in a
power-managed queue,) then that’s fine and the machine wakes up a little
more slowly. But if there isn’t a power reference, then wakeup speed is
more important.

Couldn’t be possible to implement the optimization that is shown in PCIDRV (completing the S0 IRP immediately without waiting for the D0 completion)? Yeah, I’m aware about the possible complications. That’s why I ask if it would be possible.

Jake_Oshins · June 23, 2007, 11:33pm

Sure. But that still eats processor time while powering up.

Jake Oshins

wrote in message news:xxxxx@ntdev…
> Jake Oshins wrote:
>
>> The other reason for this decision was that it significantly speeds up
>> the
>> computer as it’s coming out of a sleep state and back into S0. If every
>> device has to be put in D0 before the machine gets to S0, the whole
>> machine
>> slows down. If there’s actually a reason to be in D0, i.e. there a power
>> reference (or an implied power reference because there’s an IRP in a
>> power-managed queue,) then that’s fine and the machine wakes up a little
>> more slowly. But if there isn’t a power reference, then wakeup speed is
>> more important.
>
> Couldn’t be possible to implement the optimization that is shown in PCIDRV
> (completing the S0 IRP immediately without waiting for the D0 completion)?
> Yeah, I’m aware about the possible complications. That’s why I ask if it
> would be possible.
>
>

Doron_Holan · June 24, 2007, 12:03am

Not only is it possible, KMDF implements this (it is called fast
resume).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Saturday, June 23, 2007 8:33 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmdf - powering down a device

Sure. But that still eats processor time while powering up.

Jake Oshins

wrote in message news:xxxxx@ntdev…
> Jake Oshins wrote:
>
>> The other reason for this decision was that it significantly speeds
up
>> the
>> computer as it’s coming out of a sleep state and back into S0. If
every
>> device has to be put in D0 before the machine gets to S0, the whole
>> machine
>> slows down. If there’s actually a reason to be in D0, i.e. there a
power
>> reference (or an implied power reference because there’s an IRP in a
>> power-managed queue,) then that’s fine and the machine wakes up a
little
>> more slowly. But if there isn’t a power reference, then wakeup speed
is
>> more important.
>
> Couldn’t be possible to implement the optimization that is shown in
PCIDRV
> (completing the S0 IRP immediately without waiting for the D0
completion)?
> Yeah, I’m aware about the possible complications. That’s why I ask if
it
> would be possible.
>
>

—
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

OSR_Community_User · June 24, 2007, 12:24am

I see, good to know.

I misunderstood Jake’s post. Because while it’s true that the transition to D0 still consumes processor time, in many cases it is a small fraction of the wall clock time it takes.

Doron Holan wrote:
-----Original Message-----
Doron Holan wrote:

Not only is it possible, KMDF implements this (it is called fast
resume).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Saturday, June 23, 2007 8:33 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmdf - powering down a device

Sure. But that still eats processor time while powering up.

Jake Oshins

wrote in message news:xxxxx@ntdev…
> Jake Oshins wrote:
>
>> The other reason for this decision was that it significantly speeds
>> up the computer as it’s coming out of a sleep state and back into S0.
>> If every device has to be put in D0 before the machine gets to S0, the whole
>> machine slows down.
>
> Couldn’t be possible to implement the optimization that is shown in PCIDRV
> (completing the S0 IRP immediately without waiting for the D0 completion)?
> Yeah, I’m aware about the possible complications. That’s why I ask if
> it would be possible.