From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
To: Rob Herring <robh+dt@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Cai Huoqing <cai.huoqing@linux.dev>,
Robin Murphy <robin.murphy@arm.com>,
Jingoo Han <jingoohan1@gmail.com>,
Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Cc: "Serge Semin" <Sergey.Semin@baikalelectronics.ru>,
"Serge Semin" <fancer.lancer@gmail.com>,
"Alexey Malahov" <Alexey.Malahov@baikalelectronics.ru>,
"Pavel Parkhomenko" <Pavel.Parkhomenko@baikalelectronics.ru>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Frank Li" <Frank.Li@nxp.com>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
caihuoqing <caihuoqing@baidu.com>,
"Vinod Koul" <vkoul@kernel.org>,
linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v6 10/20] dt-bindings: PCI: dwc: Add reg/reg-names common properties
Date: Mon, 7 Nov 2022 23:49:24 +0300 [thread overview]
Message-ID: <20221107204934.32655-11-Sergey.Semin@baikalelectronics.ru> (raw)
In-Reply-To: <20221107204934.32655-1-Sergey.Semin@baikalelectronics.ru>
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.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
Changelog v3:
- This is a new patch unpinned from the next one:
https://lore.kernel.org/linux-pci/20220503214638.1895-2-Sergey.Semin@baikalelectronics.ru/
by the Rob' request. (@Rob)
- Split up reg-names in the same way as the interrupt-names: common,
Root Port and Endpoint specific names. (@Rob)
- Drop synonymous from the names list since the device schemas create
their own enumerations anyway.
Changelog v5:
- Add platform-specific reg names, but mark them as deprecated.
Changelog v6:
- Move the common reg-names definitions to the RP/EP schemas. Thus drop
the 'definitions' property. (@Rob)
- Drop the 'deprecated' keywords from the vendor-specific names. (@Rob)
---
.../bindings/pci/snps,dw-pcie-common.yaml | 22 +++++
.../bindings/pci/snps,dw-pcie-ep.yaml | 82 +++++++++++++++++--
.../devicetree/bindings/pci/snps,dw-pcie.yaml | 78 ++++++++++++++++--
3 files changed, 169 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
index 4646fb14e817..13c41cd50e54 100644
--- a/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
@@ -17,6 +17,28 @@ description:
select: false
properties:
+ reg:
+ description:
+ DWC PCIe CSR space is normally accessed over the dedicated Data Bus
+ Interface - DBI. In accordance with the reference manual the register
+ configuration space belongs to the Configuration-Dependent Module (CDM)
+ and is split up into several sub-parts Standard PCIe configuration
+ space, Port Logic Registers (PL), Shadow Config-space Registers,
+ iATU/eDMA registers. The particular sub-space is selected by the
+ CDM/ELBI (dbi_cs) and CS2 (dbi_cs2) signals (selector bits). Such
+ configuration provides a flexible interface for the system engineers to
+ either map the particular space at a desired MMIO address or just leave
+ them in a contiguous memory space if pure Native or AXI Bridge DBI access
+ is selected. Note the PCIe CFG-space, PL and Shadow registers are
+ specific for each activated function, while the rest of the sub-spaces
+ are common for all of them (if there are more than one).
+ minItems: 2
+ maxItems: 6
+
+ reg-names:
+ minItems: 2
+ maxItems: 6
+
interrupts:
description:
There are two main sub-blocks which are normally capable of
diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
index 7d3f8fc8b7b4..f4d7eb2dec4d 100644
--- a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
@@ -28,18 +28,86 @@ allOf:
properties:
reg:
- description: |
- It should contain Data Bus Interface (dbi) and config registers for all
- versions.
- For designware core version >= 4.80, it may contain ATU address space.
+ 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: 4
+ maxItems: 5
reg-names:
minItems: 2
- maxItems: 4
+ maxItems: 5
items:
- enum: [dbi, dbi2, config, atu, addr_space, link, atu_dma, appl]
+ 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: [ link, appl ]
+ - description: See native 'atu' CSR region for details.
+ enum: [ atu_dma ]
+ allOf:
+ - contains:
+ const: dbi
+ - contains:
+ const: addr_space
interrupts:
description:
diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
index fa1db57b2b97..59d3bbb5883a 100644
--- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
@@ -28,10 +28,10 @@ allOf:
properties:
reg:
- description: |
- It should contain Data Bus Interface (dbi) and config registers for all
- versions.
- For designware core version >= 4.80, it may contain ATU address space.
+ description:
+ At least DBI reg-space and peripheral devices CFG-space outbound window
+ are required for the normal controller work. iATU memory IO region is
+ also required if the space is unrolled (IP-core version >= 4.80a).
minItems: 2
maxItems: 5
@@ -39,8 +39,74 @@ properties:
minItems: 2
maxItems: 5
items:
- enum: [ dbi, dbi2, config, atu, atu_dma, app, appl, elbi, mgmt, ctrl,
- parf, cfg, link, ulreg, smu, mpu, apb, phy ]
+ 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 access
+ the peripheral PCIe devices configuration space.
+ const: config
+ - 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, mgmt, link, ulreg, appl ]
+ - description: See native 'atu' CSR region for details.
+ enum: [ atu_dma ]
+ - description: Syscon-related CSR regions.
+ enum: [ smu, mpu ]
+ allOf:
+ - contains:
+ const: dbi
+ - contains:
+ const: config
interrupts:
description:
--
2.38.0
next prev parent reply other threads:[~2022-11-07 21:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 20:49 [PATCH v6 00/20] PCI: dwc: Add generic resources and Baikal-T1 support Serge Semin
2022-11-07 20:49 ` [PATCH v6 01/20] dt-bindings: imx6q-pcie: Fix clock names for imx6sx and imx8mq Serge Semin
2022-11-10 21:01 ` Rob Herring
2022-11-11 11:00 ` Serge Semin
2022-11-07 20:49 ` [PATCH v6 02/20] dt-bindings: visconti-pcie: Fix interrupts array max constraints Serge Semin
2022-11-07 20:49 ` [PATCH v6 03/20] dt-bindings: PCI: dwc: Detach common RP/EP DT bindings Serge Semin
2022-11-07 20:49 ` [PATCH v6 04/20] dt-bindings: PCI: dwc: Remove bus node from the examples Serge Semin
2022-11-07 20:49 ` [PATCH v6 05/20] dt-bindings: PCI: dwc: Add phys/phy-names common properties Serge Semin
2022-11-10 21:01 ` Rob Herring
2022-11-07 20:49 ` [PATCH v6 06/20] dt-bindings: PCI: dwc: Add max-link-speed common property Serge Semin
2022-11-07 20:49 ` [PATCH v6 07/20] dt-bindings: PCI: dwc: Apply generic schema for generic device only Serge Semin
2022-11-07 20:49 ` [PATCH v6 08/20] dt-bindings: PCI: dwc: Add max-functions EP property Serge Semin
2022-11-07 20:49 ` [PATCH v6 09/20] dt-bindings: PCI: dwc: Add interrupts/interrupt-names common properties Serge Semin
2022-11-08 12:40 ` Yoshihiro Shimoda
2022-11-08 13:52 ` Serge Semin
2022-11-08 22:32 ` Rob Herring
2022-11-10 12:26 ` Serge Semin
2022-11-10 21:18 ` Rob Herring
2022-11-07 20:49 ` Serge Semin [this message]
2022-11-10 21:22 ` [PATCH v6 10/20] dt-bindings: PCI: dwc: Add reg/reg-names " Rob Herring
2022-11-07 20:49 ` [PATCH v6 11/20] dt-bindings: PCI: dwc: Add clocks/resets " Serge Semin
2022-11-10 21:23 ` Rob Herring
2022-11-11 11:04 ` Serge Semin
2022-11-07 20:49 ` [PATCH v6 12/20] dt-bindings: PCI: dwc: Add dma-coherent property Serge Semin
2022-11-07 20:49 ` [PATCH v6 13/20] dt-bindings: PCI: dwc: Apply common schema to Rockchip DW PCIe nodes Serge Semin
2022-11-07 20:49 ` [PATCH v6 14/20] dt-bindings: PCI: dwc: Add Baikal-T1 PCIe Root Port bindings Serge Semin
2022-11-07 20:49 ` [PATCH v6 15/20] PCI: dwc: Introduce dma-ranges property support for RC-host Serge Semin
2022-11-07 20:49 ` [PATCH v6 16/20] PCI: dwc: Introduce generic controller capabilities interface Serge Semin
2022-11-07 20:49 ` [PATCH v6 17/20] PCI: dwc: Introduce generic resources getter Serge Semin
2022-11-09 2:17 ` Yoshihiro Shimoda
2022-11-10 13:10 ` Serge Semin
2022-11-07 20:49 ` [PATCH v6 18/20] PCI: dwc: Combine iATU detection procedures Serge Semin
2022-11-07 20:49 ` [PATCH v6 19/20] PCI: dwc: Introduce generic platform clocks and resets Serge Semin
2022-11-07 20:49 ` [PATCH v6 20/20] PCI: dwc: Add Baikal-T1 PCIe controller support Serge Semin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221107204934.32655-11-Sergey.Semin@baikalelectronics.ru \
--to=sergey.semin@baikalelectronics.ru \
--cc=Alexey.Malahov@baikalelectronics.ru \
--cc=Frank.Li@nxp.com \
--cc=Pavel.Parkhomenko@baikalelectronics.ru \
--cc=bhelgaas@google.com \
--cc=cai.huoqing@linux.dev \
--cc=caihuoqing@baidu.com \
--cc=devicetree@vger.kernel.org \
--cc=fancer.lancer@gmail.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=manivannan.sadhasivam@linaro.org \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).