We are making USB image capture device with a driver like UsbIntel.

I added IdleNotification routine to the driver.

A PC pluged in our device wasn't able to suspend sometimes.

My attention is in PoRequestPowerIrp call of
IdleNotificationRequestComplete.

Now our driver code is as below.

powerState.DeviceState = PowerDeviceD0;
PoRequestPowerIrp(
...
IRP_MN_SET_POWER,
powerState,
...
);

When I delete this function call PoRequestPowerIrp,
A PC pluged in our device was able to suspend always.
But My device power is still off.

In IdleNotificationRequestComplete I must know
whether our driver should go to D3 or D0.

Please help me.
Thanks in Advance,

shinji

RE: Should UsbIntel driver go to D3 or D0 inIdleNotificationRequestComplete by martinbo

martinbo
Mon Nov 21 20:51:11 CST 2005

------=_NextPart_0001_0AE05399
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

If you look at the DDK samples that use
IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION, it shows that the completion
handler for this request only tries to set the device back to D0 if the
IOCTL failed. Are you always setting D0 in the completion handler, or
only when the IOCTL has failed?

Martin Borve
Windows DDK Support
This posting is provided "AS IS" with no warranties, and confers no rights.



------=_NextPart_0001_0AE05399
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 If you look at the DDK samples that use IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION, it shows that the completion handler for this request only tries to set the device back to D0 if the IOCTL failed. Are you always setting D0 in the completion handler, or only when the IOCTL has failed?
\par
\par Martin Borve
\par Windows DDK Support
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par
\par
\par }
------=_NextPart_0001_0AE05399--


Re: Should UsbIntel driver go to D3 or D0 inIdleNotificationRequestComplete by shinji

shinji
Mon Nov 21 23:05:58 CST 2005

Thank you for your reply.

> If you look at the DDK samples that use
> IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION, it shows that the completion
> handler for this request only tries to set the device back to D0 if the
> IOCTL failed.

I read selsusp sample again.

I think
"the completion handler " that you wrote means
IdleNotificationRequestComplete,
"if the IOCTL failed" means "IdleNotificationRequestComplete was called".

When selective suspend is broken by other usb pluging or
by closing OS( power-off, stand-by ), Irp->IoStatus.Status of
IdleNotificationRequestComplete
is STATUS_CANCELLED always.

And depending on Irp->IoStatus.Status and DeviceExtension->DevPower,
usually PoRequestPowerIrp was called and raised up to D0.

a comment of ssdevctrr.c said "if the irp completes in error, request for a
SetD0 only if not in D0".

If the irp completes in error always, I must setD0 always.