Document the bindings for STM32MP25 PCIe Controller configured in
root complex mode.
Supports 4 legacy interrupts and MSI interrupts from the ARM
GICv2m controller.
STM32 PCIe may be in a power domain which is the case for the STM32MP25
based boards.
Supports wake# from wake-gpios
Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
---
.../bindings/pci/st,stm32-pcie-common.yaml | 45 +++++++++
.../bindings/pci/st,stm32-pcie-host.yaml | 99 +++++++++++++++++++
2 files changed, 144 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
create mode 100644 Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
new file mode 100644
index 000000000000..479c03134da3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/st,stm32-pcie-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32MP25 PCIe RC/EP controller
+
+maintainers:
+ - Christian Bruel <christian.bruel@foss.st.com>
+
+description:
+ STM32MP25 PCIe RC/EP common properties
+
+properties:
+ clocks:
+ maxItems: 1
+ description: PCIe system clock
+
+ resets:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: pcie-phy
+
+ power-domains:
+ maxItems: 1
+
+ access-controllers:
+ maxItems: 1
+
+ reset-gpios:
+ description: GPIO controlled connection to PERST# signal
+ maxItems: 1
+
+required:
+ - clocks
+ - resets
+ - phys
+ - phy-names
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
new file mode 100644
index 000000000000..18083cc69024
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/st,stm32-pcie-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32MP25 PCIe root complex driver
+
+maintainers:
+ - Christian Bruel <christian.bruel@foss.st.com>
+
+description:
+ PCIe root complex controller based on the Synopsys DesignWare PCIe core.
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie.yaml#
+ - $ref: /schemas/pci/st,stm32-pcie-common.yaml#
+
+select:
+ properties:
+ compatible:
+ const: st,stm32mp25-pcie-rc
+ required:
+ - compatible
+
+properties:
+ compatible:
+ const: st,stm32mp25-pcie-rc
+
+ reg:
+ items:
+ - description: Data Bus Interface (DBI) registers.
+ - description: PCIe configuration registers.
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: config
+
+ num-lanes:
+ const: 1
+
+ msi-parent:
+ maxItems: 1
+
+ wake-gpios:
+ description: GPIO controlled connection to WAKE# input signal
+ maxItems: 1
+
+ wakeup-source: true
+
+dependentRequired:
+ wakeup-source: [ wake-gpios ]
+
+required:
+ - interrupt-map
+ - interrupt-map-mask
+ - ranges
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/phy/phy.h>
+ #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+ pcie@48400000 {
+ compatible = "st,stm32mp25-pcie-rc";
+ device_type = "pci";
+ num-lanes = <1>;
+ reg = <0x48400000 0x400000>,
+ <0x10000000 0x10000>;
+ reg-names = "dbi", "config";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0 0x10010000 0x10010000 0 0x10000>,
+ <0x02000000 0 0x10020000 0x10020000 0 0x7fe0000>,
+ <0x42000000 0 0x18000000 0x18000000 0 0x8000000>;
+ clocks = <&rcc CK_BUS_PCIE>;
+ phys = <&combophy PHY_TYPE_PCIE>;
+ phy-names = "pcie-phy";
+ resets = <&rcc PCIE_R>;
+ msi-parent = <&v2m0>;
+ wakeup-source;
+ wake-gpios = <&gpioh 5 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ reset-gpios = <&gpioj 8 GPIO_ACTIVE_LOW>;
+ access-controllers = <&rifsc 68>;
+ power-domains = <&CLUSTER_PD>;
+ };
+
--
2.34.1On Tue, Nov 26, 2024 at 04:51:15PM +0100, Christian Bruel wrote: > Document the bindings for STM32MP25 PCIe Controller configured in > root complex mode. > ... > + power-domains = <&CLUSTER_PD>; > + }; > + Nit: Applying: dt-bindings: PCI: Add STM32MP25 PCIe root complex bindings .git/rebase-apply/patch:163: new blank line at EOF. + warning: 1 line adds whitespace errors.
On Tue, Nov 26, 2024 at 04:51:15PM +0100, Christian Bruel wrote:
> Document the bindings for STM32MP25 PCIe Controller configured in
> root complex mode.
>
> Supports 4 legacy interrupts and MSI interrupts from the ARM
> GICv2m controller.
s/legacy/INTx/
> STM32 PCIe may be in a power domain which is the case for the STM32MP25
> based boards.
>
> Supports wake# from wake-gpios
s/wake#/WAKE#/
> + wake-gpios:
> + description: GPIO controlled connection to WAKE# input signal
I'm not a hardware guy, but this sounds like a GPIO that *reads*
WAKE#, not controls it.
> + pcie@48400000 {
> + compatible = "st,stm32mp25-pcie-rc";
> + device_type = "pci";
> + num-lanes = <1>;
num-lanes applies to a Root Port, not to a Root Complex. I know most
bindings conflate Root Ports with the Root Complex, maybe because many
of these controllers only support a single Root Port?
But are we ever going to separate these out? I assume someday
controllers will support multiple Root Ports and/or additional devices
on the root bus, like RCiEPs, RCECs, etc., and we'll need per-RP phys,
max-link-speed, num-lanes, reset-gpios, etc.
Seems like it would be to our benefit to split out the Root Ports when
we can, even if the current hardware only supports one, so we can
start untangling the code and data structures.
Bjorn
On Tue, Dec 03, 2024 at 04:25:15PM -0600, Bjorn Helgaas wrote:
> On Tue, Nov 26, 2024 at 04:51:15PM +0100, Christian Bruel wrote:
> > Document the bindings for STM32MP25 PCIe Controller configured in
> > root complex mode.
> >
> > Supports 4 legacy interrupts and MSI interrupts from the ARM
> > GICv2m controller.
>
> s/legacy/INTx/
>
> > STM32 PCIe may be in a power domain which is the case for the STM32MP25
> > based boards.
> >
> > Supports wake# from wake-gpios
>
> s/wake#/WAKE#/
>
> > + wake-gpios:
> > + description: GPIO controlled connection to WAKE# input signal
>
> I'm not a hardware guy, but this sounds like a GPIO that *reads*
> WAKE#, not controls it.
>
> > + pcie@48400000 {
> > + compatible = "st,stm32mp25-pcie-rc";
> > + device_type = "pci";
> > + num-lanes = <1>;
>
> num-lanes applies to a Root Port, not to a Root Complex. I know most
> bindings conflate Root Ports with the Root Complex, maybe because many
> of these controllers only support a single Root Port?
>
> But are we ever going to separate these out? I assume someday
> controllers will support multiple Root Ports and/or additional devices
> on the root bus, like RCiEPs, RCECs, etc., and we'll need per-RP phys,
> max-link-speed, num-lanes, reset-gpios, etc.
>
> Seems like it would be to our benefit to split out the Root Ports when
> we can, even if the current hardware only supports one, so we can
> start untangling the code and data structures.
>
+1 for moving the properties to RP node where they should belong to. The
controller driver might have to do some extra work to parse the RP node and get
these properties, but it is worth the effort.
- Mani
--
மணிவண்ணன் சதாசிவம்
On 12/3/24 23:25, Bjorn Helgaas wrote:
> On Tue, Nov 26, 2024 at 04:51:15PM +0100, Christian Bruel wrote:
>> Document the bindings for STM32MP25 PCIe Controller configured in
>> root complex mode.
>>
>> Supports 4 legacy interrupts and MSI interrupts from the ARM
>> GICv2m controller.
>
> s/legacy/INTx/
>
>> STM32 PCIe may be in a power domain which is the case for the STM32MP25
>> based boards.
>>
>> Supports wake# from wake-gpios
>
> s/wake#/WAKE#/
>
>> + wake-gpios:
>> + description: GPIO controlled connection to WAKE# input signal
>
> I'm not a hardware guy, but this sounds like a GPIO that *reads*
> WAKE#, not controls it.
Rephrasing as
"GPIO used as WAKE# input signal" (output for the endpoint bindings)
>
>> + pcie@48400000 {
>> + compatible = "st,stm32mp25-pcie-rc";
>> + device_type = "pci";
>> + num-lanes = <1>;
>
> num-lanes applies to a Root Port, not to a Root Complex. I know most
> bindings conflate Root Ports with the Root Complex, maybe because many
> of these controllers only support a single Root Port?
>
> But are we ever going to separate these out? I assume someday
> controllers will support multiple Root Ports and/or additional devices
> on the root bus, like RCiEPs, RCECs, etc., and we'll need per-RP phys,
> max-link-speed, num-lanes, reset-gpios, etc.
>
> Seems like it would be to our benefit to split out the Root Ports when
> we can, even if the current hardware only supports one, so we can
> start untangling the code and data structures.
OK. and we support only 1 lane anyway, so drop it.
thanks,
>
> Bjorn
[cc->to: Rob for RC/RP separation conversation]
On Thu, Dec 05, 2024 at 02:41:26PM +0100, Christian Bruel wrote:
> On 12/3/24 23:25, Bjorn Helgaas wrote:
> > On Tue, Nov 26, 2024 at 04:51:15PM +0100, Christian Bruel wrote:
> > > Document the bindings for STM32MP25 PCIe Controller configured in
> > > root complex mode.
> > >
> > > Supports 4 legacy interrupts and MSI interrupts from the ARM
> > > GICv2m controller.
> > > + wake-gpios:
> > > + description: GPIO controlled connection to WAKE# input signal
> >
> > I'm not a hardware guy, but this sounds like a GPIO that *reads*
> > WAKE#, not controls it.
>
> Rephrasing as
> "GPIO used as WAKE# input signal" (output for the endpoint bindings)
Perfect, that makes a lot of sense.
> > > + pcie@48400000 {
> > > + compatible = "st,stm32mp25-pcie-rc";
> > > + device_type = "pci";
> > > + num-lanes = <1>;
> >
> > num-lanes applies to a Root Port, not to a Root Complex. I know most
> > bindings conflate Root Ports with the Root Complex, maybe because many
> > of these controllers only support a single Root Port?
> >
> > But are we ever going to separate these out? I assume someday
> > controllers will support multiple Root Ports and/or additional devices
> > on the root bus, like RCiEPs, RCECs, etc., and we'll need per-RP phys,
> > max-link-speed, num-lanes, reset-gpios, etc.
> >
> > Seems like it would be to our benefit to split out the Root Ports when
> > we can, even if the current hardware only supports one, so we can
> > start untangling the code and data structures.
>
> OK. and we support only 1 lane anyway, so drop it.
Makes sense. What about phys, resets, etc? I'm pretty sure a PHY
would be a per-Root Port thing, and some resets and wakeup signals
also.
For new drivers, I think we should start adding Root Port stanzas to
specifically associate those things with the Root Port, e.g.,
something like this?
pcie@48400000 {
compatible = "st,stm32mp25-pcie-rc";
pcie@0,0 {
reg = <0x0000 0 0 0 0>;
phys = <&combophy PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
};
};
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml?id=v6.12#n111
is one binding that does this, others include apple,pcie.yaml,
brcm,stb-pcie.yaml, hisilicon,kirin-pcie.yaml.
Bjorn
> Makes sense. What about phys, resets, etc? I'm pretty sure a PHY
> would be a per-Root Port thing, and some resets and wakeup signals
> also.
>
> For new drivers, I think we should start adding Root Port stanzas to
> specifically associate those things with the Root Port, e.g.,
> something like this?
>
> pcie@48400000 {
> compatible = "st,stm32mp25-pcie-rc";
>
> pcie@0,0 {
> reg = <0x0000 0 0 0 0>;
> phys = <&combophy PHY_TYPE_PCIE>;
> phy-names = "pcie-phy";
> };
> };
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml?id=v6.12#n111
> is one binding that does this, others include apple,pcie.yaml,
> brcm,stb-pcie.yaml, hisilicon,kirin-pcie.yaml.
>
On a second thought, moving the PHY to the root-port part would
introduce a discrepancy with the pcie_ep binding, whereas the PHY is
required on the pcie_ep node.
Even for the pcie_rc, the PHY is needed to enable the core_clk to access
the PCIe core registers,
So that would make 2 different required PHY locations for RC and EP:
pcie_rc: pcie@48400000 {
compatible = "st,stm32mp25-pcie-rc";
pcie@0,0 {
reg = <0x0000 0 0 0 0>;
phys = <&combophy PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
};
};
pcie_ep pcie@48400000 {
compatible = "st,stm32mp25-pcie-ep";
phys = <&combophy PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
};
Simplest seems to keep the PHY required for the pcie core regardless of
the mode and keep the empty root port to split the design
pcie_rc: pcie@48400000 {
compatible = "st,stm32mp25-pcie-rc";
phys = <&combophy PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
pcie@0,0 {
reg = <0x0000 0 0 0 0>;
};
};
pcie_ep: pcie@48400000 {
compatible = "st,stm32mp25-pcie-ep";
phys = <&combophy PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
};
But I have no experience with multiple root-port systems, I'm open for
the best :)
Thanks
Christian
On Tue, Dec 17, 2024 at 04:53:48PM +0100, Christian Bruel wrote:
>
> > Makes sense. What about phys, resets, etc? I'm pretty sure a PHY
> > would be a per-Root Port thing, and some resets and wakeup signals
> > also.
> >
> > For new drivers, I think we should start adding Root Port stanzas to
> > specifically associate those things with the Root Port, e.g.,
> > something like this?
> >
> > pcie@48400000 {
> > compatible = "st,stm32mp25-pcie-rc";
> >
> > pcie@0,0 {
> > reg = <0x0000 0 0 0 0>;
> > phys = <&combophy PHY_TYPE_PCIE>;
> > phy-names = "pcie-phy";
> > };
> > };
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml?id=v6.12#n111
> > is one binding that does this, others include apple,pcie.yaml,
> > brcm,stb-pcie.yaml, hisilicon,kirin-pcie.yaml.
> >
>
> On a second thought, moving the PHY to the root-port part would introduce a
> discrepancy with the pcie_ep binding, whereas the PHY is required on the
> pcie_ep node.
>
> Even for the pcie_rc, the PHY is needed to enable the core_clk to access
> the PCIe core registers,
>
But why that matters? You can still parse the child nodes, enable PHY and
configure PCIe registers.
> So that would make 2 different required PHY locations for RC and EP:
>
> pcie_rc: pcie@48400000 {
> compatible = "st,stm32mp25-pcie-rc";
>
> pcie@0,0 {
> reg = <0x0000 0 0 0 0>;
> phys = <&combophy PHY_TYPE_PCIE>;
> phy-names = "pcie-phy";
> };
> };
>
> pcie_ep pcie@48400000 {
> compatible = "st,stm32mp25-pcie-ep";
> phys = <&combophy PHY_TYPE_PCIE>;
> phy-names = "pcie-phy";
> };
>
> Simplest seems to keep the PHY required for the pcie core regardless of the
> mode and keep the empty root port to split the design
>
No please. Try to do the right thing from the start itself.
- Mani
--
மணிவண்ணன் சதாசிவம்
On 12/17/24 18:25, Manivannan Sadhasivam wrote:
> On Tue, Dec 17, 2024 at 04:53:48PM +0100, Christian Bruel wrote:
>>
>>> Makes sense. What about phys, resets, etc? I'm pretty sure a PHY
>>> would be a per-Root Port thing, and some resets and wakeup signals
>>> also.
>>>
>>> For new drivers, I think we should start adding Root Port stanzas to
>>> specifically associate those things with the Root Port, e.g.,
>>> something like this?
>>>
>>> pcie@48400000 {
>>> compatible = "st,stm32mp25-pcie-rc";
>>>
>>> pcie@0,0 {
>>> reg = <0x0000 0 0 0 0>;
>>> phys = <&combophy PHY_TYPE_PCIE>;
>>> phy-names = "pcie-phy";
>>> };
>>> };
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml?id=v6.12#n111
>>> is one binding that does this, others include apple,pcie.yaml,
>>> brcm,stb-pcie.yaml, hisilicon,kirin-pcie.yaml.
>>>
>>
>> On a second thought, moving the PHY to the root-port part would introduce a
>> discrepancy with the pcie_ep binding, whereas the PHY is required on the
>> pcie_ep node.
>>
>> Even for the pcie_rc, the PHY is needed to enable the core_clk to access
>> the PCIe core registers,
>>
>
> But why that matters? You can still parse the child nodes, enable PHY and
> configure PCIe registers. >
>> So that would make 2 different required PHY locations for RC and EP:
>>
>> pcie_rc: pcie@48400000 {
>> compatible = "st,stm32mp25-pcie-rc";
>>
>> pcie@0,0 {
>> reg = <0x0000 0 0 0 0>;
>> phys = <&combophy PHY_TYPE_PCIE>;
>> phy-names = "pcie-phy";
>> };
>> };
>>
>> pcie_ep pcie@48400000 {
>> compatible = "st,stm32mp25-pcie-ep";
>> phys = <&combophy PHY_TYPE_PCIE>;
>> phy-names = "pcie-phy";
>> };
>>
>> Simplest seems to keep the PHY required for the pcie core regardless of the
>> mode and keep the empty root port to split the design
>>
>
> No please. Try to do the right thing from the start itself.
Parsing the child node to clock the IP seems weird. Note that
hisilicon,kirin-pcie.yaml also declares the PHY at the controller level.
thanks
Christian
>
> - Mani
>
On Wed, Dec 18, 2024 at 09:42:45AM +0100, Christian Bruel wrote:
>
>
> On 12/17/24 18:25, Manivannan Sadhasivam wrote:
> > On Tue, Dec 17, 2024 at 04:53:48PM +0100, Christian Bruel wrote:
> > >
> > > > Makes sense. What about phys, resets, etc? I'm pretty sure a PHY
> > > > would be a per-Root Port thing, and some resets and wakeup signals
> > > > also.
> > > >
> > > > For new drivers, I think we should start adding Root Port stanzas to
> > > > specifically associate those things with the Root Port, e.g.,
> > > > something like this?
> > > >
> > > > pcie@48400000 {
> > > > compatible = "st,stm32mp25-pcie-rc";
> > > >
> > > > pcie@0,0 {
> > > > reg = <0x0000 0 0 0 0>;
> > > > phys = <&combophy PHY_TYPE_PCIE>;
> > > > phy-names = "pcie-phy";
> > > > };
> > > > };
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml?id=v6.12#n111
> > > > is one binding that does this, others include apple,pcie.yaml,
> > > > brcm,stb-pcie.yaml, hisilicon,kirin-pcie.yaml.
> > > >
> > >
> > > On a second thought, moving the PHY to the root-port part would introduce a
> > > discrepancy with the pcie_ep binding, whereas the PHY is required on the
> > > pcie_ep node.
> > >
> > > Even for the pcie_rc, the PHY is needed to enable the core_clk to access
> > > the PCIe core registers,
> > >
> >
> > But why that matters? You can still parse the child nodes, enable PHY and
> > configure PCIe registers. >
> > > So that would make 2 different required PHY locations for RC and EP:
> > >
> > > pcie_rc: pcie@48400000 {
> > > compatible = "st,stm32mp25-pcie-rc";
> > >
> > > pcie@0,0 {
> > > reg = <0x0000 0 0 0 0>;
> > > phys = <&combophy PHY_TYPE_PCIE>;
> > > phy-names = "pcie-phy";
> > > };
> > > };
> > >
> > > pcie_ep pcie@48400000 {
> > > compatible = "st,stm32mp25-pcie-ep";
> > > phys = <&combophy PHY_TYPE_PCIE>;
> > > phy-names = "pcie-phy";
> > > };
> > >
> > > Simplest seems to keep the PHY required for the pcie core regardless of the
> > > mode and keep the empty root port to split the design
> > >
> >
> > No please. Try to do the right thing from the start itself.
>
> Parsing the child node to clock the IP seems weird. Note that
> hisilicon,kirin-pcie.yaml also declares the PHY at the controller level.
>
Nothing is weird here. Almost all multi port controller drivers does the same.
Most of the single port controller instances define port properties in
controller node only, but that's what we want to avoid now.
- Mani
--
மணிவண்ணன் சதாசிவம்
On Tue, Nov 26, 2024 at 04:51:15PM +0100, Christian Bruel wrote:
> Document the bindings for STM32MP25 PCIe Controller configured in
> root complex mode.
>
> Supports 4 legacy interrupts and MSI interrupts from the ARM
> GICv2m controller.
>
> STM32 PCIe may be in a power domain which is the case for the STM32MP25
> based boards.
>
> Supports wake# from wake-gpios
>
> Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
> ---
> .../bindings/pci/st,stm32-pcie-common.yaml | 45 +++++++++
> .../bindings/pci/st,stm32-pcie-host.yaml | 99 +++++++++++++++++++
> 2 files changed, 144 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
> create mode 100644 Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
> new file mode 100644
> index 000000000000..479c03134da3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/st,stm32-pcie-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STM32MP25 PCIe RC/EP controller
> +
> +maintainers:
> + - Christian Bruel <christian.bruel@foss.st.com>
> +
> +description:
> + STM32MP25 PCIe RC/EP common properties
> +
> +properties:
> + clocks:
> + maxItems: 1
> + description: PCIe system clock
> +
> + resets:
> + maxItems: 1
> +
> + phys:
> + maxItems: 1
> +
> + phy-names:
> + const: pcie-phy
> +
> + power-domains:
> + maxItems: 1
> +
> + access-controllers:
> + maxItems: 1
> +
> + reset-gpios:
> + description: GPIO controlled connection to PERST# signal
> + maxItems: 1
> +
> +required:
> + - clocks
> + - resets
> + - phys
> + - phy-names
> +
> +additionalProperties: true
> diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
> new file mode 100644
> index 000000000000..18083cc69024
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
> @@ -0,0 +1,99 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/st,stm32-pcie-host.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STM32MP25 PCIe root complex driver
> +
> +maintainers:
> + - Christian Bruel <christian.bruel@foss.st.com>
> +
> +description:
> + PCIe root complex controller based on the Synopsys DesignWare PCIe core.
> +
> +allOf:
> + - $ref: /schemas/pci/snps,dw-pcie.yaml#
> + - $ref: /schemas/pci/st,stm32-pcie-common.yaml#
> +
> +select:
> + properties:
> + compatible:
> + const: st,stm32mp25-pcie-rc
> + required:
> + - compatible
> +
> +properties:
> + compatible:
> + const: st,stm32mp25-pcie-rc
> +
> + reg:
> + items:
> + - description: Data Bus Interface (DBI) registers.
> + - description: PCIe configuration registers.
> +
> + reg-names:
> + items:
> + - const: dbi
> + - const: config
> +
> + num-lanes:
> + const: 1
> +
> + msi-parent:
> + maxItems: 1
> +
> + wake-gpios:
> + description: GPIO controlled connection to WAKE# input signal
> + maxItems: 1
> +
> + wakeup-source: true
> +
> +dependentRequired:
> + wakeup-source: [ wake-gpios ]
> +
> +required:
> + - interrupt-map
> + - interrupt-map-mask
> + - ranges
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/st,stm32mp25-rcc.h>
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/phy/phy.h>
> + #include <dt-bindings/reset/st,stm32mp25-rcc.h>
> +
> + pcie@48400000 {
> + compatible = "st,stm32mp25-pcie-rc";
> + device_type = "pci";
> + num-lanes = <1>;
> + reg = <0x48400000 0x400000>,
> + <0x10000000 0x10000>;
> + reg-names = "dbi", "config";
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc 0 0 GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc 0 0 GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc 0 0 GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0 0x10010000 0x10010000 0 0x10000>,
PCI address of I/O region should start from address 0x00000000.
Also use hex notation for all values.
- Mani
--
மணிவண்ணன் சதாசிவம்
On 12/3/24 14:34, Manivannan Sadhasivam wrote:
> On Tue, Nov 26, 2024 at 04:51:15PM +0100, Christian Bruel wrote:
>> Document the bindings for STM32MP25 PCIe Controller configured in
>> root complex mode.
>>
>> Supports 4 legacy interrupts and MSI interrupts from the ARM
>> GICv2m controller.
>>
>> STM32 PCIe may be in a power domain which is the case for the STM32MP25
>> based boards.
>>
>> Supports wake# from wake-gpios
>>
>> Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
>> ---
>> .../bindings/pci/st,stm32-pcie-common.yaml | 45 +++++++++
>> .../bindings/pci/st,stm32-pcie-host.yaml | 99 +++++++++++++++++++
>> 2 files changed, 144 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
>> create mode 100644 Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
>> new file mode 100644
>> index 000000000000..479c03134da3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
>> @@ -0,0 +1,45 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pci/st,stm32-pcie-common.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: STM32MP25 PCIe RC/EP controller
>> +
>> +maintainers:
>> + - Christian Bruel <christian.bruel@foss.st.com>
>> +
>> +description:
>> + STM32MP25 PCIe RC/EP common properties
>> +
>> +properties:
>> + clocks:
>> + maxItems: 1
>> + description: PCIe system clock
>> +
>> + resets:
>> + maxItems: 1
>> +
>> + phys:
>> + maxItems: 1
>> +
>> + phy-names:
>> + const: pcie-phy
>> +
>> + power-domains:
>> + maxItems: 1
>> +
>> + access-controllers:
>> + maxItems: 1
>> +
>> + reset-gpios:
>> + description: GPIO controlled connection to PERST# signal
>> + maxItems: 1
>> +
>> +required:
>> + - clocks
>> + - resets
>> + - phys
>> + - phy-names
>> +
>> +additionalProperties: true
>> diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
>> new file mode 100644
>> index 000000000000..18083cc69024
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
>> @@ -0,0 +1,99 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pci/st,stm32-pcie-host.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: STM32MP25 PCIe root complex driver
>> +
>> +maintainers:
>> + - Christian Bruel <christian.bruel@foss.st.com>
>> +
>> +description:
>> + PCIe root complex controller based on the Synopsys DesignWare PCIe core.
>> +
>> +allOf:
>> + - $ref: /schemas/pci/snps,dw-pcie.yaml#
>> + - $ref: /schemas/pci/st,stm32-pcie-common.yaml#
>> +
>> +select:
>> + properties:
>> + compatible:
>> + const: st,stm32mp25-pcie-rc
>> + required:
>> + - compatible
>> +
>> +properties:
>> + compatible:
>> + const: st,stm32mp25-pcie-rc
>> +
>> + reg:
>> + items:
>> + - description: Data Bus Interface (DBI) registers.
>> + - description: PCIe configuration registers.
>> +
>> + reg-names:
>> + items:
>> + - const: dbi
>> + - const: config
>> +
>> + num-lanes:
>> + const: 1
>> +
>> + msi-parent:
>> + maxItems: 1
>> +
>> + wake-gpios:
>> + description: GPIO controlled connection to WAKE# input signal
>> + maxItems: 1
>> +
>> + wakeup-source: true
>> +
>> +dependentRequired:
>> + wakeup-source: [ wake-gpios ]
>> +
>> +required:
>> + - interrupt-map
>> + - interrupt-map-mask
>> + - ranges
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/st,stm32mp25-rcc.h>
>> + #include <dt-bindings/gpio/gpio.h>
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/phy/phy.h>
>> + #include <dt-bindings/reset/st,stm32mp25-rcc.h>
>> +
>> + pcie@48400000 {
>> + compatible = "st,stm32mp25-pcie-rc";
>> + device_type = "pci";
>> + num-lanes = <1>;
>> + reg = <0x48400000 0x400000>,
>> + <0x10000000 0x10000>;
>> + reg-names = "dbi", "config";
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 2 &intc 0 0 GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 3 &intc 0 0 GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 4 &intc 0 0 GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + ranges = <0x01000000 0 0x10010000 0x10010000 0 0x10000>,
>
> PCI address of I/O region should start from address 0x00000000.
>
ok, thanks !
> Also use hex notation for all values.
>
> - Mani
>
On Tue, Nov 26, 2024 at 04:51:15PM +0100, Christian Bruel wrote:
> Document the bindings for STM32MP25 PCIe Controller configured in
> root complex mode.
>
> Supports 4 legacy interrupts and MSI interrupts from the ARM
> GICv2m controller.
>
> STM32 PCIe may be in a power domain which is the case for the STM32MP25
> based boards.
>
> Supports wake# from wake-gpios
>
> Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
> ---
> .../bindings/pci/st,stm32-pcie-common.yaml | 45 +++++++++
> .../bindings/pci/st,stm32-pcie-host.yaml | 99 +++++++++++++++++++
> 2 files changed, 144 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
> create mode 100644 Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
> new file mode 100644
> index 000000000000..479c03134da3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/st,stm32-pcie-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STM32MP25 PCIe RC/EP controller
> +
> +maintainers:
> + - Christian Bruel <christian.bruel@foss.st.com>
> +
> +description:
> + STM32MP25 PCIe RC/EP common properties
> +
> +properties:
> + clocks:
> + maxItems: 1
> + description: PCIe system clock
> +
> + resets:
> + maxItems: 1
> +
> + phys:
> + maxItems: 1
> +
> + phy-names:
> + const: pcie-phy
> +
> + power-domains:
> + maxItems: 1
> +
> + access-controllers:
> + maxItems: 1
> +
> + reset-gpios:
> + description: GPIO controlled connection to PERST# signal
> + maxItems: 1
> +
> +required:
> + - clocks
> + - resets
> + - phys
> + - phy-names
> +
> +additionalProperties: true
> diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
> new file mode 100644
> index 000000000000..18083cc69024
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
> @@ -0,0 +1,99 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/st,stm32-pcie-host.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STM32MP25 PCIe root complex driver
> +
> +maintainers:
> + - Christian Bruel <christian.bruel@foss.st.com>
> +
> +description:
> + PCIe root complex controller based on the Synopsys DesignWare PCIe core.
> +
> +allOf:
> + - $ref: /schemas/pci/snps,dw-pcie.yaml#
> + - $ref: /schemas/pci/st,stm32-pcie-common.yaml#
> +
> +select:
You don't need select.
> + properties:
> + compatible:
> + const: st,stm32mp25-pcie-rc
> + required:
> + - compatible
> +
> +properties:
> + compatible:
> + const: st,stm32mp25-pcie-rc
> +
> + reg:
> + items:
> + - description: Data Bus Interface (DBI) registers.
> + - description: PCIe configuration registers.
> +
> + reg-names:
> + items:
> + - const: dbi
> + - const: config
> +
> + num-lanes:
> + const: 1
Not required, so what's the default? If it can only ever be 1, then why
do you need the property?
> +
> + msi-parent:
> + maxItems: 1
> +
> + wake-gpios:
> + description: GPIO controlled connection to WAKE# input signal
> + maxItems: 1
> +
> + wakeup-source: true
> +
> +dependentRequired:
> + wakeup-source: [ wake-gpios ]
> +
> +required:
> + - interrupt-map
> + - interrupt-map-mask
> + - ranges
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/st,stm32mp25-rcc.h>
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/phy/phy.h>
> + #include <dt-bindings/reset/st,stm32mp25-rcc.h>
> +
> + pcie@48400000 {
> + compatible = "st,stm32mp25-pcie-rc";
> + device_type = "pci";
> + num-lanes = <1>;
> + reg = <0x48400000 0x400000>,
> + <0x10000000 0x10000>;
> + reg-names = "dbi", "config";
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc 0 0 GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc 0 0 GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc 0 0 GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0 0x10010000 0x10010000 0 0x10000>,
> + <0x02000000 0 0x10020000 0x10020000 0 0x7fe0000>,
> + <0x42000000 0 0x18000000 0x18000000 0 0x8000000>;
> + clocks = <&rcc CK_BUS_PCIE>;
> + phys = <&combophy PHY_TYPE_PCIE>;
> + phy-names = "pcie-phy";
> + resets = <&rcc PCIE_R>;
> + msi-parent = <&v2m0>;
> + wakeup-source;
> + wake-gpios = <&gpioh 5 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> + reset-gpios = <&gpioj 8 GPIO_ACTIVE_LOW>;
> + access-controllers = <&rifsc 68>;
> + power-domains = <&CLUSTER_PD>;
> + };
> +
> --
> 2.34.1
>
© 2016 - 2026 Red Hat, Inc.