Support regulators found on the e.g. KingFisher board.
Signed-off-by: Wolfram Sang <[email protected]>
---
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
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 <[email protected]>
> ---
> 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/[email protected]
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.
Hi Wolfram,
On Mon, May 8, 2023 at 12:46 PM Wolfram Sang
<[email protected]> wrote:
> Support regulators found on the e.g. KingFisher board.
... for the mini-PCIe slot.
> Signed-off-by: Wolfram Sang <[email protected]>
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 -- [email protected]
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
<[email protected]> 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 -- [email protected]
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.