linux/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml

204 lines
7.6 KiB
YAML
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/snps,dw-pcie-ep.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Synopsys DesignWare PCIe endpoint interface
maintainers:
- Jingoo Han <jingoohan1@gmail.com>
- Gustavo Pimentel <gustavo.pimentel@synopsys.com>
description: |
Synopsys DesignWare PCIe host controller endpoint
# Please create a separate DT-schema for your DWC PCIe Endpoint controller
# and make sure it's assigned with the vendor-specific compatible string.
select:
properties:
compatible:
const: snps,dw-pcie-ep
required:
- compatible
allOf:
- $ref: /schemas/pci/pci-ep.yaml#
- $ref: /schemas/pci/snps,dw-pcie-common.yaml#
properties:
reg:
dt-bindings: PCI: dwc: Add reg/reg-names common properties Even though there is a more-or-less limited set of the CSR spaces can be defined for each DW PCIe controller the generic DT-schema currently doesn't specify much limitations on the reg-space names used for one or another range. In order to prevent the vendor-specific controller schemas further deviation from the generic interface let's fix that by introducing the reg-names definition in the common DW PCIe DT-schemas and preserving the generic "reg" and "reg-names" properties in there. New DW PCIe device DT-bindings are encouraged to use the generic set of the CSR spaces defined in the generic DW PCIe RP/EP DT-bindings, while the already available vendor-specific DT-bindings can still apple the common DT-schemas. Note the number of reg/reg-names items need to be changed in the DW PCIe EP DT-schema since aside with the "dbi" CSRs space these arrays can have "dbi2", "addr_space", "atu", etc ranges. Also note since there are DW PCIe-based vendor-specific DT-bindings with the custom names assigned to the same CSR resources we have no much choice but to add them to the generic DT-schemas in order to have the schemas being applicable for such devices. These names are marked as vendor-specific and should be avoided being used in new bindings in favor of the generic names. Link: https://lore.kernel.org/r/20221113191301.5526-11-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org>
2022-11-13 22:12:51 +03:00
description:
DBI, DBI2 reg-spaces and outbound memory window are required for the
normal controller functioning. iATU memory IO region is also required
if the space is unrolled (IP-core version >= 4.80a).
minItems: 2
maxItems: 7
reg-names:
minItems: 2
maxItems: 7
items:
dt-bindings: PCI: dwc: Add reg/reg-names common properties Even though there is a more-or-less limited set of the CSR spaces can be defined for each DW PCIe controller the generic DT-schema currently doesn't specify much limitations on the reg-space names used for one or another range. In order to prevent the vendor-specific controller schemas further deviation from the generic interface let's fix that by introducing the reg-names definition in the common DW PCIe DT-schemas and preserving the generic "reg" and "reg-names" properties in there. New DW PCIe device DT-bindings are encouraged to use the generic set of the CSR spaces defined in the generic DW PCIe RP/EP DT-bindings, while the already available vendor-specific DT-bindings can still apple the common DT-schemas. Note the number of reg/reg-names items need to be changed in the DW PCIe EP DT-schema since aside with the "dbi" CSRs space these arrays can have "dbi2", "addr_space", "atu", etc ranges. Also note since there are DW PCIe-based vendor-specific DT-bindings with the custom names assigned to the same CSR resources we have no much choice but to add them to the generic DT-schemas in order to have the schemas being applicable for such devices. These names are marked as vendor-specific and should be avoided being used in new bindings in favor of the generic names. Link: https://lore.kernel.org/r/20221113191301.5526-11-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org>
2022-11-13 22:12:51 +03:00
oneOf:
- description:
Basic DWC PCIe controller configuration-space accessible over
the DBI interface. This memory space is either activated with
CDM/ELBI = 0 and CS2 = 0 or is a contiguous memory region
with all spaces. Note iATU/eDMA CSRs are indirectly accessible
via the PL viewports on the DWC PCIe controllers older than
v4.80a.
const: dbi
- description:
Shadow DWC PCIe config-space registers. This space is selected
by setting CDM/ELBI = 0 and CS2 = 1. This is an intermix of
the PCI-SIG PCIe CFG-space with the shadow registers for some
PCI Header space, PCI Standard and Extended Structures. It's
mainly relevant for the end-point controller configuration,
but still there are some shadow registers available for the
Root Port mode too.
const: dbi2
- description:
External Local Bus registers. It's an application-dependent
registers normally defined by the platform engineers. The space
can be selected by setting CDM/ELBI = 1 and CS2 = 0 wires or can
be accessed over some platform-specific means (for instance
as a part of a system controller).
enum: [ elbi, app ]
- description:
iATU/eDMA registers common for all device functions. It's an
unrolled memory space with the internal Address Translation
Unit and Enhanced DMA, which is selected by setting CDM/ELBI = 1
and CS2 = 1. For IP-core releases prior v4.80a, these registers
have been programmed via an indirect addressing scheme using a
set of viewport CSRs mapped into the PL space. Note iATU is
normally mapped to the 0x0 address of this region, while eDMA
is available at 0x80000 base address.
const: atu
- description:
Platform-specific eDMA registers. Some platforms may have eDMA
CSRs mapped in a non-standard base address. The registers offset
can be changed or the MS/LS-bits of the address can be attached
in an additional RTL block before the MEM-IO transactions reach
the DW PCIe slave interface.
const: dma
- description:
PHY/PCS configuration registers. Some platforms can have the
PCS and PHY CSRs accessible over a dedicated memory mapped
region, but mainly these registers are indirectly accessible
either by means of the embedded PHY viewport schema or by some
platform-specific method.
const: phy
- description:
Outbound iATU-capable memory-region which will be used to
generate various application-specific traffic on the PCIe bus
hierarchy. It's usage scenario depends on the endpoint
functionality, for instance it can be used to create MSI(X)
messages.
const: addr_space
- description:
Vendor-specific CSR names. Consider using the generic names above
for new bindings.
oneOf:
- description: See native 'elbi/app' CSR region for details.
enum: [ apb, link, appl ]
dt-bindings: PCI: dwc: Add reg/reg-names common properties Even though there is a more-or-less limited set of the CSR spaces can be defined for each DW PCIe controller the generic DT-schema currently doesn't specify much limitations on the reg-space names used for one or another range. In order to prevent the vendor-specific controller schemas further deviation from the generic interface let's fix that by introducing the reg-names definition in the common DW PCIe DT-schemas and preserving the generic "reg" and "reg-names" properties in there. New DW PCIe device DT-bindings are encouraged to use the generic set of the CSR spaces defined in the generic DW PCIe RP/EP DT-bindings, while the already available vendor-specific DT-bindings can still apple the common DT-schemas. Note the number of reg/reg-names items need to be changed in the DW PCIe EP DT-schema since aside with the "dbi" CSRs space these arrays can have "dbi2", "addr_space", "atu", etc ranges. Also note since there are DW PCIe-based vendor-specific DT-bindings with the custom names assigned to the same CSR resources we have no much choice but to add them to the generic DT-schemas in order to have the schemas being applicable for such devices. These names are marked as vendor-specific and should be avoided being used in new bindings in favor of the generic names. Link: https://lore.kernel.org/r/20221113191301.5526-11-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org>
2022-11-13 22:12:51 +03:00
- description: See native 'atu' CSR region for details.
enum: [ atu_dma ]
allOf:
- contains:
const: dbi
- contains:
const: addr_space
interrupts:
description:
There is no mandatory IRQ signals for the normal controller functioning,
but in addition to the native set the platforms may have a link- or
PM-related IRQs specified.
minItems: 1
maxItems: 20
interrupt-names:
minItems: 1
maxItems: 20
items:
oneOf:
- description:
Controller request to read or write virtual product data
from/to the VPD capability registers.
const: vpd
- description:
Link Equalization Request flag is set in the Link Status 2
register (applicable if the corresponding IRQ is enabled in
the Link Control 3 register).
const: l_eq
- description:
Indicates that the eDMA Tx/Rx transfer is complete or that an
error has occurred on the corresponding channel. eDMA can have
eight Tx (Write) and Rx (Read) eDMA channels thus supporting up
to 16 IRQ signals all together. Write eDMA channels shall go
first in the ordered row as per default edma_int[*] bus setup.
pattern: '^dma([0-9]|1[0-5])?$'
- description:
PCIe protocol correctable error or a Data Path protection
correctable error is detected by the automotive/safety
feature.
const: sft_ce
- description:
Indicates that the internal safety mechanism has detected an
uncorrectable error.
const: sft_ue
- description:
Application-specific IRQ raised depending on the vendor-specific
events basis.
const: app
- description:
Interrupts triggered when the controller itself (in Endpoint mode)
has sent an Assert_INT{A,B,C,D}/Desassert_INT{A,B,C,D} message to
the upstream device.
pattern: "^tx_int(a|b|c|d)$"
- description:
Combined interrupt signal raised when the controller has sent an
Assert_INT{A,B,C,D} message. See "^tx_int(a|b|c|d)$" for details.
const: legacy
- description:
Vendor-specific IRQ names. Consider using the generic names above
for new bindings.
oneOf:
- description: See native "app" IRQ for details
enum: [ intr, sys, pmc, msg, err ]
max-functions:
maximum: 32
required:
- compatible
- reg
- reg-names
dt-bindings: PCI: designware: Fix 'unevaluatedProperties' warnings With 'unevaluatedProperties' support implemented, there's a number of warnings from the Designware PCIe based bindings: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.example.dt.yaml: pcie@1ffc000: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'device_type', 'bus-range', 'ranges', '#interrupt-cells', 'interrupt-map-mask', 'interrupt-map' were unexpected) Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.example.dt.yaml: pcie@1ffc000: Unevaluated properties are not allowed ('clock-names' was unexpected) Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.example.dt.yaml: pcie@f4000000: Unevaluated properties are not allowed ('bus-range', '#address-cells', '#size-cells', 'device_type', 'ranges', 'num-lanes', '#interrupt-cells', 'interrupts', 'interrupt-names', 'interrupt-map-mask', 'interrupt-map', 'clocks', 'clock-names' were unexpected) Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.example.dt.yaml: pcie@f4000000: Unevaluated properties are not allowed ('clock-names' was unexpected) Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.example.dt.yaml: pcie@f5000000: Unevaluated properties are not allowed ('bus-range', '#address-cells', '#size-cells', 'device_type', 'phys', 'ranges', 'num-lanes', '#interrupt-cells', 'interrupts', 'interrupt-names', 'interrupt-map-mask', 'interrupt-map', 'reset-gpios', 'pcie@0,0' were unexpected) Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.example.dt.yaml: pcie@f5000000: Unevaluated properties are not allowed ('phys', 'hisilicon,clken-gpios' were unexpected) Documentation/devicetree/bindings/pci/intel-gw-pcie.example.dt.yaml: pcie@d0e00000: Unevaluated properties are not allowed ('device_type', '#address-cells', '#size-cells', 'linux,pci-domain', 'bus-range', '#interrupt-cells', 'interrupt-map-mask', 'interrupt-map' were unexpected) Documentation/devicetree/bindings/pci/intel-gw-pcie.example.dt.yaml: pcie@d0e00000: Unevaluated properties are not allowed ('resets', 'phys', 'phy-names', 'reset-assert-ms' were unexpected) Documentation/devicetree/bindings/pci/rockchip-dw-pcie.example.dt.yaml: pcie@fe280000: Unevaluated properties are not allowed ('clock-names', 'msi-map', 'phys', 'phy-names', 'power-domains', 'resets', 'reset-names' were unexpected) Documentation/devicetree/bindings/pci/samsung,exynos-pcie.example.dt.yaml: pcie@15700000: Unevaluated properties are not allowed ('#address-cells', '#size-cells', '#interrupt-cells', 'device_type', 'bus-range', 'ranges', 'interrupt-map-mask', 'interrupt-map' were unexpected) Documentation/devicetree/bindings/pci/samsung,exynos-pcie.example.dt.yaml: pcie@15700000: Unevaluated properties are not allowed ('clock-names', 'phys', 'vdd10-supply', 'vdd18-supply' were unexpected) Documentation/devicetree/bindings/pci/sifive,fu740-pcie.example.dt.yaml: pcie@e00000000: Unevaluated properties are not allowed ('#address-cells', '#size-cells', '#interrupt-cells', 'device_type', 'dma-coherent', 'bus-range', 'ranges', 'interrupts', 'interrupt-parent', 'interrupt-map-mask', 'interrupt-map', 'clock-names', 'clocks' were unexpected) Documentation/devicetree/bindings/pci/sifive,fu740-pcie.example.dt.yaml: pcie@e00000000: Unevaluated properties are not allowed ('dma-coherent', 'clock-names', 'resets', 'pwren-gpios' were unexpected) Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.example.dt.yaml: pcie-ep@66000000: Unevaluated properties are not allowed ('clock-names', 'clocks', 'reset-names', 'resets', 'phy-names', 'phys' were unexpected) Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.example.dt.yaml: pcie@28400000: Unevaluated properties are not allowed ('clock-names' was unexpected) Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.example.dt.yaml: pcie@28400000: Unevaluated properties are not allowed ('device_type', 'bus-range', 'num-viewport', '#address-cells', '#size-cells', '#interrupt-cells', 'ranges', 'interrupt-names', 'interrupt-map-mask', 'interrupt-map', 'max-link-speed' were unexpected) The main problem is that snps,dw-pcie.yaml and snps,dw-pcie-ep.yaml shouldn't set 'unevaluatedProperties: false'. Otherwise, bindings that reference them cannot add additional properties. With that addressed, there's a handful of other undocumented properties to add. Cc: Xiaowei Song <songxiaowei@hisilicon.com> Cc: Binghui Wang <wangbinghui@hisilicon.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Greentime Hu <greentime.hu@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: linux-pci@vger.kernel.org Cc: linux-riscv@lists.infradead.org Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211206194426.2470080-1-robh@kernel.org
2021-12-06 13:44:25 -06:00
additionalProperties: true
examples:
- |
pcie-ep@dfd00000 {
compatible = "snps,dw-pcie-ep";
reg = <0xdfc00000 0x0001000>, /* IP registers 1 */
<0xdfc01000 0x0001000>, /* IP registers 2 */
<0xd0000000 0x2000000>; /* Configuration space */
reg-names = "dbi", "dbi2", "addr_space";
interrupts = <23>, <24>;
interrupt-names = "dma0", "dma1";
clocks = <&sys_clk 12>, <&sys_clk 24>;
clock-names = "dbi", "ref";
resets = <&sys_rst 12>, <&sys_rst 24>;
reset-names = "dbi", "phy";
phys = <&pcie_phy0>, <&pcie_phy1>, <&pcie_phy2>, <&pcie_phy3>;
phy-names = "pcie0", "pcie1", "pcie2", "pcie3";
max-link-speed = <3>;
max-functions = /bits/ 8 <4>;
};