-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
schemas: pci: bridge: Document "supports-d3" property #127
Conversation
There's a reason D3 support cannot be determined through the Power Management Control/Status Register (unlike D1 and D2, which can): It's mandatory for all functions per PCIe r6.1 sec 5.3.1: All Functions must support the D0 and D3 states (both D3Hot and D3Cold). The D1 and D2 states are optional. Unfortunately in practice, for PCIe bridges, D3 is not always supported. Please add the above to the commit message. |
Even though the PCIe spec states that all PCIe devices should support D0 and D3 states (both D3 hot and D3 cold), PCIe bridges do not follow that in practice. Spec r3.0, section 5.3.1: "All Functions must support the D0 and D3 states (both D3 hot and D3 cold ). The D1 and D2 states are optional." Also, unlike D1 and D2, D3 support cannot be determined using the standard Power Management Control/Status (PMCSR) Register. So the OS needs to know the D3 support using platform specific ways. Hence, for DT based platforms, let's add a new property called "supports-d3" that specifies that the PCI bridge is D3 capable. Signed-off-by: Manivannan Sadhasivam <[email protected]>
fc6929f
to
57be7dd
Compare
@l1k Done! |
If the default in the spec is supported, then the property should be to disable it. |
Spec supports it by default, but not all the bridges. That's why the property has to enable it. |
No. Default is D3 supported because the spec says it should be supported, so a property should be a quirk to disable it. |
That wouldn't accurately describe the HW. As you know, PCIe devices have a history of violating specs, so if we add the property based on the spec, then there would be a disconnect w.r.t the implementation. For instance, if we name it |
What's the behavior for a PCI bridge with no firmware node? D3 is disabled? Does this go back to the long standing problem that runtime PM is disabled for PCI? |
Yes, D3 is disabled for the bridge by default. The goal here is to safely enable D3 for capable bridges. |
There is no standard way to detect the D3 support of the PCI-PCI bridges. So let's add a new property, "supports-d3" to specify that the bridge supports transitioning to D3 states.