| Message ID | 20241011023724.614584-9-mailingradian@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add SDM670 camera subsystem | expand |
Hello Richard, On 10/11/24 05:37, Richard Acayan wrote: > As found in the Pixel 3a, the Snapdragon 670 has a camera subsystem with > 3 CSIDs and 3 VFEs (including 1 VFE lite). Add this camera subsystem to > the bindings. > > Adapted from SC8280XP camera subsystem. > > Signed-off-by: Richard Acayan <mailingradian@gmail.com> > --- > .../bindings/media/qcom,sdm670-camss.yaml | 318 ++++++++++++++++++ > 1 file changed, 318 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml > > diff --git a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml > new file mode 100644 > index 000000000000..670502532d28 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml > @@ -0,0 +1,318 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/qcom,sdm670-camss.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm SDM670 Camera Subsystem (CAMSS) > + > +maintainers: > + - Richard Acayan <mailingradian@gmail.com> > + > +description: > + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. > + > +properties: > + compatible: > + const: qcom,sdm670-camss > + > + reg: > + maxItems: 9 > + > + reg-names: > + items: > + - const: csid0 > + - const: csid1 > + - const: csid2 > + - const: csiphy0 > + - const: csiphy1 > + - const: csiphy2 > + - const: vfe0 > + - const: vfe1 > + - const: vfe_lite > + > + clocks: > + maxItems: 22 > + > + clock-names: > + items: > + - const: gcc_camera_ahb > + - const: gcc_camera_axi > + - const: soc_ahb > + - const: camnoc_axi > + - const: cpas_ahb > + - const: csi0 > + - const: csi1 > + - const: csi2 > + - const: csiphy0 > + - const: csiphy0_timer > + - const: csiphy1 > + - const: csiphy1_timer > + - const: csiphy2 > + - const: csiphy2_timer > + - const: vfe0_axi > + - const: vfe0 > + - const: vfe0_cphy_rx > + - const: vfe1_axi > + - const: vfe1 > + - const: vfe1_cphy_rx > + - const: vfe_lite > + - const: vfe_lite_cphy_rx > + > + interrupts: > + maxItems: 9 > + > + interrupt-names: > + items: > + - const: csid0 > + - const: csid1 > + - const: csid2 > + - const: csiphy0 > + - const: csiphy1 > + - const: csiphy2 > + - const: vfe0 > + - const: vfe1 > + - const: vfe_lite > + > + iommus: > + maxItems: 4 > + > + power-domains: > + items: > + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. > + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. > + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller. > + > + power-domain-names: > + items: > + - const: ife0 > + - const: ife1 > + - const: top > + > + ports: > + $ref: /schemas/graph.yaml#/properties/ports > + > + description: > + CSI input ports. > + > + properties: > + port@0: > + $ref: /schemas/graph.yaml#/$defs/port-base > + unevaluatedProperties: false > + description: > + Input port for receiving CSI data from CSIPHY0. > + > + properties: > + endpoint: > + $ref: video-interfaces.yaml# > + unevaluatedProperties: false > + > + properties: > + clock-lanes: > + maxItems: 1 > + > + data-lanes: > + minItems: 1 > + maxItems: 4 > + > + required: > + - clock-lanes > + - data-lanes > + > + port@1: > + $ref: /schemas/graph.yaml#/$defs/port-base > + unevaluatedProperties: false > + description: > + Input port for receiving CSI data from CSIPHY1. > + > + properties: > + endpoint: > + $ref: video-interfaces.yaml# > + unevaluatedProperties: false > + > + properties: > + clock-lanes: > + maxItems: 1 > + > + data-lanes: > + minItems: 1 > + maxItems: 4 > + > + required: > + - clock-lanes > + - data-lanes > + > + port@2: > + $ref: /schemas/graph.yaml#/$defs/port-base > + unevaluatedProperties: false > + description: > + Input port for receiving CSI data from CSIPHY2. > + > + properties: > + endpoint: > + $ref: video-interfaces.yaml# > + unevaluatedProperties: false > + > + properties: > + clock-lanes: > + maxItems: 1 > + > + data-lanes: > + minItems: 1 > + maxItems: 4 > + > + required: > + - clock-lanes > + - data-lanes > + > + vdda-phy-supply: > + description: > + Phandle to a regulator supply to PHY core block. > + > + vdda-pll-supply: > + description: > + Phandle to 1.8V regulator supply to PHY refclk pll block. > + > +required: > + - reg > + - reg-names > + - clock-names > + - clocks > + - compatible > + - interrupts > + - interrupt-names > + - iommus > + - power-domains > + - power-domain-names > + - vdda-phy-supply > + - vdda-pll-supply > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/clock/qcom,camcc-sdm845.h> > + #include <dt-bindings/clock/qcom,gcc-sdm845.h> > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + camss@ac65000 { > + compatible = "qcom,sdm670-camss"; > + > + reg = <0 0x0acb3000 0 0x1000>, This is immediately wrong, unit address shall be the same as the address of the first value of reg property. I still object to the sorting order of reg values dictated by reg-names property. There are a few recently added CAMSS device tree binding descriptions, where reg values are sorted by address values without a connection to another property values, and I believe this is the correct way to go. Two most recently added CAMSS IP descriptions (qcom,sm8250-camss.yaml and qcom,sc8280xp-camss.yaml) do implement sorting by reg values, I believe from now on it should be assumed that all subsequently added CAMSS IP descriptions to follow the same established policy. I vote for it. > + <0 0x0acba000 0 0x1000>, > + <0 0x0acc8000 0 0x1000>, > + <0 0x0ac65000 0 0x1000>, > + <0 0x0ac66000 0 0x1000>, > + <0 0x0ac67000 0 0x1000>, > + <0 0x0acaf000 0 0x4000>, > + <0 0x0acb6000 0 0x4000>, > + <0 0x0acc4000 0 0x4000>; > + reg-names = "csid0", > + "csid1", > + "csid2", > + "csiphy0", > + "csiphy1", > + "csiphy2", > + "vfe0", > + "vfe1", > + "vfe_lite"; > + > + interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>; > + interrupt-names = "csid0", > + "csid1", > + "csid2", > + "csiphy0", > + "csiphy1", > + "csiphy2", > + "vfe0", > + "vfe1", > + "vfe_lite"; > + > + clocks = <&gcc GCC_CAMERA_AHB_CLK>, > + <&gcc GCC_CAMERA_AXI_CLK>, > + <&camcc CAM_CC_SOC_AHB_CLK>, > + <&camcc CAM_CC_CAMNOC_AXI_CLK>, > + <&camcc CAM_CC_CPAS_AHB_CLK>, > + <&camcc CAM_CC_IFE_0_CSID_CLK>, > + <&camcc CAM_CC_IFE_1_CSID_CLK>, > + <&camcc CAM_CC_IFE_LITE_CSID_CLK>, > + <&camcc CAM_CC_CSIPHY0_CLK>, > + <&camcc CAM_CC_CSI0PHYTIMER_CLK>, > + <&camcc CAM_CC_CSIPHY1_CLK>, > + <&camcc CAM_CC_CSI1PHYTIMER_CLK>, > + <&camcc CAM_CC_CSIPHY2_CLK>, > + <&camcc CAM_CC_CSI2PHYTIMER_CLK>, > + <&camcc CAM_CC_IFE_0_AXI_CLK>, > + <&camcc CAM_CC_IFE_0_CLK>, > + <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>, > + <&camcc CAM_CC_IFE_1_AXI_CLK>, > + <&camcc CAM_CC_IFE_1_CLK>, > + <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>, > + <&camcc CAM_CC_IFE_LITE_CLK>, > + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>; > + clock-names = "gcc_camera_ahb", > + "gcc_camera_axi", > + "soc_ahb", > + "camnoc_axi", > + "cpas_ahb", > + "csi0", > + "csi1", > + "csi2", > + "csiphy0", > + "csiphy0_timer", > + "csiphy1", > + "csiphy1_timer", > + "csiphy2", > + "csiphy2_timer", > + "vfe0_axi", > + "vfe0", > + "vfe0_cphy_rx", > + "vfe1_axi", > + "vfe1", > + "vfe1_cphy_rx", > + "vfe_lite", > + "vfe_lite_cphy_rx"; > + > + iommus = <&apps_smmu 0x808 0x0>, > + <&apps_smmu 0x810 0x8>, > + <&apps_smmu 0xc08 0x0>, > + <&apps_smmu 0xc10 0x8>; > + > + power-domains = <&camcc IFE_0_GDSC>, > + <&camcc IFE_1_GDSC>, > + <&camcc TITAN_TOP_GDSC>; > + power-domain-names = "ife0", > + "ife1", > + "top"; > + > + vdda-phy-supply = <&vreg_l1a_1p225>; > + vdda-pll-supply = <&vreg_l8a_1p8>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + > + csiphy_ep0: endpoint { > + clock-lanes = <7>; > + data-lanes = <0 1 2 3>; > + remote-endpoint = <&front_sensor_ep>; > + }; > + }; > + }; > + }; > + }; -- Best wishes, Vladimir
On 11/10/2024 08:14, Vladimir Zapolskiy wrote: > > Two most recently added CAMSS IP descriptions (qcom,sm8250-camss.yaml and > qcom,sc8280xp-camss.yaml) do implement sorting by reg values, I believe > from now on > it should be assumed that all subsequently added CAMSS IP descriptions > to follow > the same established policy. My preference is sort by address not sort by name => we sort the device nodes themselves by address so it seems more consistent to sort by address inside of the devices too. Which means sorting reg by address and irq too. --- bod
On Fri, Oct 11, 2024 at 10:14:49AM +0300, Vladimir Zapolskiy wrote: > > + soc { > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + camss@ac65000 { > > + compatible = "qcom,sdm670-camss"; > > + > > + reg = <0 0x0acb3000 0 0x1000>, > > This is immediately wrong, unit address shall be the same as the address of the > first value of reg property. > > I still object to the sorting order of reg values dictated by reg-names property. > > There are a few recently added CAMSS device tree binding descriptions, where > reg values are sorted by address values without a connection to another property > values, and I believe this is the correct way to go. > > Two most recently added CAMSS IP descriptions (qcom,sm8250-camss.yaml and > qcom,sc8280xp-camss.yaml) do implement sorting by reg values, I believe from now on > it should be assumed that all subsequently added CAMSS IP descriptions to follow > the same established policy. Heh, sc8280xp introduced entirely different sorting also in interrupt-names. Just look at interrupts of sm8250 and sc8280xp. Luckily clocks are still keeping style. Can you start keeping consistency? All bindings from the same family of devices, especially if they share something, should have similar order in lists. How do you imagine writing drivers and request items by order (not by name) if the order is different in each flavor? And such change to randomness in style - sometimes reg sorted that way, sometimes other, interrupts sometimes like this or like that - should not come from Linaro. Best regards, Krzysztof
On Fri, Oct 11, 2024 at 09:31:06AM +0100, Bryan O'Donoghue wrote: > On 11/10/2024 08:14, Vladimir Zapolskiy wrote: > > > > Two most recently added CAMSS IP descriptions (qcom,sm8250-camss.yaml and > > qcom,sc8280xp-camss.yaml) do implement sorting by reg values, I believe > > from now on > > it should be assumed that all subsequently added CAMSS IP descriptions > > to follow > > the same established policy. > > My preference is sort by address not sort by name => we sort the device > nodes themselves by address so it seems more consistent to sort by address > inside of the devices too. Strictly speaking, the values of addresses are unknown to the binding, so you can't sort by address. However, if something is truly a single block, then the offsets are probably fixed in order by offset makes sense. But when a block is changed, any rule on sorting may go out the window since we add new regions on the end. This one in particular I have to wonder why csiphy is not a separate node. > > Which means sorting reg by address and irq too. IRQs make little sense to sort IMO. Rob
On 11/10/2024 15:41, Rob Herring wrote: > But when a block is changed, any rule on sorting may go out > the window since we add new regions on the end. Ah I see, I didn't TBH know that. > This one in particular I have to wonder why csiphy is not a separate > node. Hmm, to be honest with you Rob, even though I realise I'm digging myself into a hole of yet more work, yes - we should probably structure camss along the lines of mdss which has separate nodes for DSI phys. -> mdss: display-subsystem@ae00000{} We have 4 SoCs "in flight" at the moment. sdm670 and sc7280 don't require any real driver update to facilitate. sm8550 and x1e80100 do require new VFE, CSID etc. We've been debating how to model the regulators for the CSIPHYs too which are on rails supplied by PMICs external to the SoC. I'm congniscient of the fact 670, 7280 and to an extent sm8550 have been on the list for quite some time, so I'd rather not push 670 and 7280 to have to wait for a whole new way of doing CSIPHYs - especially because these are old hardware with little to no driver change required to support. OTOH x1e80100 and sm8550 already need development work so we can do the CSIPHY transition there. --- bod
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml new file mode 100644 index 000000000000..670502532d28 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml @@ -0,0 +1,318 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,sdm670-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SDM670 Camera Subsystem (CAMSS) + +maintainers: + - Richard Acayan <mailingradian@gmail.com> + +description: + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. + +properties: + compatible: + const: qcom,sdm670-camss + + reg: + maxItems: 9 + + reg-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: vfe0 + - const: vfe1 + - const: vfe_lite + + clocks: + maxItems: 22 + + clock-names: + items: + - const: gcc_camera_ahb + - const: gcc_camera_axi + - const: soc_ahb + - const: camnoc_axi + - const: cpas_ahb + - const: csi0 + - const: csi1 + - const: csi2 + - const: csiphy0 + - const: csiphy0_timer + - const: csiphy1 + - const: csiphy1_timer + - const: csiphy2 + - const: csiphy2_timer + - const: vfe0_axi + - const: vfe0 + - const: vfe0_cphy_rx + - const: vfe1_axi + - const: vfe1 + - const: vfe1_cphy_rx + - const: vfe_lite + - const: vfe_lite_cphy_rx + + interrupts: + maxItems: 9 + + interrupt-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: vfe0 + - const: vfe1 + - const: vfe_lite + + iommus: + maxItems: 4 + + power-domains: + items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller. + + power-domain-names: + items: + - const: ife0 + - const: ife1 + - const: top + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data from CSIPHY0. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data from CSIPHY1. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@2: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data from CSIPHY2. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.8V regulator supply to PHY refclk pll block. + +required: + - reg + - reg-names + - clock-names + - clocks + - compatible + - interrupts + - interrupt-names + - iommus + - power-domains + - power-domain-names + - vdda-phy-supply + - vdda-pll-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,camcc-sdm845.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + camss@ac65000 { + compatible = "qcom,sdm670-camss"; + + reg = <0 0x0acb3000 0 0x1000>, + <0 0x0acba000 0 0x1000>, + <0 0x0acc8000 0 0x1000>, + <0 0x0ac65000 0 0x1000>, + <0 0x0ac66000 0 0x1000>, + <0 0x0ac67000 0 0x1000>, + <0 0x0acaf000 0 0x4000>, + <0 0x0acb6000 0 0x4000>, + <0 0x0acc4000 0 0x4000>; + reg-names = "csid0", + "csid1", + "csid2", + "csiphy0", + "csiphy1", + "csiphy2", + "vfe0", + "vfe1", + "vfe_lite"; + + interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "csid0", + "csid1", + "csid2", + "csiphy0", + "csiphy1", + "csiphy2", + "vfe0", + "vfe1", + "vfe_lite"; + + clocks = <&gcc GCC_CAMERA_AHB_CLK>, + <&gcc GCC_CAMERA_AXI_CLK>, + <&camcc CAM_CC_SOC_AHB_CLK>, + <&camcc CAM_CC_CAMNOC_AXI_CLK>, + <&camcc CAM_CC_CPAS_AHB_CLK>, + <&camcc CAM_CC_IFE_0_CSID_CLK>, + <&camcc CAM_CC_IFE_1_CSID_CLK>, + <&camcc CAM_CC_IFE_LITE_CSID_CLK>, + <&camcc CAM_CC_CSIPHY0_CLK>, + <&camcc CAM_CC_CSI0PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY1_CLK>, + <&camcc CAM_CC_CSI1PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY2_CLK>, + <&camcc CAM_CC_CSI2PHYTIMER_CLK>, + <&camcc CAM_CC_IFE_0_AXI_CLK>, + <&camcc CAM_CC_IFE_0_CLK>, + <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_1_AXI_CLK>, + <&camcc CAM_CC_IFE_1_CLK>, + <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_CLK>, + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>; + clock-names = "gcc_camera_ahb", + "gcc_camera_axi", + "soc_ahb", + "camnoc_axi", + "cpas_ahb", + "csi0", + "csi1", + "csi2", + "csiphy0", + "csiphy0_timer", + "csiphy1", + "csiphy1_timer", + "csiphy2", + "csiphy2_timer", + "vfe0_axi", + "vfe0", + "vfe0_cphy_rx", + "vfe1_axi", + "vfe1", + "vfe1_cphy_rx", + "vfe_lite", + "vfe_lite_cphy_rx"; + + iommus = <&apps_smmu 0x808 0x0>, + <&apps_smmu 0x810 0x8>, + <&apps_smmu 0xc08 0x0>, + <&apps_smmu 0xc10 0x8>; + + power-domains = <&camcc IFE_0_GDSC>, + <&camcc IFE_1_GDSC>, + <&camcc TITAN_TOP_GDSC>; + power-domain-names = "ife0", + "ife1", + "top"; + + vdda-phy-supply = <&vreg_l1a_1p225>; + vdda-pll-supply = <&vreg_l8a_1p8>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + csiphy_ep0: endpoint { + clock-lanes = <7>; + data-lanes = <0 1 2 3>; + remote-endpoint = <&front_sensor_ep>; + }; + }; + }; + }; + };
As found in the Pixel 3a, the Snapdragon 670 has a camera subsystem with 3 CSIDs and 3 VFEs (including 1 VFE lite). Add this camera subsystem to the bindings. Adapted from SC8280XP camera subsystem. Signed-off-by: Richard Acayan <mailingradian@gmail.com> --- .../bindings/media/qcom,sdm670-camss.yaml | 318 ++++++++++++++++++ 1 file changed, 318 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml