Support regulators found on the e.g. KingFisher board.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 Documentation/devicetree/bindings/pci/rcar-pci-host.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
index 8fdfbc763d70..23e44f78e62e 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
@@ -68,6 +68,12 @@ properties:
   phy-names:
     const: pcie
 
+  vpcie1v5-supply:
+    description: The 1.5v regulator to use for PCIe.
+
+  vpcie3v3-supply:
+    description: The 3.3v regulator to use for PCIe.
+
 required:
   - compatible
   - reg
@@ -121,5 +127,7 @@ examples:
              clock-names = "pcie", "pcie_bus";
              power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
              resets = <&cpg 319>;
+             vpcie1v5-supply = <&pcie_1v5>;
+             vpcie3v3-supply = <&pcie_3v3>;
          };
     };
-- 
2.30.2

Hi Wolfram,

On Mon, May 8, 2023 at 12:46 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> Support regulators found on the e.g. KingFisher board.

... for the mini-PCIe slot.

> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Thanks for your patch!

> --- a/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
> @@ -68,6 +68,12 @@ properties:
>    phy-names:
>      const: pcie
>
> +  vpcie1v5-supply:
> +    description: The 1.5v regulator to use for PCIe.

+1.5V is only present on mini-PCIe slots...

> +
> +  vpcie3v3-supply:
> +    description: The 3.3v regulator to use for PCIe.

... while +3.3V is present on PCIe, mini-PCIe, and M2 PCIe slots.

In addition, normal PCIe slots also have +12V.
So I think it would be prudent to add a vpcie12v0-supply property, too.

W.r.t. to the actual naming, I don't know if there's already a (de facto)
standard for that?

> +
>  required:
>    - compatible
>    - reg
> @@ -121,5 +127,7 @@ examples:
>               clock-names = "pcie", "pcie_bus";
>               power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
>               resets = <&cpg 319>;
> +             vpcie1v5-supply = <&pcie_1v5>;
> +             vpcie3v3-supply = <&pcie_3v3>;
>           };
>      };

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

Hi Geert,

> > +  vpcie1v5-supply:
> > +    description: The 1.5v regulator to use for PCIe.
> 
> +1.5V is only present on mini-PCIe slots...

Since mini-PCIe is a subset of PCIe, I'd think we can leave the
description as-is.

> > +
> > +  vpcie3v3-supply:
> > +    description: The 3.3v regulator to use for PCIe.
> 
> ... while +3.3V is present on PCIe, mini-PCIe, and M2 PCIe slots.
> 
> In addition, normal PCIe slots also have +12V.
> So I think it would be prudent to add a vpcie12v0-supply property, too.

I agree. I can't test it but it is trivial enough to add 12v support as
well.

> W.r.t. to the actual naming, I don't know if there's already a (de facto)
> standard for that?

I couldn't find one and took what I think is the most used pattern. But
I wasn't entirely sure, this is why the series is still RFC.

Thanks for the review!

   Wolfram

Hi Wolfram,

On Mon, May 8, 2023 at 8:48 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > > +  vpcie1v5-supply:
> > > +    description: The 1.5v regulator to use for PCIe.
> >
> > +1.5V is only present on mini-PCIe slots...
>
> Since mini-PCIe is a subset of PCIe, I'd think we can leave the
> description as-is.

Sure, the description is fine.

> > > +
> > > +  vpcie3v3-supply:
> > > +    description: The 3.3v regulator to use for PCIe.
> >
> > ... while +3.3V is present on PCIe, mini-PCIe, and M2 PCIe slots.
> >
> > In addition, normal PCIe slots also have +12V.
> > So I think it would be prudent to add a vpcie12v0-supply property, too.
>
> I agree. I can't test it but it is trivial enough to add 12v support as
> well.
>
> > W.r.t. to the actual naming, I don't know if there's already a (de facto)
> > standard for that?
>
> I couldn't find one and took what I think is the most used pattern. But
> I wasn't entirely sure, this is why the series is still RFC.

Upon second thought, shouldn't these supplies be part of a PCIe
connector subnode, as they are not properties of the PCIe host
controller itself?

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

> > I couldn't find one and took what I think is the most used pattern. But
> > I wasn't entirely sure, this is why the series is still RFC.
> 
> Upon second thought, shouldn't these supplies be part of a PCIe
> connector subnode, as they are not properties of the PCIe host
> controller itself?

Beats me. Current practice is to put it in the host controller.

On Mon, 08 May 2023 12:45:55 +0200, Wolfram Sang wrote:
> Support regulators found on the e.g. KingFisher board.
> 
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>  Documentation/devicetree/bindings/pci/rcar-pci-host.yaml | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/rockchip-isp1.example.dtb: camera@3c: port:endpoint:data-lanes: [[1]] is too short
	From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.example.dtb: camera-sensor@3c: port:endpoint:data-lanes: [[1]] is too short
	From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.example.dtb: pcie-ep@33800000: Unevaluated properties are not allowed ('assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' were unexpected)
	From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml

doc reference errors (make refcheckdocs):
Documentation/usb/gadget_uvc.rst: Documentation/userspace-api/media/v4l/pixfmt-packed.yuv.rst
MAINTAINERS: Documentation/devicetree/bindings/pwm/pwm-apple.yaml

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230508104557.47889-2-wsa+renesas@sang-engineering.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.