linux/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
Rob Herring 6fdc6e23a7 dt-bindings: Add missing 'unevaluatedProperties'
This doesn't yet do anything in the tools, but make it explicit so we can
check either 'unevaluatedProperties' or 'additionalProperties' is present
in schemas.

'unevaluatedProperties' is appropriate when including another schema (via
'$ref') and all possible properties and/or child nodes are not
explicitly listed in the schema with the '$ref'.

This is in preparation to add a meta-schema to check for missing
'unevaluatedProperties' or 'additionalProperties'. This has been a
constant source of review issues.

Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Wolfram Sang <wsa@kernel.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-By: Vinod Koul <vkoul@kernel.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20201005183830.486085-2-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
2020-10-07 11:26:41 -05:00

175 lines
6.1 KiB
YAML

# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic PCI host controller
maintainers:
- Will Deacon <will@kernel.org>
description: |
Firmware-initialised PCI host controllers and PCI emulations, such as the
virtio-pci implementations found in kvmtool and other para-virtualised
systems, do not require driver support for complexities such as regulator
and clock management. In fact, the controller may not even require the
configuration of a control interface by the operating system, instead
presenting a set of fixed windows describing a subset of IO, Memory and
Configuration Spaces.
Configuration Space is assumed to be memory-mapped (as opposed to being
accessed via an ioport) and laid out with a direct correspondence to the
geography of a PCI bus address by concatenating the various components to
form an offset.
For CAM, this 24-bit offset is:
cfg_offset(bus, device, function, register) =
bus << 16 | device << 11 | function << 8 | register
While ECAM extends this by 4 bits to accommodate 4k of function space:
cfg_offset(bus, device, function, register) =
bus << 20 | device << 15 | function << 12 | register
properties:
compatible:
description: Depends on the layout of configuration space (CAM vs ECAM
respectively). May also have more specific compatibles.
oneOf:
- description:
PCIe host controller in Arm Juno based on PLDA XpressRICH3-AXI IP
items:
- const: arm,juno-r1-pcie
- const: plda,xpressrich3-axi
- const: pci-host-ecam-generic
- description: |
ThunderX PCI host controller for pass-1.x silicon
Firmware-initialized PCI host controller to on-chip devices found on
some Cavium ThunderX processors. These devices have ECAM-based config
access, but the BARs are all at fixed addresses. We handle the fixed
addresses by synthesizing Enhanced Allocation (EA) capabilities for
these devices.
const: cavium,pci-host-thunder-ecam
- description:
Cavium ThunderX PEM firmware-initialized PCIe host controller
const: cavium,pci-host-thunder-pem
- description:
HiSilicon Hip06/Hip07 PCIe host bridge in almost-ECAM mode. Some
firmware places the host controller in a mode where it is ECAM
compliant for all devices other than the root complex.
enum:
- hisilicon,hip06-pcie-ecam
- hisilicon,hip07-pcie-ecam
- description: |
In some cases, firmware may already have configured the Synopsys
DesignWare PCIe controller in RC mode with static ATU window mappings
that cover all config, MMIO and I/O spaces in a [mostly] ECAM
compatible fashion. In this case, there is no need for the OS to
perform any low level setup of clocks, PHYs or device registers, nor
is there any reason for the driver to reconfigure ATU windows for
config and/or IO space accesses at runtime.
In cases where the IP was synthesized with a minimum ATU window size
of 64 KB, it cannot be supported by the generic ECAM driver, because
it requires special config space accessors that filter accesses to
device #1 and beyond on the first bus.
items:
- enum:
- marvell,armada8k-pcie-ecam
- socionext,synquacer-pcie-ecam
- const: snps,dw-pcie-ecam
- description:
CAM or ECAM compliant PCI host controllers without any quirks
enum:
- pci-host-cam-generic
- pci-host-ecam-generic
reg:
description:
The Configuration Space base address and size, as accessed from the parent
bus. The base address corresponds to the first bus in the "bus-range"
property. If no "bus-range" is specified, this will be bus 0 (the
default). Some host controllers have a 2nd non-compliant address range,
so 2 entries are allowed.
minItems: 1
maxItems: 2
ranges:
description:
As described in IEEE Std 1275-1994, but must provide at least a
definition of non-prefetchable memory. One or both of prefetchable Memory
and IO Space may also be provided.
minItems: 1
maxItems: 3
dma-coherent: true
required:
- compatible
- reg
- ranges
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
- if:
properties:
compatible:
contains:
const: arm,juno-r1-pcie
then:
required:
- dma-coherent
- if:
properties:
compatible:
not:
contains:
enum:
- cavium,pci-host-thunder-pem
- hisilicon,hip06-pcie-ecam
- hisilicon,hip07-pcie-ecam
then:
properties:
reg:
maxItems: 1
unevaluatedProperties: false
examples:
- |
bus {
#address-cells = <2>;
#size-cells = <2>;
pcie@40000000 {
compatible = "pci-host-cam-generic";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x0 0x1>;
// CPU_PHYSICAL(2) SIZE(2)
reg = <0x0 0x40000000 0x0 0x1000000>;
// BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2)
ranges = <0x01000000 0x0 0x01000000 0x0 0x01000000 0x0 0x00010000>,
<0x02000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>;
#interrupt-cells = <0x1>;
// PCI_DEVICE(3) INT#(1) CONTROLLER(PHANDLE) CONTROLLER_DATA(3)
interrupt-map = < 0x0 0x0 0x0 0x1 &gic 0x0 0x4 0x1>,
< 0x800 0x0 0x0 0x1 &gic 0x0 0x5 0x1>,
<0x1000 0x0 0x0 0x1 &gic 0x0 0x6 0x1>,
<0x1800 0x0 0x0 0x1 &gic 0x0 0x7 0x1>;
// PCI_DEVICE(3) INT#(1)
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
};
};
...