I want to reset a specific PCI device in PCH,
because that device have a problem when system is going to sleep mode,
and the problem will be solved if I disable and enable that device in device manager,
therefor, I am right now trying to reset it and make it auto-reinitialized using RW to set its PCI configuration space.
I read the PCI power management specification, it said there are two ways to reset a PCI device, soft reset and #RST(hardware reset)
I met some question about that PCI device as below:
1.Its NO_SOFT_RESET bit in PMCSR is read-only, and it was set to 1,
so the PCI device can’t be internal reset when device power state is from D3hot to D0.
Is there any way to set the NO_SOFT_RESET to 0, even it’s read-only?
2.Right now I don’t know how to signal a #RST for a specific PCI device.
I could be wrong but I don’t think that is possible for a PCI device, only
for PCIE.
Mark Roddy
On Tue, Mar 17, 2015 at 8:45 PM, wrote:
> Hi all, > > I want to reset a specific PCI device in PCH, > because that device have a problem when system is going to sleep mode, > and the problem will be solved if I disable and enable that device in > device manager, > therefor, I am right now trying to reset it and make it auto-reinitialized > using RW to set its PCI configuration space. > > I read the PCI power management specification, it said there are two ways > to reset a PCI device, soft reset and #RST(hardware reset) > > I met some question about that PCI device as below: > 1.Its NO_SOFT_RESET bit in PMCSR is read-only, and it was set to 1, > so the PCI device can’t be internal reset when device power state is from > D3hot to D0. > Is there any way to set the NO_SOFT_RESET to 0, even it’s read-only? > > 2.Right now I don’t know how to signal a #RST for a specific PCI device. > > Thanks in advanced, > DLCU > > — > 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 >
My problem is that the system is not able to get into S0i3 (Connected standby).
The reason I found is because there are some sensors still being subscribed by some app(for retrieving sensor data), so right now I’m trying to force the sensor hub to get into D3hot when the system should get into S0i3.
Is there a safe way to do that?
Btw, I don’t have device driver source code, so I have to use byway(non regular way) to notify the device’s power policy owner to mark the device as idle.
My problem is that the system is not able to get into S0i3 (Connected standby).
The reason I found is because there are some sensors still being subscribed by some app(for retrieving sensor data), so right now I’m trying to force the sensor hub to get into D3hot when the system should get into S0i3.
Is there a safe way to do that?
Absolutely not. It should be obvious that you cannot alter the power
behavior of another device behind its back. When you drop into any
non-D0 state, the device has the potential to lose power, and hence lose
part of its internal state. The driver must be involved in that
process. If the driver knows that the device is in a recoverable state,
then it will report that it is safely idle.
Just because a sensor is subscribed does not mean the device cannot go
idle. Your only recourse here is to complain to the sensor vendor. If
connected standby is ever going to be ubiquitous, sensor vendors need to
be aggressive about following the D3hot procedures. You can’t force
that to happen from the outside.
Btw, I don’t have device driver source code, so I have to use byway(non regular way) to notify the device’s power policy owner to mark the device as idle.
You can’t do that. It’s just that simple.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Venerable MVP Tim,Thank you.
“A KMDF filter driver can indicate that it is the power policy owner for its device by notifying the framework during initialization.” - MSFT WDF page 154.
I saw such sentence in WDF,my understanding is that it is possible to write a kmdf filter driver for specific device and initialize the filter DO as the power policy owner,so that I am able to change the device’s power behavior without having the source code of function driver,I am not sure whether my understanding is correct.
//dlcu
Claiming power policy ownership is a whole stack exercise. If the function driver doesn’t let you take it, your filter can’t take it. The wdf API is just a way to tell wdf that as a filter you have somehow negotiated it away from the current owner
d
Bent from my phone
From: DL CUmailto:xxxxx Sent: ?3/?24/?2015 12:19 AM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: RE: [ntdev] How to signal a soft reset or #RST for a specific PCI device
Venerable MVP Tim, Thank you.
“A KMDF filter driver can indicate that it is the power policy owner for its device by notifying the framework during initialization.” - MSFT WDF page 154.
I saw such sentence in WDF, my understanding is that it is possible to write a kmdf filter driver for specific device and initialize the filter DO as the power policy owner, so that I am able to change the device’s power behavior without having the source code of function driver, I am not sure whether my understanding is correct.
“A KMDF filter driver can indicate that it is the power policy owner
for its device by notifying the framework during initialization.” -
MSFT WDF page 154.
I saw such sentence in WDF,
my understanding is that it is possible to write a kmdf filter driver
for specific device and initialize the filter DO as the power policy
owner,
so that I am able to change the device’s power behavior without having
the source code of function driver,
I am not sure whether my understanding is correct.
But notice this as well:
For each device, one (and only one) of the device’s drivers must be
the device’s /power policy owner/. The power policy owner determines
the appropriate device power state https: for a device and sends requests to the device’s driver stack whenever the device’s power state should change.
So, if the function driver has already claimed to be the power policy owner, you cannot wrestle that away from him. Further, even if you DID force yourself to be the power policy owner, that doesn’t change the practical behavior of the function driver. If the function driver is not prepared for the device to lose power, and you force that to happen, then the device will be broken. Things won’t get saved and restored, because the function driver didn’t know that would be necessary.
– Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.</https:>