DeviceState in DEVICE_CAPABILITIES

NTDEV
1

So, power mappings. Filled in by the bus driver, but based on what information? How does it decide the mappings, and what, and where from, is the information it uses?

What I would like to be able to do is change this to D0 for all states so the device is powered up during suspend and hibernate.

So far from looking at an enumeration there is only ‘self powered’ and ‘remote wakeup’ which seem to have anything to do with power, and changing these so the device declares itself as ‘not self powered’ and ‘can wake’ hasn’t made any difference to the power mappings.

Does anyone have any idea on this?

Thx

2

Great question. MSDN’s description that “The bus driver gets this information from its parent devnode” is not exactly enlightening, is it. So, an Express device presumably gets this mapping info from PCI.SYS… which gets it from where?

Gosh I miss JakeO answering questions on this list.

Hmmmm… Unusual. Kind of an odd device design. I’ve seen this done, but usually only with prototype hardware (I remember a device that lost its encryption key or something similar if it was powered down). The requirements to keep power on your device during hiber are usually handled from V(aux).

Is this a desktop system you’re talking about or a mobile platform?

I ask because, if you’re talking about a device on a mobile platform, I want to be sure you understand the details of how devices on these platforms work. For example, on mobile platforms you don’t ever see conventional S1/S2/S3/S4.

Peter
OSR
@OSRDrivers

3

Have you read these pages ?

http://msdn.microsoft.com/en-us/library/windows/hardware/ff561058(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/hardware/ff543087(v=vs.85).aspx

4

xxxxx@hotmail.com wrote:

So, power mappings. Filled in by the bus driver, but based on what information? How does it decide the mappings, and what, and where from, is the information it uses?

Some buses get this information from the device itself. USB and
PCIExpress devices both have information in their configuration spaces
that describe their power behavior. The bus driver maps this to the
Windows power states. The power policy owner (usually the function
driver) can override all of that.

What I would like to be able to do is change this to D0 for all states so the device is powered up during suspend and hibernate.

It’s not that simple. When your system goes into hibernate, power is
physically removed. Your driver can claim it is in D0, but unless you
are self-powered, if your bus loses power, you lose power.

These power states are a software convention. They are not instructions
to the hardware. When the system wants to go to S3, it asks each
device’s driver to figure out what it needs to do. The driver then says
“well, for S3, I need to go to D2”. It then does what it needs to do to
transition to D2. But you can’t really ask the PCI driver “put me into
D2”. If all of the drivers have agreed to transition to S3, then the
system will transition to S3.

And changing that state table doesn’t change the behavior of the
function driver. Even if you change all of the S mappings to D0, the
function driver can still say “well, for S3 I need to go to D2”.

Do you control the function driver for this device?

So far from looking at an enumeration there is only ‘self powered’ and ‘remote wakeup’ which seem to have anything to do with power, and changing these so the device declares itself as ‘not self powered’ and ‘can wake’ hasn’t made any difference to the power mappings.

Are you talking about a USB device? The mention of “self powered” makes
me think you might be. If so, then you have even less flexibility. The
USB spec doesn’t have very many externally visible power states. You
have selective suspend, and you have off. The operating system doesn’t
really care about “self powered” vs “not self powered”; all that means
is that your device will still have power when the bus turns off.

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

5

Mr. Sykes: You question intrigued me, so I went off spelunking in the PCI driver. This is always a dangerous and time-consuming thing. I was rewarded for my efforts to find… that “The bus driver gets this information from its parent devnode” – which, you know, we already knew from MSDN.

So, who’s the parent of PCI.SYS… well, it’s ACPI of course. And therein lies the answer. Along the way, I discovered what may be one of THE most interesting and definitive write-ups on this topic that I’ve seen… well, I hadn’t seen it before today, but I’ve seen it now:

http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ACPI_SxD.rtf

For the archives, when the above link does not work, try searching “ACPI_SxD.RTF” – very interesting stuff, and clearly the genesis of many of the comments in MSDN on this topic.

Note the “rules” presented… and note how ACPI determines the capabilities.

Now… I suspect this does exactly nothing to help you with you actual situation. But, at least this should give you a clue where the mappings originate.

Peter
OSR
@OSRDrivers

6

xxxxx@osr.com wrote:

So, who’s the parent of PCI.SYS… well, it’s ACPI of course. And therein lies the answer. Along the way, I discovered what may be one of THE most interesting and definitive write-ups on this topic that I’ve seen… well, I hadn’t seen it before today, but I’ve seen it now:

http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ACPI_SxD.rtf

For the archives, when the above link does not work, try searching “ACPI_SxD.RTF” – very interesting stuff, and clearly the genesis of many of the comments in MSDN on this topic.

It was interesting to me to see that the D3Cold concept was mentioned
clear back in 1999. I thought that a much more recent innovation.

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

7

Ah! Yes, this struck me as well.

Given that there was certainly no D3(Cold) support in Windows prior to Windows 8, this made me question SOME of the things that were written in the document… I wonder if it was written as a spec, prior to all the issues with supporting D3(Cold) for devices being fleshed out. I certainly don’t know.

I used the term “definitive” in my earlier post, and I don’t think that was well chosen, given that I can’t vouch for how accurate this 15 year old document is. But I *can* say that, as far as I can tell, a device enumerated by PCI gets its power capabilities settings from its parent the PCI bus (just as is documented). And, without a long detailed study of the code, the PCI bus appears to get its power capabilities from ACPI. And that make sense to me and the document I cited seems to confirm this.

Peter
OSR
@OSRDrivers