From: Vitor Soares <vitor.soares@toradex.com>

Add optional regulator supply properties for PCIe endpoints on TI SoCs.
Some boards provide dedicated regulators for PCIe devices, such as
1.5V (miniPCIe), 3.3V (common for M.2 or miniPCIe), or 12V
(for high-power devices). These supplies are now described as optional
properties to allow the driver to control endpoint power where supported.

Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
---
 .../devicetree/bindings/pci/ti,j721e-pci-host.yaml | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
index c704099f134b..a20b03406448 100644
--- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
@@ -110,6 +110,18 @@ properties:
       interrupts:
         maxItems: 1
 
+  vpcie1v5-supply:
+    description: 1.5V regulator used to power PCIe interfaces,
+                 typically present on miniPCIe slots.
+
+  vpcie3v3-supply:
+    description: 3.3V regulator used to power PCIe interfaces
+                 or endpoint connectors such as M.2 or miniPCIe.
+
+  vpcie12v-supply:
+    description: 12V regulator used to power PCIe slots that
+                 require higher-voltage devices (e.g. full-size cards).
+
 allOf:
   - $ref: cdns-pcie-host.yaml#
   - if:
@@ -202,5 +214,7 @@ examples:
             ranges = <0x01000000 0x0 0x10001000  0x00 0x10001000  0x0 0x0010000>,
                      <0x02000000 0x0 0x10011000  0x00 0x10011000  0x0 0x7fef000>;
             dma-ranges = <0x02000000 0x0 0x0 0x0 0x0 0x10000 0x0>;
+            vpcie3v3-supply = <&pcie_3v3>;
+            vpcie12v-supply = <&pcie_12v>;
         };
     };
-- 
2.51.0

On Tue, Oct 14, 2025 at 12:25:48PM +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
> 
> Add optional regulator supply properties for PCIe endpoints on TI SoCs.
> Some boards provide dedicated regulators for PCIe devices, such as
> 1.5V (miniPCIe), 3.3V (common for M.2 or miniPCIe), or 12V
> (for high-power devices). These supplies are now described as optional
> properties to allow the driver to control endpoint power where supported.

Last sentence is completely redundant. Please do not describe DT, we
all can read the patch. Driver is irrelevant here.

How you described here and in descriptions, suggests these are rather
port properties, not the controller.

> 
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> ---
>  .../devicetree/bindings/pci/ti,j721e-pci-host.yaml | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
> index c704099f134b..a20b03406448 100644
> --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
> +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
> @@ -110,6 +110,18 @@ properties:
>        interrupts:
>          maxItems: 1
>  
> +  vpcie1v5-supply:

How is it called in this device datasheet (not the board schematics)?

> +    description: 1.5V regulator used to power PCIe interfaces,
> +                 typically present on miniPCIe slots.

Best regards,
Krzysztof

Hi Krzysztof,

Thank you for the feedback.

On Mon, 2025-10-20 at 13:14 +0200, Krzysztof Kozlowski wrote:
> On Tue, Oct 14, 2025 at 12:25:48PM +0100, Vitor Soares wrote:
> > From: Vitor Soares <vitor.soares@toradex.com>
> > 
> > Add optional regulator supply properties for PCIe endpoints on TI SoCs.
> > Some boards provide dedicated regulators for PCIe devices, such as
> > 1.5V (miniPCIe), 3.3V (common for M.2 or miniPCIe), or 12V
> > (for high-power devices). These supplies are now described as optional
> > properties to allow the driver to control endpoint power where supported.
> 
> Last sentence is completely redundant. Please do not describe DT, we
> all can read the patch. Driver is irrelevant here.
> 
> 
Ack, I will remove last sentence.

> 
> How you described here and in descriptions, suggests these are rather
> port properties, not the controller.

You are right - these supplies power the PCIe slot/connector, not the controller
itself. However, as per my understanding, the current kernel practice is to
place slot supplies in the root complex node rather than the endpoint node. as
seen in e.g.:
- imx6q-pcie.yaml
- rockchip-dw-pcie.yaml
- rcar-pci-host.yaml

This seems consistent with those existing bindings, but please let me know if
I’m overlooking something specific to this case.

> 
> > 
> > Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> > ---
> >  .../devicetree/bindings/pci/ti,j721e-pci-host.yaml | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
> > b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
> > index c704099f134b..a20b03406448 100644
> > --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
> > +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
> > @@ -110,6 +110,18 @@ properties:
> >        interrupts:
> >          maxItems: 1
> >  
> > +  vpcie1v5-supply:
> 
> How is it called in this device datasheet (not the board schematics)?

The TI SoC datasheet describes the controller interface but doesn’t define these
external supply rails - they are board-level regulators specific to the slot.

> 
> > +    description: 1.5V regulator used to power PCIe interfaces,
> > +                 typically present on miniPCIe slots.
> 
> Best regards,
> Krzysztof
> 

