I have here a USB device that uses WinUSB. In Device Manager, in
Details, under “Power data”, it shows that D2 and D3 are supported. The
power state mappings are shown as:
S0 -> D0
S1 -> D2
S2 -> D2
S3 -> D2
S4 -> D2
S5 -> D3
This matches reality: if I capture an ETW trace while putting the
machine into S3, I see that the device is being put into D2.
My question is, why does S3 map to D2? We want S3 to map to D3. There
are four other interfaces in this device (all UVC), and they happily map
S3 to D3. This one interface is keeping the whole device from going
into D3.
There are registry entries to control selective suspend in WinUSB, but I
don’t see anything to control this. Is this just a built-in artifact of
WinUSB? Would I have to use a UMDF driver to become the power policy owner?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
I have here a USB device that uses WinUSB. In Device Manager, in
Details, under “Power data”, it shows that D2 and D3 are supported. The
power state mappings are shown as:
S0 -> D0
S1 -> D2
S2 -> D2
S3 -> D2
S4 -> D2
S5 -> D3
This matches reality: if I capture an ETW trace while putting the
machine into S3, I see that the device is being put into D2.
My question is, why does S3 map to D2? We want S3 to map to D3.
It may be important to point out that this is a self-powered device.
Does WinUSB care about that?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I will be curious to know why is it important to go to D3 vs D2. Is it about going to a deeper sleep state? If so, please note that both D2 and D3 map to the same state in USB. So going to D3 doesn’t generally lead to greater power savings (unless ACPI is doing something special for D3). The only relevant pivot is whether the device is armed for wake or not.
As for the winusb behavior, I think the choice of D2/D3 might also depend on whether the interface is being armed for system wake or not. USB drivers cannot go to D3 if they are being armed for wake.
There is a registry entry to control the wake policy in winusb. http://msdn.microsoft.com/en-us/library/windows/hardware/ff728834(v=vs.85).aspx
>
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, May 29, 2014 4:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WinUSB and Power Management
Tim Roberts wrote:
> I have here a USB device that uses WinUSB. In Device Manager, in
> Details, under “Power data”, it shows that D2 and D3 are supported.
> The power state mappings are shown as:
>
> S0 -> D0
> S1 -> D2
> S2 -> D2
> S3 -> D2
> S4 -> D2
> S5 -> D3
>
> This matches reality: if I capture an ETW trace while putting the
> machine into S3, I see that the device is being put into D2.
>
> My question is, why does S3 map to D2? We want S3 to map to D3.
It may be important to point out that this is a self-powered device.
Does WinUSB care about that?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Doron Holan wrote:
PEZyb20gdGhlIHVzYiBsZWFkPg0KDQpJIHdpbGwgYmU
gY3VyaW91cyB0byBrbm93IHdoeSBpcyBpdCBpbXBvc
nRhbnQgdG8gZ28gdG8gRDMgdnMgRDIuIElzIGl0IGFib
3V0IGdvaW5nIHRvIGEgZGVlcGVyIHNsZWVwI
HN0YXRlPyBJZiBzbywgcGxlYXNlIG5vdGUgdGhhdCBib3R
oIEQyIGFuZCBEMyBt
Really, you don’t say. Fascinating.
xxxxx@gmail.com wrote:
Doron Holan wrote:
> PEZyb20gdGhlIHVzYiBsZWFkPg0KDQpJIHdpbGwgYmU
> gY3VyaW91cyB0byBrbm93IHdoeSBpcyBpdCBpbXBvc
> nRhbnQgdG8gZ28gdG8gRDMgdnMgRDIuIElzIGl0IGFib
> 3V0IGdvaW5nIHRvIGEgZGVlcGVyIHNsZWVwI
> HN0YXRlPyBJZiBzbywgcGxlYXNlIG5vdGUgdGhhdCBib3R
> oIEQyIGFuZCBEMyBt
Really, you don’t say. Fascinating.
What email program do you use? Or do you read through the web? This
came through just fine for me. It was text/plain in Base64, which is
certainly allowed, although unusual.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I don’t control encoding, outlook does that 
d
Bent from my phone
From: Tim Robertsmailto:xxxxx
Sent: ?5/?30/?2014 9:56 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] WinUSB and Power Management
xxxxx@gmail.com wrote:
> Doron Holan wrote:
>
>> PEZyb20gdGhlIHVzYiBsZWFkPg0KDQpJIHdpbGwgYmU
>> gY3VyaW91cyB0byBrbm93IHdoeSBpcyBpdCBpbXBvc
>> nRhbnQgdG8gZ28gdG8gRDMgdnMgRDIuIElzIGl0IGFib
>> 3V0IGdvaW5nIHRvIGEgZGVlcGVyIHNsZWVwI
>> HN0YXRlPyBJZiBzbywgcGxlYXNlIG5vdGUgdGhhdCBib3R
>> oIEQyIGFuZCBEMyBt
> Really, you don’t say. Fascinating.
What email program do you use? Or do you read through the web? This
came through just fine for me. It was text/plain in Base64, which is
certainly allowed, although unusual.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>
Doron Holan wrote:
I will be curious to know why is it important to go to D3 vs D2. Is it about going to a deeper sleep state? If so, please note that both D2 and D3 map to the same state in USB. So going to D3 doesn’t generally lead to greater power savings (unless ACPI is doing something special for D3). The only relevant pivot is whether the device is armed for wake or not.
As for the winusb behavior, I think the choice of D2/D3 might also depend on whether the interface is being armed for system wake or not. USB drivers cannot go to D3 if they are being armed for wake.
This was quite revealing, thanks. What it pointed out is that I should
have done more digging to find out what my client expected. It now
seems they expected the WDM Dx states to correspond one-to-one to the
USB 3 Ux link states. So, to get their link to U3, they thought they
needed the driver in D3. That’s simply not the case, especially for U3,
where the request actually comes from the device, not the host.
My [ntdev] subscription paid for itself today.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I’ve had long discussions in the past with the Windows USB team on how there is no “off” for USB devices (think gang powered hubs). From a USB point of view, D1, D2, D3 are all mapped for suspend. The hub driver will map Sx states to D2 or D3 depending on whether remote wakeup is supported by the device in suspend and if the system has Vbus powered in the Sx state.
I haven’t done it, but I think you can arm a device for remote wakeup and go to D3. I don’t think the USB 2.0 stack will prevent that.
Tim Roberts wrote:
What email program do you use? Or do you read through
the web?
Google and I read “through the web”.
This came through just fine for me. It was text/plain in Base64,
which is certainly allowed, although unusual.
Look, let’s be serious for a second. I’ve been on this list a long time, and you’ve been on even longer. Only in the last six months to a year, when people starting posting with these “Surface Pro” machinations, that these posts started appearing as giant, indecipherable walls of garbage.
So why is the “Surface version” of Outlook deciding to send Base64 emails all of a sudden? Probably the same reason Outlook switched to its own, broken HTML email renderer (instead of using Internet Explorer’s) starting in Office 2007.
I sent it from outlook 2010, no surface
d
Bent from my phone
From: xxxxx@gmail.commailto:xxxxx
Sent: ?5/?31/?2014 3:14 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] WinUSB and Power Management
Tim Roberts wrote:
> What email program do you use? Or do you read through
> the web?
Google and I read “through the web”.
> This came through just fine for me. It was text/plain in Base64,
> which is certainly allowed, although unusual.
Look, let’s be serious for a second. I’ve been on this list a long time, and you’ve been on even longer. Only in the last six months to a year, when people starting posting with these “Surface Pro” machinations, that these posts started appearing as giant, indecipherable walls of garbage.
So why is the “Surface version” of Outlook deciding to send Base64 emails all of a sudden? Probably the same reason Outlook switched to its own, broken HTML email renderer (instead of using Internet Explorer’s) starting in Office 2007.
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>
[RANT]
I’m sorry, Tim. I can’t help you with WinUSB.
I *can* however commiserate around any problem that involves getting a system into Connected Standby. There will be a “period of transition” (ahem) where we all figure this out. So far, it is not going smoothly. To date, getting *anything* that engineers at Microsoft didn’t personally help make work to support Connected Standby has proved, uh, “very frustrating” – I’m in the special hell that is reserved for this kind of issue even as I type this. I spend a lot of time asking “Does xxxx know if the entire platform *really* supports Connected Standby??” and “You DO realize that there’s more to supporting Connected Standby than just ticking the option in the BIOS, right?”
So I am watching this thread carefully to see if I can learn something.
Peter
OSR
@OSRDrivers
[/RANT]
Please note that the S to D mappings are not relevant for CS at all. There is no Sx transition involved in CS. For a system to enter CS, all USB devices must go to D2/D3 while the system remains in S0 (In other words, the device must support S0Idle/Selective suspend).
So the question here is whether the winusb interface goes to either D2 or D3 while the system is in S0. Can you confirm that? One way to check that would be to capture and look at USB ETW logs: http://blogs.msdn.com/b/usbcoreblog/archive/2012/08/07/how-to-trace-usb-3-activity.aspx
Winusb exposes a number of settings to control S0Idle behavior. Please look at Selective Suspend section of the following link.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff728834(v=vs.85).aspx
On Jun 2, 2014, at 9:11 PM, xxxxx@live.com wrote:
Please note that the S to D mappings are not relevant for CS at all. There is no Sx transition involved in CS. For a system to enter CS, all USB devices must go to D2/D3 while the system remains in S0 (In other words, the device must support S0Idle/Selective suspend).
So the question here is whether the winusb interface goes to either D2 or D3 while the system is in S0. Can you confirm that? One way to check that would be to capture and look at USB ETW logs: http://blogs.msdn.com/b/usbcoreblog/archive/2012/08/07/how-to-trace-usb-3-activity.aspx
Winusb exposes a number of settings to control S0Idle behavior. Please look at Selective Suspend section of the following link.
The one, true final answer was buried between the lines here, when mixed with prior answers on this list.
WinUSB will not allow the device to go into selective suspend unless the device advertises itself as being able to wake. Simply advertising the ability to go into D2 or D3 is not enough to allow the device to do so while in S0. It would happily go into D2 when the system went to sleep, but as long as the system was in S0, the device would stay in D0.
So, we added DeviceIdleIgnoreWakeEnable, which allows the device to selective suspend without supporting remote wake. Once we did that, the device happily went into D2, and the system happily went into Connected Standby.
I?m not sure I would have made that connection on my own, but the client is happy.
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.