You are assuming that the hardware works. For instance on ICH2 host controllers, if you powered down one of the root ports, the only way to get the port back to full power was to power off the entire controller first. There are hubs which cannot power down individual ports. Furthermore, the power savings from just one port being powered down while the others are still powered up is minimal at best (I think non existent). This is not a usb spec compliance issue, this is the real world of bad hw implementations being worked around. Basically for all shipping operating systems, USB SS compensates for all these issues by making sure it can power down the entire hardware tree before going into low power. On Vista, the usb core was rewritten to allow individual ports to power down. Furthermore, the generic parent driver (usbgccp on XP and later, usbhub on win2k) does not support the USB SS IOCTL which means that usb SS is useless for composite devices.
IMHO, PoRegisterDeviceForIdleDetection and PoSetDeviceBusy are useless. They don’t buy you anything. All they will do is send you a Dx irp after a certain period. I feel that they are useless b/c you are not explicitly sending them, which means that your power policy state machine cannot be in a definitive state to process them. You are better off with your own timer so you can manage your own power policy state. I have seen these 2 APIs used successfully only in the disk stack (and I have experimented with them in other stacks like HID)
d
From: Edward Dekker [mailto:xxxxx@eclectic-eng.com]
Sent: Monday, December 26, 2005 9:42 AM
To: Windows System Software Devs Interest List
Cc: Doron Holan
Subject: RE: [ntdev] USB Selective suspend
Doron,
Why would Windows Selective Suspend care about devices on other ports on the hub?
I have been unable to find any issues that would dictate this in the USB spec.
My understanding of the USB suspend mechanism is that the suspend is based on ports.? The power management software for USB sends a SetPortFeature(PORT_SUSPEND) to the hub port my device is plugged into to place my device in the Idle State.? In theory this should not affect any other device plugged into the other ports of the hub.
My understanding was that the Windows Selective Suspend assures that all components of a multi-function device are ready to power down to a lower device power state before the shared hub port connecting them to the system is placed in suspend.
The Windows 2000 style device idle power management as well as the Windows XP Selective Suspend implement what the USB specification refers to as Selective Suspend,? the lowering of the device power state of a USB device to cause the device to enter the Idle state by placing one or more hub ports in the suspend state.?
When I modify my driver to use Windows 2000 style idle power management (PoRegisterDeviceForIdleDetection, PoSetDeviceBusy) in place of the Selective Suspend should I expect the same restriction?
Ed
At 12:42 PM 12/23/2005, Doron Holan wrote:
All devices on the bus have to support SS for SS to be initiated.? It sounds like the mouse is not enabled for SS (probably b/c it can’t wake itself up using all functions and appear seamless to the user).
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Edward Dekker
Sent: Friday, December 23, 2005 3:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] USB Selective suspend
I have a Power Management / Selective Suspend bug I can not find.
The device is a bus powered USB device.? It is a simple USB device with a single configuration and interface. With the device as the only USB peripheral (directly connected to the USB adapter or connected through an external hub) the driver will usually place the device into and out of? idle using selective suspend as expected.?
(I am using Selective Suspend to place the device into low power mode not to wake the system from a sleeping system power state.)
When a mouse is plugged into another port on the internal or external hub the selective suspend fails almost every time.
The selective suspend logic is based on the SelSUSB driver in the DDK.? A timer DPC queues a work item which builds and submits the IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION IRP.?
When the selective suspend works I see the idle notification callback called and issue the power IRP to change the device power state.?? When it fails there is no call to the idle callback.
The simplest failure is to hot plug in the device with a mouse already plugged into the hub of a running system.? It will almost always fail.? Without the mouse it takes many plug/unplug cycles with the device to see this bug.
The power trace (thanks Don) produces only one trace message (in AddDevice):
PLOG,00330,setstate,do@861a5018,dev,0
The USB trace options show a few lines when the IDLE_NOTIFICATION IRP is submitted:
XXXXUSB Submit an idle request at power state PowerDeviceD0
USBHUB.SYS: 'PdoDispatch DeviceExtension 863c94d0 Irp 861b7988
USBHUB.SYS: 'Internal Device Control
USBHUB.SYS: 'Idle request 863c94d0, IRP 861b7988
USBHUB.SYS: 'Hub Check Idle 8614b9c8
USBHUB.SYS: '***WAIT reset device mutex 8614b9c8
USBHUB.SYS: '***WAIT reset device mutex done 8614b9c8
USBHUB.SYS: '***RELEASE reset device mutex 8614b9c8
USBHUB.SYS: ’ exit USBH_PdoDispatch Object 863c9418 Status 103
XXXXUSB SubmitIdleRequestIrp - ends? (status = 0x103
Any suggestions?
Ed
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com