From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express
Base Specification 4.0. It is designed for root complex applications and
features a single-lane (x1) implementation. Add documentation for it.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
Changes in v3:
- collected tags
- updated the flags of ranges property from example
Changes in v2:
- update the interrupt names by dropping "int" and "rc" string; due
to this the patch description was adjusted
- added "interrupt-controller" and made it mandatory
- s/clkl1pm/pm/g
- dropped the legacy-interrupt-controller node; with this the gic
interrupt controller node was dropped as well as it is not needed
anymore
- updated interrupt-map in example and added interrupt-controller
- added clock-names as required property as the pm clock is not
handled though PM domains; this will allow the driver to have
the option to request the pm clock by its name when implementation
will be adjusted to used the pm clock
- adjusted the size of dma-ranges to reflect the usage on
SMARC module board
- moved "renesas,sysc" at the end of the node in example to align
with dts coding style
.../pci/renesas,r9a08g045s33-pcie.yaml | 202 ++++++++++++++++++
1 file changed, 202 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml
diff --git a/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml
new file mode 100644
index 000000000000..42a9494c96c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml
@@ -0,0 +1,202 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/renesas,r9a08g045s33-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G3S PCIe host controller
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
+
+description:
+ Renesas RZ/G3S PCIe host controller complies with PCIe Base Specification
+ 4.0 and supports up to 5 GT/s (Gen2).
+
+properties:
+ compatible:
+ const: renesas,r9a08g045s33-pcie # RZ/G3S
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: System error interrupt
+ - description: System error on correctable error interrupt
+ - description: System error on non-fatal error interrupt
+ - description: System error on fatal error interrupt
+ - description: AXI error interrupt
+ - description: INTA interrupt
+ - description: INTB interrupt
+ - description: INTC interrupt
+ - description: INTD interrupt
+ - description: MSI interrupt
+ - description: Link bandwidth interrupt
+ - description: PME interrupt
+ - description: DMA interrupt
+ - description: PCIe event interrupt
+ - description: Message interrupt
+ - description: All interrupts
+
+ interrupt-names:
+ items:
+ - description: serr
+ - description: ser_cor
+ - description: serr_nonfatal
+ - description: serr_fatal
+ - description: axi_err
+ - description: inta
+ - description: intb
+ - description: intc
+ - description: intd
+ - description: msi
+ - description: link_bandwidth
+ - description: pm_pme
+ - description: dma
+ - description: pcie_evt
+ - description: msg
+ - description: all
+
+ interrupt-controller: true
+
+ clocks:
+ items:
+ - description: System clock
+ - description: PM control clock
+
+ clock-names:
+ items:
+ - description: aclk
+ - description: pm
+
+ resets:
+ items:
+ - description: AXI2PCIe Bridge reset
+ - description: Data link layer/transaction layer reset
+ - description: Transaction layer (ACLK domain) reset
+ - description: Transaction layer (PCLK domain) reset
+ - description: Physical layer reset
+ - description: Configuration register reset
+ - description: Configuration register reset
+
+ reset-names:
+ items:
+ - description: aresetn
+ - description: rst_b
+ - description: rst_gp_b
+ - description: rst_ps_b
+ - description: rst_rsm_b
+ - description: rst_cfg_b
+ - description: rst_load_b
+
+ power-domains:
+ maxItems: 1
+
+ dma-ranges:
+ description:
+ A single range for the inbound memory region.
+ maxItems: 1
+
+ renesas,sysc:
+ description: System controller phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ vendor-id:
+ const: 0x1912
+
+ device-id:
+ const: 0x0033
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - interrupts
+ - interrupt-names
+ - interrupt-map
+ - interrupt-map-mask
+ - interrupt-controller
+ - power-domains
+ - "#address-cells"
+ - "#size-cells"
+ - "#interrupt-cells"
+ - renesas,sysc
+ - vendor-id
+ - device-id
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a08g045-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@11e40000 {
+ compatible = "renesas,r9a08g045s33-pcie";
+ reg = <0 0x11e40000 0 0x10000>;
+ ranges = <0x02000000 0 0x30000000 0 0x30000000 0 0x8000000>;
+ dma-ranges = <0x42000000 0 0x48000000 0 0x48000000 0 0x38000000>;
+ bus-range = <0x0 0xff>;
+ clocks = <&cpg CPG_MOD R9A08G045_PCI_ACLK>,
+ <&cpg CPG_MOD R9A08G045_PCI_CLKL1PM>;
+ clock-names = "aclk", "pm";
+ resets = <&cpg R9A08G045_PCI_ARESETN>,
+ <&cpg R9A08G045_PCI_RST_B>,
+ <&cpg R9A08G045_PCI_RST_GP_B>,
+ <&cpg R9A08G045_PCI_RST_PS_B>,
+ <&cpg R9A08G045_PCI_RST_RSM_B>,
+ <&cpg R9A08G045_PCI_RST_CFG_B>,
+ <&cpg R9A08G045_PCI_RST_LOAD_B>;
+ reset-names = "aresetn", "rst_b", "rst_gp_b", "rst_ps_b",
+ "rst_rsm_b", "rst_cfg_b", "rst_load_b";
+ interrupts = <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "serr", "serr_cor", "serr_nonfatal",
+ "serr_fatal", "axi_err", "inta",
+ "intb", "intc", "intd", "msi",
+ "link_bandwidth", "pm_pme", "dma",
+ "pcie_evt", "msg", "all";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie 0 0 0 0>, /* INT A */
+ <0 0 0 2 &pcie 0 0 0 1>, /* INT B */
+ <0 0 0 3 &pcie 0 0 0 2>, /* INT C */
+ <0 0 0 4 &pcie 0 0 0 3>; /* INT D */
+ device_type = "pci";
+ num-lanes = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ power-domains = <&cpg>;
+ vendor-id = <0x1912>;
+ device-id = <0x0033>;
+ renesas,sysc = <&sysc>;
+ };
+ };
+
+...
--
2.43.0On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express
> Base Specification 4.0. It is designed for root complex applications and
> features a single-lane (x1) implementation. Add documentation for it.
> +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml
The "r9a08g045s33" in the filename seems oddly specific. Does it
leave room for descendants of the current chip that will inevitably be
added in the future? Most bindings are named with a fairly generic
family name, e.g., "fsl,layerscape", "hisilicon,kirin", "intel,
keembay", "samsung,exynos", etc.
> +examples:
> + - |
> + #include <dt-bindings/clock/r9a08g045-cpg.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + bus {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pcie@11e40000 {
> + compatible = "renesas,r9a08g045s33-pcie";
> + reg = <0 0x11e40000 0 0x10000>;
> + ranges = <0x02000000 0 0x30000000 0 0x30000000 0 0x8000000>;
> + dma-ranges = <0x42000000 0 0x48000000 0 0x48000000 0 0x38000000>;
> + bus-range = <0x0 0xff>;
> + clocks = <&cpg CPG_MOD R9A08G045_PCI_ACLK>,
> + <&cpg CPG_MOD R9A08G045_PCI_CLKL1PM>;
> + clock-names = "aclk", "pm";
> + resets = <&cpg R9A08G045_PCI_ARESETN>,
> + <&cpg R9A08G045_PCI_RST_B>,
> + <&cpg R9A08G045_PCI_RST_GP_B>,
> + <&cpg R9A08G045_PCI_RST_PS_B>,
> + <&cpg R9A08G045_PCI_RST_RSM_B>,
> + <&cpg R9A08G045_PCI_RST_CFG_B>,
> + <&cpg R9A08G045_PCI_RST_LOAD_B>;
> + reset-names = "aresetn", "rst_b", "rst_gp_b", "rst_ps_b",
> + "rst_rsm_b", "rst_cfg_b", "rst_load_b";
> + interrupts = <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "serr", "serr_cor", "serr_nonfatal",
> + "serr_fatal", "axi_err", "inta",
> + "intb", "intc", "intd", "msi",
> + "link_bandwidth", "pm_pme", "dma",
> + "pcie_evt", "msg", "all";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &pcie 0 0 0 0>, /* INT A */
> + <0 0 0 2 &pcie 0 0 0 1>, /* INT B */
> + <0 0 0 3 &pcie 0 0 0 2>, /* INT C */
> + <0 0 0 4 &pcie 0 0 0 3>; /* INT D */
The spec styles these closed up: "INTA", "INTB", etc.
> + device_type = "pci";
> + num-lanes = <1>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + power-domains = <&cpg>;
> + vendor-id = <0x1912>;
> + device-id = <0x0033>;
Some of this is specific to a Root Port, not to the Root Complex as a
whole. E.g., device-type = "pci", num-lanes, vendor-id, device-id,
are Root Port properties. Some of the resets, clocks, and interrupts
might be as well.
I really want to separate those out because even though this
particular version of this PCIe controller only supports a single Root
Port, there are other controllers (and possibly future iterations of
this controller) that support multiple Root Ports, and it makes
maintenance easier if the DT bindings and the driver structures are
similar.
This email includes pointers to sample DT bindings and driver code
that is structured to allow multiple Root Ports:
https://lore.kernel.org/linux-pci/20250625221653.GA1590146@bhelgaas/
Bjorn
Hi, Bjorn,
On 08.07.2025 19:34, Bjorn Helgaas wrote:
> On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express
>> Base Specification 4.0. It is designed for root complex applications and
>> features a single-lane (x1) implementation. Add documentation for it.
>
>> +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml
>
> The "r9a08g045s33" in the filename seems oddly specific. Does it
> leave room for descendants of the current chip that will inevitably be
> added in the future? Most bindings are named with a fairly generic
> family name, e.g., "fsl,layerscape", "hisilicon,kirin", "intel,
> keembay", "samsung,exynos", etc.
>
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/r9a08g045-cpg.h>
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +
>> + bus {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + pcie@11e40000 {
>> + compatible = "renesas,r9a08g045s33-pcie";
>> + reg = <0 0x11e40000 0 0x10000>;
>> + ranges = <0x02000000 0 0x30000000 0 0x30000000 0 0x8000000>;
>> + dma-ranges = <0x42000000 0 0x48000000 0 0x48000000 0 0x38000000>;
>> + bus-range = <0x0 0xff>;
>> + clocks = <&cpg CPG_MOD R9A08G045_PCI_ACLK>,
>> + <&cpg CPG_MOD R9A08G045_PCI_CLKL1PM>;
>> + clock-names = "aclk", "pm";
>> + resets = <&cpg R9A08G045_PCI_ARESETN>,
>> + <&cpg R9A08G045_PCI_RST_B>,
>> + <&cpg R9A08G045_PCI_RST_GP_B>,
>> + <&cpg R9A08G045_PCI_RST_PS_B>,
>> + <&cpg R9A08G045_PCI_RST_RSM_B>,
>> + <&cpg R9A08G045_PCI_RST_CFG_B>,
>> + <&cpg R9A08G045_PCI_RST_LOAD_B>;
>> + reset-names = "aresetn", "rst_b", "rst_gp_b", "rst_ps_b",
>> + "rst_rsm_b", "rst_cfg_b", "rst_load_b";
>> + interrupts = <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "serr", "serr_cor", "serr_nonfatal",
>> + "serr_fatal", "axi_err", "inta",
>> + "intb", "intc", "intd", "msi",
>> + "link_bandwidth", "pm_pme", "dma",
>> + "pcie_evt", "msg", "all";
>> + #interrupt-cells = <1>;
>> + interrupt-controller;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &pcie 0 0 0 0>, /* INT A */
>> + <0 0 0 2 &pcie 0 0 0 1>, /* INT B */
>> + <0 0 0 3 &pcie 0 0 0 2>, /* INT C */
>> + <0 0 0 4 &pcie 0 0 0 3>; /* INT D */
>
> The spec styles these closed up: "INTA", "INTB", etc.
I'll update it.
>
>> + device_type = "pci";
>> + num-lanes = <1>;
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + power-domains = <&cpg>;
>> + vendor-id = <0x1912>;
>> + device-id = <0x0033>;
>
> Some of this is specific to a Root Port, not to the Root Complex as a
> whole. E.g., device-type = "pci", num-lanes, vendor-id, device-id,
> are Root Port properties. Some of the resets, clocks, and interrupts
> might be as well.
>
> I really want to separate those out because even though this
> particular version of this PCIe controller only supports a single Root
> Port, there are other controllers (and possibly future iterations of
> this controller) that support multiple Root Ports, and it makes
> maintenance easier if the DT bindings and the driver structures are
> similar.
I'll ask the Renesas HW team about the resets and clocks as the HW manual
don't offer any information about this.
If they will confirm some of the clocks and/or resets could be controlled
as part of a port then patch 3/9 "PCI: of_property: Restore the arguments
of the next level parent" in this series will not be needed anymore. Would
you prefer me to abandon it or post it as individual patch, if any?
>
> This email includes pointers to sample DT bindings and driver code
> that is structured to allow multiple Root Ports:
>
> https://lore.kernel.org/linux-pci/20250625221653.GA1590146@bhelgaas/
Thank you for this!
And, thank you for your review,
Claudiu
>
> Bjorn
Hi, Bjorn,
On 8/8/25 14:25, Claudiu Beznea wrote:
> Hi, Bjorn,
>
> On 08.07.2025 19:34, Bjorn Helgaas wrote:
>> On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote:
>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>
>>> The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express
>>> Base Specification 4.0. It is designed for root complex applications and
>>> features a single-lane (x1) implementation. Add documentation for it.
>>
>>> +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml
>>
>> The "r9a08g045s33" in the filename seems oddly specific. Does it
>> leave room for descendants of the current chip that will inevitably be
>> added in the future? Most bindings are named with a fairly generic
>> family name, e.g., "fsl,layerscape", "hisilicon,kirin", "intel,
>> keembay", "samsung,exynos", etc.
>>
>>> +examples:
>>> + - |
>>> + #include <dt-bindings/clock/r9a08g045-cpg.h>
>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +
>>> + bus {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> +
>>> + pcie@11e40000 {
>>> + compatible = "renesas,r9a08g045s33-pcie";
>>> + reg = <0 0x11e40000 0 0x10000>;
>>> + ranges = <0x02000000 0 0x30000000 0 0x30000000 0 0x8000000>;
>>> + dma-ranges = <0x42000000 0 0x48000000 0 0x48000000 0 0x38000000>;
>>> + bus-range = <0x0 0xff>;
>>> + clocks = <&cpg CPG_MOD R9A08G045_PCI_ACLK>,
>>> + <&cpg CPG_MOD R9A08G045_PCI_CLKL1PM>;
>>> + clock-names = "aclk", "pm";
>>> + resets = <&cpg R9A08G045_PCI_ARESETN>,
>>> + <&cpg R9A08G045_PCI_RST_B>,
>>> + <&cpg R9A08G045_PCI_RST_GP_B>,
>>> + <&cpg R9A08G045_PCI_RST_PS_B>,
>>> + <&cpg R9A08G045_PCI_RST_RSM_B>,
>>> + <&cpg R9A08G045_PCI_RST_CFG_B>,
>>> + <&cpg R9A08G045_PCI_RST_LOAD_B>;
>>> + reset-names = "aresetn", "rst_b", "rst_gp_b", "rst_ps_b",
>>> + "rst_rsm_b", "rst_cfg_b", "rst_load_b";
>>> + interrupts = <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH>;
>>> + interrupt-names = "serr", "serr_cor", "serr_nonfatal",
>>> + "serr_fatal", "axi_err", "inta",
>>> + "intb", "intc", "intd", "msi",
>>> + "link_bandwidth", "pm_pme", "dma",
>>> + "pcie_evt", "msg", "all";
>>> + #interrupt-cells = <1>;
>>> + interrupt-controller;
>>> + interrupt-map-mask = <0 0 0 7>;
>>> + interrupt-map = <0 0 0 1 &pcie 0 0 0 0>, /* INT A */
>>> + <0 0 0 2 &pcie 0 0 0 1>, /* INT B */
>>> + <0 0 0 3 &pcie 0 0 0 2>, /* INT C */
>>> + <0 0 0 4 &pcie 0 0 0 3>; /* INT D */
>>
>> The spec styles these closed up: "INTA", "INTB", etc.
>
> I'll update it.
>
>>
>>> + device_type = "pci";
>>> + num-lanes = <1>;
>>> + #address-cells = <3>;
>>> + #size-cells = <2>;
>>> + power-domains = <&cpg>;
>>> + vendor-id = <0x1912>;
>>> + device-id = <0x0033>;
>>
>> Some of this is specific to a Root Port, not to the Root Complex as a
>> whole. E.g., device-type = "pci", num-lanes, vendor-id, device-id,
>> are Root Port properties. Some of the resets, clocks, and interrupts
>> might be as well.
>>
>> I really want to separate those out because even though this
>> particular version of this PCIe controller only supports a single Root
>> Port, there are other controllers (and possibly future iterations of
>> this controller) that support multiple Root Ports, and it makes
>> maintenance easier if the DT bindings and the driver structures are
>> similar.
>
> I'll ask the Renesas HW team about the resets and clocks as the HW manual
> don't offer any information about this.
Renesas HW team replied to me that there are no clock, reset, or interrupt
signals dedicated specifically to the Root Port. All these signals are shared
across the PCIe system.
Taking this and your suggestions into account, I have prepared the following
device tree:
pcie: pcie@11e40000 {
compatible = "renesas,r9a08g045-pcie";
reg = <0 0x11e40000 0 0x10000>;
ranges = <0x02000000 0 0x30000000 0 0x30000000 0 0x8000000>;
/* Map all possible DRAM ranges (4 GB). */
dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0x1 0x0>;
bus-range = <0x0 0xff>;
interrupts = <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "serr", "serr_cor", "serr_nonfatal",
"serr_fatal", "axi_err", "inta",
"intb", "intc", "intd", "msi",
"link_bandwidth", "pm_pme", "dma",
"pcie_evt", "msg", "all";
#interrupt-cells = <1>;
interrupt-controller;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie 0 0 0 0>, /* INTA */
<0 0 0 2 &pcie 0 0 0 1>, /* INTB */
<0 0 0 3 &pcie 0 0 0 2>, /* INTC */
<0 0 0 4 &pcie 0 0 0 3>; /* INTD */
clocks = <&cpg CPG_MOD R9A08G045_PCI_ACLK>,
<&cpg CPG_MOD R9A08G045_PCI_CLKL1PM>;
clock-names = "aclk", "pm";
resets = <&cpg R9A08G045_PCI_ARESETN>,
<&cpg R9A08G045_PCI_RST_B>,
<&cpg R9A08G045_PCI_RST_GP_B>,
<&cpg R9A08G045_PCI_RST_PS_B>,
<&cpg R9A08G045_PCI_RST_RSM_B>,
<&cpg R9A08G045_PCI_RST_CFG_B>,
<&cpg R9A08G045_PCI_RST_LOAD_B>;
reset-names = "aresetn", "rst_b", "rst_gp_b", "rst_ps_b",
"rst_rsm_b", "rst_cfg_b", "rst_load_b";
power-domains = <&cpg>;
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
renesas,sysc = <&sysc>;
status = "disabled";
pcie_port0: pcie@0,0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
ranges;
clocks = <&versa3 5>;
clock-names = "ref";
device_type = "pci";
vendor-id = <0x1912>;
device-id = <0x0033>;
bus-range = <0x1 0xff>;
#address-cells = <3>;
#size-cells = <2>;
};
};
and added clocks in the port section, populated with the reference clock that is
provided by a board specific clock generator (that I failed to noticed
previously on schematics; this clock is always on).
Please let me know if you find something wrong with this format.
Thank you,
Claudiu
>
> If they will confirm some of the clocks and/or resets could be controlled
> as part of a port then patch 3/9 "PCI: of_property: Restore the arguments
> of the next level parent" in this series will not be needed anymore. Would
> you prefer me to abandon it or post it as individual patch, if any?
>
>>
>> This email includes pointers to sample DT bindings and driver code
>> that is structured to allow multiple Root Ports:
>>
>> https://lore.kernel.org/linux-pci/20250625221653.GA1590146@bhelgaas/
>
> Thank you for this!
>
> And, thank you for your review,
> Claudiu
>
>>
>> Bjorn
>
On Thu, Aug 28, 2025 at 10:11:55PM +0300, claudiu beznea wrote:
> On 8/8/25 14:25, Claudiu Beznea wrote:
> > On 08.07.2025 19:34, Bjorn Helgaas wrote:
> > > On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote:
> > > > From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > >
> > > > The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express
> > > > Base Specification 4.0. It is designed for root complex applications and
> > > > features a single-lane (x1) implementation. Add documentation for it.
> ...
> Renesas HW team replied to me that there are no clock, reset, or interrupt
> signals dedicated specifically to the Root Port. All these signals are
> shared across the PCIe system.
>
> Taking this and your suggestions into account, I have prepared the following
> device tree:
>
> pcie: pcie@11e40000 {
> compatible = "renesas,r9a08g045-pcie";
> reg = <0 0x11e40000 0 0x10000>;
> ranges = <0x02000000 0 0x30000000 0 0x30000000 0 0x8000000>;
> /* Map all possible DRAM ranges (4 GB). */
> dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0x1 0x0>;
> bus-range = <0x0 0xff>;
> interrupts = <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "serr", "serr_cor", "serr_nonfatal",
> "serr_fatal", "axi_err", "inta",
> "intb", "intc", "intd", "msi",
> "link_bandwidth", "pm_pme", "dma",
> "pcie_evt", "msg", "all";
> #interrupt-cells = <1>;
> interrupt-controller;
> interrupt-map-mask = <0 0 0 7>;
> interrupt-map = <0 0 0 1 &pcie 0 0 0 0>, /* INTA */
> <0 0 0 2 &pcie 0 0 0 1>, /* INTB */
> <0 0 0 3 &pcie 0 0 0 2>, /* INTC */
> <0 0 0 4 &pcie 0 0 0 3>; /* INTD */
> clocks = <&cpg CPG_MOD R9A08G045_PCI_ACLK>,
> <&cpg CPG_MOD R9A08G045_PCI_CLKL1PM>;
> clock-names = "aclk", "pm";
> resets = <&cpg R9A08G045_PCI_ARESETN>,
> <&cpg R9A08G045_PCI_RST_B>,
> <&cpg R9A08G045_PCI_RST_GP_B>,
> <&cpg R9A08G045_PCI_RST_PS_B>,
> <&cpg R9A08G045_PCI_RST_RSM_B>,
> <&cpg R9A08G045_PCI_RST_CFG_B>,
> <&cpg R9A08G045_PCI_RST_LOAD_B>;
> reset-names = "aresetn", "rst_b", "rst_gp_b", "rst_ps_b",
> "rst_rsm_b", "rst_cfg_b", "rst_load_b";
> power-domains = <&cpg>;
> device_type = "pci";
> #address-cells = <3>;
> #size-cells = <2>;
> renesas,sysc = <&sysc>;
> status = "disabled";
>
> pcie_port0: pcie@0,0 {
> reg = <0x0 0x0 0x0 0x0 0x0>;
> ranges;
> clocks = <&versa3 5>;
> clock-names = "ref";
> device_type = "pci";
> vendor-id = <0x1912>;
> device-id = <0x0033>;
> bus-range = <0x1 0xff>;
I don't think you need this bus-range. The bus range for the
hierarchy below a Root Port is discoverable and configurable via
config space.
> #address-cells = <3>;
> #size-cells = <2>;
> };
> };
Hi, Bjorn,
On 8/28/25 22:36, Bjorn Helgaas wrote:
> On Thu, Aug 28, 2025 at 10:11:55PM +0300, claudiu beznea wrote:
>> On 8/8/25 14:25, Claudiu Beznea wrote:
>>> On 08.07.2025 19:34, Bjorn Helgaas wrote:
>>>> On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote:
>>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>
>>>>> The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express
>>>>> Base Specification 4.0. It is designed for root complex applications and
>>>>> features a single-lane (x1) implementation. Add documentation for it.
>> ...
>
>> Renesas HW team replied to me that there are no clock, reset, or interrupt
>> signals dedicated specifically to the Root Port. All these signals are
>> shared across the PCIe system.
>>
>> Taking this and your suggestions into account, I have prepared the following
>> device tree:
>>
>> pcie: pcie@11e40000 {
>> compatible = "renesas,r9a08g045-pcie";
>> reg = <0 0x11e40000 0 0x10000>;
>> ranges = <0x02000000 0 0x30000000 0 0x30000000 0 0x8000000>;
>> /* Map all possible DRAM ranges (4 GB). */
>> dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0x1 0x0>;
>> bus-range = <0x0 0xff>;
>> interrupts = <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH>;
>> interrupt-names = "serr", "serr_cor", "serr_nonfatal",
>> "serr_fatal", "axi_err", "inta",
>> "intb", "intc", "intd", "msi",
>> "link_bandwidth", "pm_pme", "dma",
>> "pcie_evt", "msg", "all";
>> #interrupt-cells = <1>;
>> interrupt-controller;
>> interrupt-map-mask = <0 0 0 7>;
>> interrupt-map = <0 0 0 1 &pcie 0 0 0 0>, /* INTA */
>> <0 0 0 2 &pcie 0 0 0 1>, /* INTB */
>> <0 0 0 3 &pcie 0 0 0 2>, /* INTC */
>> <0 0 0 4 &pcie 0 0 0 3>; /* INTD */
>> clocks = <&cpg CPG_MOD R9A08G045_PCI_ACLK>,
>> <&cpg CPG_MOD R9A08G045_PCI_CLKL1PM>;
>> clock-names = "aclk", "pm";
>> resets = <&cpg R9A08G045_PCI_ARESETN>,
>> <&cpg R9A08G045_PCI_RST_B>,
>> <&cpg R9A08G045_PCI_RST_GP_B>,
>> <&cpg R9A08G045_PCI_RST_PS_B>,
>> <&cpg R9A08G045_PCI_RST_RSM_B>,
>> <&cpg R9A08G045_PCI_RST_CFG_B>,
>> <&cpg R9A08G045_PCI_RST_LOAD_B>;
>> reset-names = "aresetn", "rst_b", "rst_gp_b", "rst_ps_b",
>> "rst_rsm_b", "rst_cfg_b", "rst_load_b";
>> power-domains = <&cpg>;
>> device_type = "pci";
>> #address-cells = <3>;
>> #size-cells = <2>;
>> renesas,sysc = <&sysc>;
>> status = "disabled";
>>
>> pcie_port0: pcie@0,0 {
>> reg = <0x0 0x0 0x0 0x0 0x0>;
>> ranges;
>> clocks = <&versa3 5>;
>> clock-names = "ref";
>> device_type = "pci";
>> vendor-id = <0x1912>;
>> device-id = <0x0033>;
>> bus-range = <0x1 0xff>;
>
> I don't think you need this bus-range. The bus range for the
> hierarchy below a Root Port is discoverable and configurable via
> config space.
Thank you for the pointer. I'll update and send a new version.
Claudiu
On Fri, Aug 08, 2025 at 02:25:42PM +0300, Claudiu Beznea wrote:
> On 08.07.2025 19:34, Bjorn Helgaas wrote:
> > On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote:
> >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>
> >> The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express
> >> Base Specification 4.0. It is designed for root complex applications and
> >> features a single-lane (x1) implementation. Add documentation for it.
> >
> >> +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml
> >> + pcie@11e40000 {
> >> + compatible = "renesas,r9a08g045s33-pcie";
> >> + reg = <0 0x11e40000 0 0x10000>;
> >> + ranges = <0x02000000 0 0x30000000 0 0x30000000 0 0x8000000>;
> >> + dma-ranges = <0x42000000 0 0x48000000 0 0x48000000 0 0x38000000>;
> >> + bus-range = <0x0 0xff>;
> ...
> >> + device_type = "pci";
> >> + num-lanes = <1>;
> >> + #address-cells = <3>;
> >> + #size-cells = <2>;
> >> + power-domains = <&cpg>;
> >> + vendor-id = <0x1912>;
> >> + device-id = <0x0033>;
> >
> > Some of this is specific to a Root Port, not to the Root Complex
> > as a whole. E.g., device-type = "pci", num-lanes, vendor-id,
> > device-id, are Root Port properties. Some of the resets, clocks,
> > and interrupts might be as well.
> >
> > I really want to separate those out because even though this
> > particular version of this PCIe controller only supports a single
> > Root Port, there are other controllers (and possibly future
> > iterations of this controller) that support multiple Root Ports,
> > and it makes maintenance easier if the DT bindings and the driver
> > structures are similar.
>
> I'll ask the Renesas HW team about the resets and clocks as the HW
> manual don't offer any information about this.
>
> If they will confirm some of the clocks and/or resets could be
> controlled as part of a port then patch 3/9 "PCI: of_property:
> Restore the arguments of the next level parent" in this series will
> not be needed anymore. Would you prefer me to abandon it or post it
> as individual patch, if any?
[PATCH v3 3/9] ("PCI: of_property: Restore the arguments of the next
level parent") isn't specific to Renesas RZ/G3S and it doesn't look
like it has anything to do with clocks or resets. I don't understand
the patch well enough to know whether you should keep it, but it does
look like you should post it separate from the RZ/G3S driver.
When the devicetree contains required information specific to Root
Ports, I would prefer that to be in a separate "pcie@x,y" stanza, even
if there are clocks or resets that apply to all Root Ports.
"num-lanes" is obviously specific to an individual Root Port because
a Root Complex doesn't have lanes at all. But in the case of RZ/G3S,
I'm not sure "num-lanes" is required in the devicetree; I don't see it
being used in the driver. If it's not needed, I would just omit it.
It looks like the driver *does* need "vendor-id" and "device-id"
though, and those also are specific to a Root Port because a Root
Complex is not a PCI device and doesn't have its own Vendor or Device
ID. So I would like them to be in a per-Root Port stanza. If there
are resets or clocks that affect a Root Port but not the Root Complex
as a whole, they should also be in the Root Port stanza.
Bjorn
On 08/07/2025 18:34, Bjorn Helgaas wrote: > On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote: >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> >> >> The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express >> Base Specification 4.0. It is designed for root complex applications and >> features a single-lane (x1) implementation. Add documentation for it. > >> +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml > > The "r9a08g045s33" in the filename seems oddly specific. Does it > leave room for descendants of the current chip that will inevitably be > added in the future? Most bindings are named with a fairly generic > family name, e.g., "fsl,layerscape", "hisilicon,kirin", "intel, > keembay", "samsung,exynos", etc. > Bindings should be named by compatible, not in a generic way, so name is correct. It can always grow with new compatibles even if name matches old one, it's not a problem. Best regards, Krzysztof
On Wed, Jul 09, 2025 at 08:47:05AM +0200, Krzysztof Kozlowski wrote: > On 08/07/2025 18:34, Bjorn Helgaas wrote: > > On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote: > >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> > >> > >> The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express > >> Base Specification 4.0. It is designed for root complex applications and > >> features a single-lane (x1) implementation. Add documentation for it. > > > >> +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml > > > > The "r9a08g045s33" in the filename seems oddly specific. Does it > > leave room for descendants of the current chip that will inevitably be > > added in the future? Most bindings are named with a fairly generic > > family name, e.g., "fsl,layerscape", "hisilicon,kirin", "intel, > > keembay", "samsung,exynos", etc. > > > > Bindings should be named by compatible, not in a generic way, so name is > correct. It can always grow with new compatibles even if name matches > old one, it's not a problem. Ok, thanks! I guess that means I'm casting shade on the "r9a08g045s33" compatible. I suppose it means something to somebody. Bjorn
On 09/07/2025 15:24, Bjorn Helgaas wrote: > On Wed, Jul 09, 2025 at 08:47:05AM +0200, Krzysztof Kozlowski wrote: >> On 08/07/2025 18:34, Bjorn Helgaas wrote: >>> On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote: >>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> >>>> >>>> The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express >>>> Base Specification 4.0. It is designed for root complex applications and >>>> features a single-lane (x1) implementation. Add documentation for it. >>> >>>> +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml >>> >>> The "r9a08g045s33" in the filename seems oddly specific. Does it >>> leave room for descendants of the current chip that will inevitably be >>> added in the future? Most bindings are named with a fairly generic >>> family name, e.g., "fsl,layerscape", "hisilicon,kirin", "intel, >>> keembay", "samsung,exynos", etc. >>> >> >> Bindings should be named by compatible, not in a generic way, so name is >> correct. It can always grow with new compatibles even if name matches >> old one, it's not a problem. > > Ok, thanks! > > I guess that means I'm casting shade on the "r9a08g045s33" compatible. > I suppose it means something to somebody. Well, I hope it matches the name of the SoC, from which the compatible should come :) Best regards, Krzysztof
Hi, all, Apologies for the late reply. On 09.07.2025 16:43, Krzysztof Kozlowski wrote: > On 09/07/2025 15:24, Bjorn Helgaas wrote: >> On Wed, Jul 09, 2025 at 08:47:05AM +0200, Krzysztof Kozlowski wrote: >>> On 08/07/2025 18:34, Bjorn Helgaas wrote: >>>> On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote: >>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> >>>>> >>>>> The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express >>>>> Base Specification 4.0. It is designed for root complex applications and >>>>> features a single-lane (x1) implementation. Add documentation for it. >>>> >>>>> +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml >>>> >>>> The "r9a08g045s33" in the filename seems oddly specific. Does it >>>> leave room for descendants of the current chip that will inevitably be >>>> added in the future? Most bindings are named with a fairly generic >>>> family name, e.g., "fsl,layerscape", "hisilicon,kirin", "intel, >>>> keembay", "samsung,exynos", etc. >>>> >>> >>> Bindings should be named by compatible, not in a generic way, so name is >>> correct. It can always grow with new compatibles even if name matches >>> old one, it's not a problem. >> >> Ok, thanks! >> >> I guess that means I'm casting shade on the "r9a08g045s33" compatible. >> I suppose it means something to somebody. > > Well, I hope it matches the name of the SoC, from which the compatible > should come :) The r9a08g45s33 is the part number of a device from the RZ/G3S group. This particular device from RZ/G3S group supports PCIe. In the RZ/G3S group there are more SoC variants (each with its own part number). Not all support PCIe. To differentiate b/w PCIe and non-PCIe variants it has been chosen to use the full part number here. The available RZ/G3S part numbers are listed in Table 1.1 Product Lineup at [1] (The following steps should be followed to access the manual: 1/ Click the "User Manual" button 2/ Click "Confirm"; this will start downloading an archive 3/ Open the downloaded archive 4/ Navigate to r01uh1014ej*-rzg3s-users-manual-hardware -> Deliverables 5/ Open the file r01uh1014ej*-rzg3s.pdf) We use a similar compatible scheme in other drivers. Geert, I may be wrong. Please correct me otherwise, as I don't have the full picture of this. Maybe, the other variant would be to use "renesas,rzg3s-pcie", or maybe a more generic one "renesas,rz-pcie" (though I think this last one is too generic). Geert, please let us know if you have some suggestions here with regards to the compatible. The IP on RZ/G3S is compatible also with the one in RZ/V2H, RZ/G3E. Thank you, Claudiu [1] https://www.renesas.com/en/products/rz-g3s?queryID=695cc067c2d89e3f271d43656ede4d12 > > Best regards, > Krzysztof
Hi Claudiu,
On Fri, 8 Aug 2025 at 13:44, Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> On 09.07.2025 16:43, Krzysztof Kozlowski wrote:
> > On 09/07/2025 15:24, Bjorn Helgaas wrote:
> >> On Wed, Jul 09, 2025 at 08:47:05AM +0200, Krzysztof Kozlowski wrote:
> >>> On 08/07/2025 18:34, Bjorn Helgaas wrote:
> >>>> On Fri, Jul 04, 2025 at 07:14:04PM +0300, Claudiu wrote:
> >>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>>>
> >>>>> The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express
> >>>>> Base Specification 4.0. It is designed for root complex applications and
> >>>>> features a single-lane (x1) implementation. Add documentation for it.
> >>>>
> >>>>> +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045s33-pcie.yaml
> >>>>
> >>>> The "r9a08g045s33" in the filename seems oddly specific. Does it
> >>>> leave room for descendants of the current chip that will inevitably be
> >>>> added in the future? Most bindings are named with a fairly generic
> >>>> family name, e.g., "fsl,layerscape", "hisilicon,kirin", "intel,
> >>>> keembay", "samsung,exynos", etc.
> >>>>
> >>>
> >>> Bindings should be named by compatible, not in a generic way, so name is
> >>> correct. It can always grow with new compatibles even if name matches
> >>> old one, it's not a problem.
> >>
> >> Ok, thanks!
> >>
> >> I guess that means I'm casting shade on the "r9a08g045s33" compatible.
> >> I suppose it means something to somebody.
> >
> > Well, I hope it matches the name of the SoC, from which the compatible
> > should come :)
>
> The r9a08g45s33 is the part number of a device from the RZ/G3S group. This
> particular device from RZ/G3S group supports PCIe.
>
> In the RZ/G3S group there are more SoC variants (each with its own part
> number). Not all support PCIe. To differentiate b/w PCIe and non-PCIe
> variants it has been chosen to use the full part number here.
>
> The available RZ/G3S part numbers are listed in Table 1.1 Product Lineup at [1]
>
> (The following steps should be followed to access the manual:
> 1/ Click the "User Manual" button
> 2/ Click "Confirm"; this will start downloading an archive
> 3/ Open the downloaded archive
> 4/ Navigate to r01uh1014ej*-rzg3s-users-manual-hardware -> Deliverables
> 5/ Open the file r01uh1014ej*-rzg3s.pdf)
>
> We use a similar compatible scheme in other drivers.
>
> Geert, I may be wrong. Please correct me otherwise, as I don't have the
> full picture of this.
>
> Maybe, the other variant would be to use "renesas,rzg3s-pcie", or maybe a
> more generic one "renesas,rz-pcie" (though I think this last one is too
> generic).
Both would be too generic for the myriad of RZ devices.
AFAIU, the R9A08G045Sxx variants are really the same SoC, with some
hardware modules disabled/nonfunctional. This is typically handled by:
1. Using the base part number (r9a08g045) in the compatible value,
2. Having the device node in the base .dtsi,
3. Deleting nodes in the variant-specific .dtsi file when needed
(see e.g. arch/arm64/boot/dts/renesas/r9a09g047{,e[35]7}.dtsi)
Hence as R9A08G045S13, R9A08G045S17, R9A08G045S33, and
R9A08G045S37 all have PCIe, I think it is more appropriate
to use "renesas,r9a08g045-pcie" as the compatible value than
"renesas,r9a08g045s33-pcie".
> Geert, please let us know if you have some suggestions here with regards to
> the compatible. The IP on RZ/G3S is compatible also with the one in RZ/V2H,
> RZ/G3E.
RZ/V2H and RZ/G3E can use "renesas,r9a09g057-pcie" resp.
"renesas,r9a09g047-pcie", with "renesas,r9a08g045-pcie" as a fallback.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
© 2016 - 2025 Red Hat, Inc.