ACPI parent/child and PoFx

NTDEV
1

I’m running into a condition where after enumeration of a ACPI parent/child pair, the parent is put into D3 upon registering with PoFx and calling PoFxStartDevicePowerManagement().

The child device, however, shares a clock source and during its subsequent enumeration and power up, it receives a D0 while the parent remains in D3.

The article on “Firmware requirements for D3cold” (http://msdn.microsoft.com/en-us/library/windows/hardware/dn605829(v=vs.85).aspx) state:

Parent device

There is no requirement for a parent device to be capable of being power-managed. However, if a parent device is power-managed, Windows never powers down this device if any of its children (dependent devices) are not in D3.
The power rail and clock domain are handled outside of ACPI, but given that the behavior I’m seeing doesn’t follow this statement above, I’m wondering if there is any way to describe this parent/child resource relationship so that the parent remains in D0 (or is brought into D0) when the child is put into D0. I want to avoid a private interface between the device nodes.

2

Great question.

I’m not likely to have the answer, but I’ll try to ask a few questions.

Does the child device specifically have a _DEP directive indicating its dependence on the parent, or are you relying on the implicit dependency of parent/child relations in the ACPI namespace? It shouldn’t NEED it, but it does make me wonder.

More likely: Do both parent and child have _PRx objects, _ON, _OFF, and _STA methods for each of the implemented power states?

Have you tried calling WdfDeviceStopIdle() to prevent the D3 transition?

Is this, perhaps, a device on a system that’s configured for Connected Standby (wait, I think we’re supposed to all say “On Now” instead of Connected Standby or AOAC, isn’t that right)?? Because I’ve seen precisely the behavior you describe in bus driver for a HID device on a misconfigured system that was trying to support Connected Standby. Before you get too excited, we never got the opportunity to root-cause this problem, as the client took their driver and went on about their business before we could look at it.

It’s not much, but it’s all I’ve got in terms of help.

Peter
OSR
@OSRDrivers

3

Thanks Peter -

I verified that _DEP doesn’t impact the power state management in this particular case. And the device power states are not managed by ACPI _PRx objects (e.g. registers for power rails), but PEP.

Anyway, can’t go into much detail on other specifics. The drivers are split between KMDF/KMDF-miniport because of their models making my life in between KMDF and WDM always an interesting space.

Here’s the answer to my immediate problem, a very subtle but important distinction in the documentation:

//
// Per MSDN: http://msdn.microsoft.com/en-us/library/windows/hardware/hh439551(v=vs.85).aspx
//
// If the driver requires a component to be in the active condition immediately
// after power management starts, the driver must explicitly activate the component
// by calling the PoFxActivateComponent routine, and this call must occur after the
// PoFxRegisterDevice call but before the PoFxStartDevicePowerManagement call.
//

I’ve not yet confirmed the D-states through transition after bring-up but the relationship is such that PoFxActivateComponent will be managed in the proper order.

On another note, I started looking at IoInvalidateDeviceRelations() w/ PowerRelations before I found that reference regarding PoFxStartDevicePowerManagement().

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, September 19, 2014 2:54 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ACPI parent/child and PoFx

Great question.

I’m not likely to have the answer, but I’ll try to ask a few questions.

Does the child device specifically have a _DEP directive indicating its dependence on the parent, or are you relying on the implicit dependency of parent/child relations in the ACPI namespace? It shouldn’t NEED it, but it does make me wonder.

More likely: Do both parent and child have _PRx objects, _ON, _OFF, and _STA methods for each of the implemented power states?

Have you tried calling WdfDeviceStopIdle() to prevent the D3 transition?

Is this, perhaps, a device on a system that’s configured for Connected Standby (wait, I think we’re supposed to all say “On Now” instead of Connected Standby or AOAC, isn’t that right)?? Because I’ve seen precisely the behavior you describe in bus driver for a HID device on a misconfigured system that was trying to support Connected Standby. Before you get too excited, we never got the opportunity to root-cause this problem, as the client took their driver and went on about their business before we could look at it.

It’s not much, but it’s all I’ve got in terms of help.

Peter
OSR
@OSRDrivers

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

4

Sigh – this only gets me to the next step and then I don’t want to leave it activated unnecessarily. So I’m back to the parent being put to D3 after the PnP start and the child coming up into D0.

I don’t think this parent/child ACPI relationship is being maintained by the system correctly. FWIW, the children don’t support D3cold so I don’t think that should be part of the issue.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bryan Woodruff
Sent: Friday, September 19, 2014 3:19 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] ACPI parent/child and PoFx

Thanks Peter -

I verified that _DEP doesn’t impact the power state management in this particular case. And the device power states are not managed by ACPI _PRx objects (e.g. registers for power rails), but PEP.

Anyway, can’t go into much detail on other specifics. The drivers are split between KMDF/KMDF-miniport because of their models making my life in between KMDF and WDM always an interesting space.

Here’s the answer to my immediate problem, a very subtle but important distinction in the documentation:

//
// Per MSDN: http://msdn.microsoft.com/en-us/library/windows/hardware/hh439551(v=vs.85).aspx
//
// If the driver requires a component to be in the active condition immediately
// after power management starts, the driver must explicitly activate the component
// by calling the PoFxActivateComponent routine, and this call must occur after the
// PoFxRegisterDevice call but before the PoFxStartDevicePowerManagement call.
//

I’ve not yet confirmed the D-states through transition after bring-up but the relationship is such that PoFxActivateComponent will be managed in the proper order.

On another note, I started looking at IoInvalidateDeviceRelations() w/ PowerRelations before I found that reference regarding PoFxStartDevicePowerManagement().

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, September 19, 2014 2:54 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ACPI parent/child and PoFx

Great question.

I’m not likely to have the answer, but I’ll try to ask a few questions.

Does the child device specifically have a _DEP directive indicating its dependence on the parent, or are you relying on the implicit dependency of parent/child relations in the ACPI namespace? It shouldn’t NEED it, but it does make me wonder.

More likely: Do both parent and child have _PRx objects, _ON, _OFF, and _STA methods for each of the implemented power states?

Have you tried calling WdfDeviceStopIdle() to prevent the D3 transition?

Is this, perhaps, a device on a system that’s configured for Connected Standby (wait, I think we’re supposed to all say “On Now” instead of Connected Standby or AOAC, isn’t that right)?? Because I’ve seen precisely the behavior you describe in bus driver for a HID device on a misconfigured system that was trying to support Connected Standby. Before you get too excited, we never got the opportunity to root-cause this problem, as the client took their driver and went on about their business before we could look at it.

It’s not much, but it’s all I’ve got in terms of help.

Peter
OSR
@OSRDrivers

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

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

5

THAT’s incredibly helpful. Subtle indeed.

Thanks for sharing, Brian!

Peter
OSR
@OSRDrivers