| Message ID | 20230508104557.47889-2-wsa+renesas@sang-engineering.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | KingFisher: support regulators for PCIe | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | success | |
| robh/dt-meta-schema | fail | build log |
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.
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
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.
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>; }; };
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(+)