Best regards,
Vitor Soares

On Mon, Oct 27, 2025 at 11:22:26PM +0000, Vitor Soares wrote:
> Hi Krzysztof,
> 
> Thank you for the feedback.
> 
> On Mon, 2025-10-20 at 13:14 +0200, Krzysztof Kozlowski wrote:
> > On Tue, Oct 14, 2025 at 12:25:48PM +0100, Vitor Soares wrote:
> > > From: Vitor Soares <vitor.soares@toradex.com>
> > > 
> > > Add optional regulator supply properties for PCIe endpoints on TI SoCs.
> > > Some boards provide dedicated regulators for PCIe devices, such as
> > > 1.5V (miniPCIe), 3.3V (common for M.2 or miniPCIe), or 12V
> > > (for high-power devices). These supplies are now described as optional
> > > properties to allow the driver to control endpoint power where supported.
> > 
> > Last sentence is completely redundant. Please do not describe DT, we
> > all can read the patch. Driver is irrelevant here.
> > 
> > 
> Ack, I will remove last sentence.
> 
> > 
> > How you described here and in descriptions, suggests these are rather
> > port properties, not the controller.
> 
> You are right - these supplies power the PCIe slot/connector, not the controller
> itself. However, as per my understanding, the current kernel practice is to
> place slot supplies in the root complex node rather than the endpoint node. as
> seen in e.g.:
> - imx6q-pcie.yaml
> - rockchip-dw-pcie.yaml
> - rcar-pci-host.yaml
> 
> This seems consistent with those existing bindings, but please let me know if
> I’m overlooking something specific to this case.
> 

We do not properly document it, but defining the slot supplies in host bridge
(controller) node is deprecated. Some bindings still do it for legacy reasons,
but the new ones should define them in the Root Port nodes as they belong to. We
do not have a separate DT node for PCI slots, but rather reuse the Root Port
node.

There are also bindings that define supplies in the endpoint node. They do it
for devices directly connected to the PCI bus without a connector (like in PCB).

- Mani

-- 
மணிவண்ணன் சதாசிவம்

On Tue, 2025-10-28 at 11:11 +0530, Manivannan Sadhasivam wrote:
> On Mon, Oct 27, 2025 at 11:22:26PM +0000, Vitor Soares wrote:
> > Hi Krzysztof,
> > 
> > Thank you for the feedback.
> > 
> > On Mon, 2025-10-20 at 13:14 +0200, Krzysztof Kozlowski wrote:
> > > On Tue, Oct 14, 2025 at 12:25:48PM +0100, Vitor Soares wrote:
> > > > From: Vitor Soares <vitor.soares@toradex.com>
> > > > 
> > > > Add optional regulator supply properties for PCIe endpoints on TI SoCs.
> > > > Some boards provide dedicated regulators for PCIe devices, such as
> > > > 1.5V (miniPCIe), 3.3V (common for M.2 or miniPCIe), or 12V
> > > > (for high-power devices). These supplies are now described as optional
> > > > properties to allow the driver to control endpoint power where
> > > > supported.
> > > 
> > > Last sentence is completely redundant. Please do not describe DT, we
> > > all can read the patch. Driver is irrelevant here.
> > > 
> > > 
> > Ack, I will remove last sentence.
> > 
> > > 
> > > How you described here and in descriptions, suggests these are rather
> > > port properties, not the controller.
> > 
> > You are right - these supplies power the PCIe slot/connector, not the
> > controller
> > itself. However, as per my understanding, the current kernel practice is to
> > place slot supplies in the root complex node rather than the endpoint node.
> > as
> > seen in e.g.:
> > - imx6q-pcie.yaml
> > - rockchip-dw-pcie.yaml
> > - rcar-pci-host.yaml
> > 
> > This seems consistent with those existing bindings, but please let me know
> > if
> > I’m overlooking something specific to this case.
> > 
> 
> We do not properly document it, but defining the slot supplies in host bridge
> (controller) node is deprecated. Some bindings still do it for legacy reasons,
> but the new ones should define them in the Root Port nodes as they belong to.
> We
> do not have a separate DT node for PCI slots, but rather reuse the Root Port
> node.
> 
> There are also bindings that define supplies in the endpoint node. They do it
> for devices directly connected to the PCI bus without a connector (like in
> PCB).
> 
> - Mani
> 

Thanks for the clarification and context. From what I understand, the
recommendation is to define the supply regulators under the individual root port
node rather than in the host bridge (controller) node, as the supplies
conceptually belong to each port rather than the controller itself.

On the j721e PCIe controller, the current driver implementation assumes a single
root port and doesn’t parse child port nodes. To follow the new convention, I’d
need to refactor the driver to support root port subnodes, and I wonder if the
PHY reference and reset should also be moved to the Root Port node in that case.

Could you please point me to an example of a PCIe controller binding or driver
that already follows this approach?

Best regards,
Vitor Soares