From patchwork Thu Nov 17 17:59:38 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 696266 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3tKTVX1bSPz9t0J for ; Fri, 18 Nov 2016 05:02:28 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7Qyn-0001Fm-GJ; Thu, 17 Nov 2016 18:00:09 +0000 Received: from mail.kernel.org ([198.145.29.136]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7Qyh-000118-OO for linux-arm-kernel@lists.infradead.org; Thu, 17 Nov 2016 18:00:05 +0000 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id EE8B020373; Thu, 17 Nov 2016 17:59:40 +0000 (UTC) Received: from localhost (unknown [69.55.156.165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8B0DD200B4; Thu, 17 Nov 2016 17:59:39 +0000 (UTC) Subject: [PATCH] PCI: Add information about describing PCI in ACPI From: Bjorn Helgaas To: linux-pci@vger.kernel.org Date: Thu, 17 Nov 2016 11:59:38 -0600 Message-ID: <20161117175938.17465.45820.stgit@bhelgaas-glaptop.roam.corp.google.com> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, NML_ADSP_CUSTOM_MED, SUSPICIOUS_RECIPS, UNPARSEABLE_RELAY autolearn=no version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161117_100003_878137_D256ED0F X-CRM114-Status: GOOD ( 25.42 ) X-Spam-Score: -2.2 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [198.145.29.136 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 2.5 SUSPICIOUS_RECIPS Similar addresses in recipient list -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.9 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linaro-acpi@lists.linaro.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org Add a writeup about how PCI host bridges should be described in ACPI using PNP0A03/PNP0A08 devices, PNP0C02 devices, and the MCFG table. Signed-off-by: Bjorn Helgaas --- Documentation/PCI/00-INDEX | 2 + Documentation/PCI/acpi-info.txt | 136 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 138 insertions(+) create mode 100644 Documentation/PCI/acpi-info.txt diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX index 147231f..0780280 100644 --- a/Documentation/PCI/00-INDEX +++ b/Documentation/PCI/00-INDEX @@ -1,5 +1,7 @@ 00-INDEX - this file +acpi-info.txt + - info on how PCI host bridges are represented in ACPI MSI-HOWTO.txt - the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ. PCIEBUS-HOWTO.txt diff --git a/Documentation/PCI/acpi-info.txt b/Documentation/PCI/acpi-info.txt new file mode 100644 index 0000000..ccbcfda --- /dev/null +++ b/Documentation/PCI/acpi-info.txt @@ -0,0 +1,136 @@ + ACPI considerations for PCI host bridges + +The basic requirement is that the ACPI namespace should describe +*everything* that consumes address space unless there's another +standard way for the OS to find it [1, 2].  For example, windows that +are forwarded to PCI by a PCI host bridge should be described via ACPI +devices, since the OS can't locate the host bridge by itself.  PCI +devices *below* the host bridge do not need to be described via ACPI, +because the resources they consume are inside the host bridge windows, +and the OS can discover them via the standard PCI enumeration +mechanism (using config accesses to read and size the BARs). + +This ACPI resource description is done via _CRS methods of devices in +the ACPI namespace [2].   _CRS methods are like generalized PCI BARs: +the OS can read _CRS and figure out what resource is being consumed +even if it doesn't have a driver for the device [3].  That's important +because it means an old OS can work correctly even on a system with +new devices unknown to the OS.  The new devices won't do anything, but +the OS can at least make sure no resources conflict with them. + +Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for +reserving address space! The static tables are for things the OS +needs to know early in boot, before it can parse the ACPI namespace. +If a new table is defined, an old OS needs to operate correctly even +though it ignores the table. _CRS allows that because it is generic +and understood by the old OS; a static table does not. + +If the OS is expected to manage an ACPI device, that device will have +a specific _HID/_CID that tells the OS what driver to bind to it, and +the _CRS tells the OS and the driver where the device's registers are. + +PNP0C02 "motherboard" devices are basically a catch-all.  There's no +programming model for them other than "don't use these resources for +anything else."  So any address space that is (1) not claimed by some +other ACPI device and (2) should not be assigned by the OS to +something else, should be claimed by a PNP0C02 _CRS method. + +PCI host bridges are PNP0A03 or PNP0A08 devices.  Their _CRS should +describe all the address space they consume.  In principle, this would +be all the windows they forward down to the PCI bus, as well as the +bridge registers themselves.  The bridge registers include things like +secondary/subordinate bus registers that determine the bus range below +the bridge, window registers that describe the apertures, etc.  These +are all device-specific, non-architected things, so the only way a +PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which +contain the device-specific details.  These bridge registers also +include ECAM space, since it is consumed by the bridge. + +ACPI defined a Producer/Consumer bit that was intended to distinguish +the bridge apertures from the bridge registers [4, 5].  However, +BIOSes didn't use that bit correctly, and the result is that OSes have +to assume that everything in a PCI host bridge _CRS is a window.  That +leaves no way to describe the bridge registers in the PNP0A03/PNP0A08 +device itself. + +The workaround is to describe the bridge registers (including ECAM +space) in PNP0C02 catch-all devices [6].  With the exception of ECAM, +the bridge register space is device-specific anyway, so the generic +PNP0A03/PNP0A08 driver (pci_root.c) has no need to know about it.  For +ECAM, pci_root.c learns about the space from either MCFG or the _CBA +method. + +Note that the PCIe spec actually does require ECAM unless there's a +standard firmware interface for config access, e.g., the ia64 SAL +interface [7]. One reason is that we want a generic host bridge +driver (pci_root.c), and a generic driver requires a generic way to +access config space. + + +[1] ACPI 6.0, sec 6.1: + For any device that is on a non-enumerable type of bus (for + example, an ISA bus), OSPM enumerates the devices' identifier(s) + and the ACPI system firmware must supply an _HID object ... for + each device to enable OSPM to do that. + +[2] ACPI 6.0, sec 3.7: + The OS enumerates motherboard devices simply by reading through + the ACPI Namespace looking for devices with hardware IDs. + + Each device enumerated by ACPI includes ACPI-defined objects in + the ACPI Namespace that report the hardware resources the device + could occupy [_PRS], an object that reports the resources that are + currently used by the device [_CRS], and objects for configuring + those resources [_SRS]. The information is used by the Plug and + Play OS (OSPM) to configure the devices. + +[3] ACPI 6.0, sec 6.2: + OSPM uses device configuration objects to configure hardware + resources for devices enumerated via ACPI. Device configuration + objects provide information about current and possible resource + requirements, the relationship between shared resources, and + methods for configuring hardware resources. + + When OSPM enumerates a device, it calls _PRS to determine the + resource requirements of the device. It may also call _CRS to + find the current resource settings for the device. Using this + information, the Plug and Play system determines what resources + the device should consume and sets those resources by calling the + device’s _SRS control method. + + In ACPI, devices can consume resources (for example, legacy + keyboards), provide resources (for example, a proprietary PCI + bridge), or do both. Unless otherwise specified, resources for a + device are assumed to be taken from the nearest matching resource + above the device in the device hierarchy. + +[4] ACPI 6.0, sec 6.4.3.5.4: + Extended Address Space Descriptor + General Flags: Bit [0] Consumer/Producer: + 1–This device consumes this resource + 0–This device produces and consumes this resource + +[5] ACPI 6.0, sec 19.6.43: + ResourceUsage specifies whether the Memory range is consumed by + this device (ResourceConsumer) or passed on to child devices + (ResourceProducer). If nothing is specified, then + ResourceConsumer is assumed. + +[6] PCI Firmware 3.0, sec 4.1.2: + If the operating system does not natively comprehend reserving the + MMCFG region, the MMCFG region must be reserved by firmware. The + address range reported in the MCFG table or by _CBA method (see + Section 4.1.3) must be reserved by declaring a motherboard + resource. For most systems, the motherboard resource would appear + at the root of the ACPI namespace (under \_SB) in a node with a + _HID of EISAID (PNP0C02), and the resources in this case should + not be claimed in the root PCI bus’s _CRS. The resources can + optionally be returned in Int15 E820 or EFIGetMemoryMap as + reserved memory but must always be reported through ACPI as a + motherboard resource. + +[7] PCI Express 3.0, sec 7.2.2: + For systems that are PC-compatible, or that do not implement a + processor-architecture-specific firmware interface standard that + allows access to the Configuration Space, the ECAM is required as + defined in this section.