On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote:
On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote:
On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote:
Here's another stab at this writeup. I'd appreciate any comments!
Changes from v1 to v2:
- Consumer/Producer is defined for Extended Address Space descriptors; should be ignored for QWord/DWord/Word Address Space descriptors
- New arches may use Extended Address Space descriptors in PNP0A03 for bridge registers, including ECAM (if the arch adds support for this)
- Add more details about MCFG and _CBA (Lv's suggestion)
- Incorporate Rafael's suggestions
Bjorn Helgaas (1): PCI: Add information about describing PCI in ACPI
Documentation/PCI/00-INDEX | 2 Documentation/PCI/acpi-info.txt | 180 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 182 insertions(+) create mode 100644 Documentation/PCI/acpi-info.txt
It's very late in the cycle, but I'm considering trying to squeeze this into v4.9 on the grounds that:
It's only a documentation change and can't break anything, and
Distributing it more widely may help the arm64 firmware ecosystem
But I don't want to disseminate misleading or incorrect information, so if it needs clarification or wordsmithing, or even just maturation, I'll wait until v4.10.
The Consumer/Producer stuff, in particular, doesn't seem 100% settled yet. Your thoughts, and especially your improvements, are welcome!
Well, what's the drawback if it doesn't go into 4.9?
Only that it's not as easily accessible. ARM64 ACPI firmware is brand new. Neither the firmware nor the kernel developers, nor even the hardware designers, have the benefit of all the x86/ia64 history, so I wrote this to try to come to a common understanding of what Linux expects.
The first generation of ARM64 hardware is already in the field, and it has teething problems in hardware, firmware, and kernel. For example, the current MCFG quirk situation: the ECAM hardware doesn't work quite per spec, the ACPI firmware doesn't describe the address space completely, and we don't really have consensus on how the firmware should communicate register space to the kernel.
We're hoping the second generation can fix some of these problems, and I think this is the time to try to influence that.
Bjorn