From: Vincent Knecht <vincent.knecht@mailoo.org>
Add bindings for qcom,msm8939-camss in order to support the camera
subsystem for MSM8939.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org>
---
.../bindings/media/qcom,msm8939-camss.yaml | 254 +++++++++++++++++++++
1 file changed, 254 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..9fbb4b204ac8728b822864ad8336aa9d826d6b5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml
@@ -0,0 +1,254 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,msm8939-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8939 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Vincent Knecht <vincent.knecht@mailoo.org>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
+
+properties:
+ compatible:
+ const: qcom,msm8939-camss
+
+ reg:
+ maxItems: 11
+
+ reg-names:
+ items:
+ - const: csi_clk_mux
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csiphy0
+ - const: csiphy0_clk_mux
+ - const: csiphy1
+ - const: csiphy1_clk_mux
+ - const: ispif
+ - const: vfe0
+ - const: vfe0_vbif
+
+ clocks:
+ maxItems: 24
+
+ clock-names:
+ items:
+ - const: ahb
+ - const: csi0
+ - const: csi0_ahb
+ - const: csi0_phy
+ - const: csi0_pix
+ - const: csi0_rdi
+ - const: csi1
+ - const: csi1_ahb
+ - const: csi1_phy
+ - const: csi1_pix
+ - const: csi1_rdi
+ - const: csi2
+ - const: csi2_ahb
+ - const: csi2_phy
+ - const: csi2_pix
+ - const: csi2_rdi
+ - const: csi_vfe0
+ - const: csiphy0_timer
+ - const: csiphy1_timer
+ - const: ispif_ahb
+ - const: top_ahb
+ - const: vfe0
+ - const: vfe_ahb
+ - const: vfe_axi
+
+ interrupts:
+ maxItems: 7
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csiphy0
+ - const: csiphy1
+ - const: ispif
+ - const: vfe0
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description: VFE GDSC - Video Front End, Global Distributed Switch
+ Controller.
+
+ vdda-supply:
+ description:
+ Definition of the regulator used as 1.2V analog power supply.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ patternProperties:
+ "^port@[0-1]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - power-domains
+ - vdda-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,gcc-msm8939.h>
+
+ isp@1b00020 {
+ compatible = "qcom,msm8939-camss";
+
+ reg = <0x01b00020 0x10>,
+ <0x01b08000 0x100>,
+ <0x01b08400 0x100>,
+ <0x01b08800 0x100>,
+ <0x01b0ac00 0x200>,
+ <0x01b00030 0x4>,
+ <0x01b0b000 0x200>,
+ <0x01b00038 0x4>,
+ <0x01b0a000 0x500>,
+ <0x01b10000 0x1000>,
+ <0x01b40000 0x200>;
+
+ reg-names = "csi_clk_mux",
+ "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy0_clk_mux",
+ "csiphy1",
+ "csiphy1_clk_mux",
+ "ispif",
+ "vfe0",
+ "vfe0_vbif";
+
+ clocks = <&gcc GCC_CAMSS_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0_CLK>,
+ <&gcc GCC_CAMSS_CSI0_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI0PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI0RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI1_CLK>,
+ <&gcc GCC_CAMSS_CSI1_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI1PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI1RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI2_CLK>,
+ <&gcc GCC_CAMSS_CSI2_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI2PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI2PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI2RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI_VFE0_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
+ <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE0_CLK>,
+ <&gcc GCC_CAMSS_VFE_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE_AXI_CLK>;
+
+ clock-names = "ahb",
+ "csi0",
+ "csi0_ahb",
+ "csi0_phy",
+ "csi0_pix",
+ "csi0_rdi",
+ "csi1",
+ "csi1_ahb",
+ "csi1_phy",
+ "csi1_pix",
+ "csi1_rdi",
+ "csi2",
+ "csi2_ahb",
+ "csi2_phy",
+ "csi2_pix",
+ "csi2_rdi",
+ "csi_vfe0",
+ "csiphy0_timer",
+ "csiphy1_timer",
+ "ispif_ahb",
+ "top_ahb",
+ "vfe0",
+ "vfe_ahb",
+ "vfe_axi";
+
+ interrupts = <GIC_SPI 51 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 52 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 153 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 55 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy1",
+ "ispif",
+ "vfe0";
+
+ iommus = <&apps_iommu 3>;
+
+ power-domains = <&gcc VFE_GDSC>;
+
+ vdda-supply = <®_1v2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ csiphy1_ep: endpoint {
+ data-lanes = <0 2>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
--
2.49.0On 13/06/2025 10:33, Vincent Knecht via B4 Relay wrote:
> From: Vincent Knecht <vincent.knecht@mailoo.org>
>
> Add bindings for qcom,msm8939-camss in order to support the camera
> subsystem for MSM8939.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org>
> ---
> .../bindings/media/qcom,msm8939-camss.yaml | 254 +++++++++++++++++++++
> 1 file changed, 254 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..9fbb4b204ac8728b822864ad8336aa9d826d6b5b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml
> @@ -0,0 +1,254 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/qcom,msm8939-camss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm MSM8939 Camera Subsystem (CAMSS)
> +
> +maintainers:
> + - Vincent Knecht <vincent.knecht@mailoo.org>
> +
> +description:
> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
> +
> +properties:
> + compatible:
> + const: qcom,msm8939-camss
> +
> + reg:
> + maxItems: 11
> +
> + reg-names:
> + items:
> + - const: csi_clk_mux
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csiphy0
> + - const: csiphy0_clk_mux
> + - const: csiphy1
> + - const: csiphy1_clk_mux
> + - const: ispif
> + - const: vfe0
> + - const: vfe0_vbif
> +
> + clocks:
> + maxItems: 24
> +
> + clock-names:
> + items:
> + - const: ahb
> + - const: csi0
> + - const: csi0_ahb
> + - const: csi0_phy
> + - const: csi0_pix
> + - const: csi0_rdi
> + - const: csi1
> + - const: csi1_ahb
> + - const: csi1_phy
> + - const: csi1_pix
> + - const: csi1_rdi
> + - const: csi2
> + - const: csi2_ahb
> + - const: csi2_phy
> + - const: csi2_pix
> + - const: csi2_rdi
> + - const: csi_vfe0
> + - const: csiphy0_timer
> + - const: csiphy1_timer
> + - const: ispif_ahb
> + - const: top_ahb
> + - const: vfe0
> + - const: vfe_ahb
> + - const: vfe_axi
> +
> + interrupts:
> + maxItems: 7
> +
> + interrupt-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csiphy0
> + - const: csiphy1
> + - const: ispif
> + - const: vfe0
> +
> + iommus:
> + maxItems: 1
> +
> + power-domains:
> + items:
> + - description: VFE GDSC - Video Front End, Global Distributed Switch
> + Controller.
> +
> + vdda-supply:
> + description:
> + Definition of the regulator used as 1.2V analog power supply.
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + description:
> + CSI input ports.
> +
> + patternProperties:
> + "^port@[0-1]$":
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> +
> + description:
> + Input port for receiving CSI data.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + bus-type:
> + enum:
> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
> +
> + required:
> + - data-lanes
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-names
> + - iommus
> + - power-domains
> + - vdda-supply
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,gcc-msm8939.h>
> +
> + isp@1b00020 {
> + compatible = "qcom,msm8939-camss";
> +
> + reg = <0x01b00020 0x10>,
> + <0x01b08000 0x100>,
> + <0x01b08400 0x100>,
> + <0x01b08800 0x100>,
> + <0x01b0ac00 0x200>,
> + <0x01b00030 0x4>,
> + <0x01b0b000 0x200>,
> + <0x01b00038 0x4>,
> + <0x01b0a000 0x500>,
> + <0x01b10000 0x1000>,
> + <0x01b40000 0x200>;
> +
> + reg-names = "csi_clk_mux",
> + "csid0",
> + "csid1",
> + "csid2",
> + "csiphy0",
> + "csiphy0_clk_mux",
> + "csiphy1",
> + "csiphy1_clk_mux",
> + "ispif",
> + "vfe0",
> + "vfe0_vbif";
> +
> + clocks = <&gcc GCC_CAMSS_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI0_CLK>,
> + <&gcc GCC_CAMSS_CSI0_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI0PHY_CLK>,
> + <&gcc GCC_CAMSS_CSI0PIX_CLK>,
> + <&gcc GCC_CAMSS_CSI0RDI_CLK>,
> + <&gcc GCC_CAMSS_CSI1_CLK>,
> + <&gcc GCC_CAMSS_CSI1_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI1PHY_CLK>,
> + <&gcc GCC_CAMSS_CSI1PIX_CLK>,
> + <&gcc GCC_CAMSS_CSI1RDI_CLK>,
> + <&gcc GCC_CAMSS_CSI2_CLK>,
> + <&gcc GCC_CAMSS_CSI2_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI2PHY_CLK>,
> + <&gcc GCC_CAMSS_CSI2PIX_CLK>,
> + <&gcc GCC_CAMSS_CSI2RDI_CLK>,
> + <&gcc GCC_CAMSS_CSI_VFE0_CLK>,
> + <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
> + <&gcc GCC_CAMSS_TOP_AHB_CLK>,
> + <&gcc GCC_CAMSS_VFE0_CLK>,
> + <&gcc GCC_CAMSS_VFE_AHB_CLK>,
> + <&gcc GCC_CAMSS_VFE_AXI_CLK>;
> +
> + clock-names = "ahb",
> + "csi0",
> + "csi0_ahb",
> + "csi0_phy",
> + "csi0_pix",
> + "csi0_rdi",
> + "csi1",
> + "csi1_ahb",
> + "csi1_phy",
> + "csi1_pix",
> + "csi1_rdi",
> + "csi2",
> + "csi2_ahb",
> + "csi2_phy",
> + "csi2_pix",
> + "csi2_rdi",
> + "csi_vfe0",
> + "csiphy0_timer",
> + "csiphy1_timer",
> + "ispif_ahb",
> + "top_ahb",
> + "vfe0",
> + "vfe_ahb",
> + "vfe_axi";
> +
> + interrupts = <GIC_SPI 51 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 52 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 153 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 55 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
> +
> + interrupt-names = "csid0",
> + "csid1",
> + "csid2",
> + "csiphy0",
> + "csiphy1",
> + "ispif",
> + "vfe0";
> +
> + iommus = <&apps_iommu 3>;
> +
> + power-domains = <&gcc VFE_GDSC>;
> +
> + vdda-supply = <®_1v2>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + csiphy1_ep: endpoint {
> + data-lanes = <0 2>;
> + remote-endpoint = <&sensor_ep>;
> + };
> + };
> + };
> + };
>
Hi Vincent.
Would appreciate if you could make the order of items here the same as
in 8916 per discussions with Krzysztof clarifying.
8916, 8939, 8953 are of a similar class of device so the correct
ordering here is as with 8916.
---
bod
On 13/06/2025 11:33, Vincent Knecht via B4 Relay wrote: > From: Vincent Knecht <vincent.knecht@mailoo.org> > > Add bindings for qcom,msm8939-camss in order to support the camera > subsystem for MSM8939. > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> > --- Also, still incorrect order of patches. Bindings come before their users. Best regards, Krzysztof
On 13/06/2025 11:33, Vincent Knecht via B4 Relay wrote: > From: Vincent Knecht <vincent.knecht@mailoo.org> > > Add bindings for qcom,msm8939-camss in order to support the camera > subsystem for MSM8939. > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Drop, you did here some unusual changes. > Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> > --- > .../bindings/media/qcom,msm8939-camss.yaml | 254 +++++++++++++++++++++ > 1 file changed, 254 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml > new file mode 100644 > index 0000000000000000000000000000000000000000..9fbb4b204ac8728b822864ad8336aa9d826d6b5b > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml > @@ -0,0 +1,254 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/qcom,msm8939-camss.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm MSM8939 Camera Subsystem (CAMSS) > + > +maintainers: > + - Vincent Knecht <vincent.knecht@mailoo.org> > + > +description: > + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms > + > +properties: > + compatible: > + const: qcom,msm8939-camss > + > + reg: > + maxItems: 11 > + > + reg-names: > + items: > + - const: csi_clk_mux No, I already provided arguments in two lengthy discussions - this is not sorted by name. Keep the same order as in previous device, so msm8916 for example. Or any other, but listen to some requests to sort it by some arbitrary rule which was never communicated by DT maintainers. > + - const: csid0 > + - const: csid1 > + - const: csid2 > + - const: csiphy0 > + - const: csiphy0_clk_mux > + - const: csiphy1 > + - const: csiphy1_clk_mux > + - const: ispif > + - const: vfe0 > + - const: vfe0_vbif > + > + clocks: > + maxItems: 24 > + > + clock-names: > + items: > + - const: ahb > + - const: csi0 > + - const: csi0_ahb > + - const: csi0_phy > + - const: csi0_pix > + - const: csi0_rdi > + - const: csi1 > + - const: csi1_ahb > + - const: csi1_phy > + - const: csi1_pix > + - const: csi1_rdi > + - const: csi2 > + - const: csi2_ahb > + - const: csi2_phy > + - const: csi2_pix > + - const: csi2_rdi > + - const: csi_vfe0 > + - const: csiphy0_timer > + - const: csiphy1_timer > + - const: ispif_ahb > + - const: top_ahb > + - const: vfe0 > + - const: vfe_ahb > + - const: vfe_axi > + Also messed up order. > + interrupts: > + maxItems: 7 > + > + interrupt-names: > + items: > + - const: csid0 > + - const: csid1 > + - const: csid2 > + - const: csiphy0 > + - const: csiphy1 > + - const: ispif > + - const: vfe0 As well. Best regards, Krzysztof
On 26/06/2025 11:00, Krzysztof Kozlowski wrote:
>> + reg-names:
>> + items:
>> + - const: csi_clk_mux
> No, I already provided arguments in two lengthy discussions - this is
> not sorted by name.
>
> Keep the same order as in previous device, so msm8916 for example. Or
> any other, but listen to some requests to sort it by some arbitrary rule
> which was never communicated by DT maintainers.
I don't think if you look through the history that you can find a
consistent rule that was used to arrange the registers.
So we are trying to have a consistent way of doing that. Thats why the
last number of additions have been sort by name, because it seemed to be
the most consistent.
commit c830aff08d51f8391e59fc6744757c58e320b41b
Author: Barnabás Czémán <barnabas.czeman@mainlining.org>
Date: Sun Nov 3 10:45:35 2024 +0100
media: dt-bindings: Add qcom,msm8953-camss
commit 2ab7f87a7f4bf392e3836a2600f115a1baa1415c
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date: Fri Mar 14 13:14:00 2025 +0000
dt-bindings: media: Add qcom,x1e80100-camss
commit c35ad8e3c59714e9cef96036edad1529e70d1a7a
Author: Depeng Shao <quic_depengs@quicinc.com>
Date: Mon Jan 13 10:01:29 2025 +0530
dt-bindings: media: camss: Add qcom,sm8550-camss binding
commit 0274ea59f83e4650c75b1a0370fbfa540bb88f9e
Author: Richard Acayan <mailingradian@gmail.com>
Date: Tue Feb 4 22:50:15 2025 -0500
dt-bindings: media: camss: Add qcom,sdm670-camss
commit 5593555343f3ec299ca28d46a478e718c1119f74
Author: Vikram Sharma <quic_vikramsa@quicinc.com>
Date: Sat Dec 7 00:48:56 2024 +0530
media: dt-bindings: Add qcom,sc7280-camss
---
bod
On 26/06/2025 12:19, Bryan O'Donoghue wrote: > On 26/06/2025 11:00, Krzysztof Kozlowski wrote: >>> + reg-names: >>> + items: >>> + - const: csi_clk_mux >> No, I already provided arguments in two lengthy discussions - this is >> not sorted by name. >> >> Keep the same order as in previous device, so msm8916 for example. Or >> any other, but listen to some requests to sort it by some arbitrary rule >> which was never communicated by DT maintainers. > > I don't think if you look through the history that you can find a > consistent rule that was used to arrange the registers. > > So we are trying to have a consistent way of doing that. Thats why the > last number of additions have been sort by name, because it seemed to be > the most consistent. Why are we discussing it again? You asked me the same here: https://lore.kernel.org/all/8f11c99b-f3ca-4501-aec4-0795643fc3a9@kernel.org/ and I already said - not sorting by name. You take the same order as previous. If you ever want to sort by name, answer to yourself: NO. Take the same order as other existing device. If you ever want to sort by value, answer to yourself: NO. You both came with some new, invented rules of sorting, applied it, and now you claim that "existing devices were sorted like that". What? NO! Best regards, Krzysztof
On 26/06/2025 11:28, Krzysztof Kozlowski wrote:
> On 26/06/2025 12:19, Bryan O'Donoghue wrote:
>> On 26/06/2025 11:00, Krzysztof Kozlowski wrote:
>>>> + reg-names:
>>>> + items:
>>>> + - const: csi_clk_mux
>>> No, I already provided arguments in two lengthy discussions - this is
>>> not sorted by name.
>>>
>>> Keep the same order as in previous device, so msm8916 for example. Or
>>> any other, but listen to some requests to sort it by some arbitrary rule
>>> which was never communicated by DT maintainers.
>>
>> I don't think if you look through the history that you can find a
>> consistent rule that was used to arrange the registers.
>>
>> So we are trying to have a consistent way of doing that. Thats why the
>> last number of additions have been sort by name, because it seemed to be
>> the most consistent.
>
>
> Why are we discussing it again? You asked me the same here:
> https://lore.kernel.org/all/8f11c99b-f3ca-4501-aec4-0795643fc3a9@kernel.org/
>
> and I already said - not sorting by name. You take the same order as
> previous.
>
> If you ever want to sort by name, answer to yourself:
> NO. Take the same order as other existing device.
>
> If you ever want to sort by value, answer to yourself:
> NO.
>
> You both came with some new, invented rules of sorting, applied it, and
> now you claim that "existing devices were sorted like that". What? NO!
>
> Best regards,
> Krzysztof
OK.
Discussed this on Slack with Krzysztof.
8939 should be like 8916 because these are devices of a similar class.
x1e has a particular order if a new device x1e+1 comes along with a new
register then
reg-names:
23 items:
24 - const: csid0
25 - const: csid1
26 - const: csid2
27 - const: csid_lite0
28 - const: csid_lite1
29 - const: csid_wrapper
30 - const: csiphy0
31 - const: csiphy1
32 - const: csiphy2
33 - const: csiphy4
34 - const: csitpg0
35 - const: csitpg1
36 - const: csitpg2
37 - const: vfe0
38 - const: vfe1
39 - const: vfe_lite0
40 - const: vfe_lite1
reg-names:
23 items:
24 - const: csid0
25 - const: csid1
26 - const: csid2
27 - const: csid_lite0
28 - const: csid_lite1
29 - const: csid_wrapper
30 - const: csiphy0
31 - const: csiphy1
32 - const: csiphy2
33 - const: csiphy4
34 - const: csitpg0
35 - const: csitpg1
36 - const: csitpg2
37 - const: vfe0
38 - const: vfe1
39 - const: vfe_lite0
40 - const: vfe_lite1
- NEW ENTRY GOES HERE csid3
A new SoC with a significantly different architecture could have
different ordering of regs.
The main block should go first which means the above should look like:
reg-names:
23 items:
24 - const: csid_wrapper
25 - const: csid0
26 - const: csid1
27 - const: csid2
28 - const: csid_lite0
29 - const: csid_lite1
30 - const: csiphy0
31 - const: csiphy1
32 - const: csiphy2
33 - const: csiphy4
34 - const: csitpg0
35 - const: csitpg1
36 - const: csitpg2
37 - const: vfe0
38 - const: vfe1
39 - const: vfe_lite0
40 - const: vfe_lite1
I think I personally haven't understood what was meant by "devices of a
class" but its clearer now.
Appreciate the explanation.
---
bod
On 6/26/25 13:48, Bryan O'Donoghue wrote:
> On 26/06/2025 11:28, Krzysztof Kozlowski wrote:
>> On 26/06/2025 12:19, Bryan O'Donoghue wrote:
>>> On 26/06/2025 11:00, Krzysztof Kozlowski wrote:
>>>>> + reg-names:
>>>>> + items:
>>>>> + - const: csi_clk_mux
>>>> No, I already provided arguments in two lengthy discussions - this is
>>>> not sorted by name.
>>>>
>>>> Keep the same order as in previous device, so msm8916 for example. Or
>>>> any other, but listen to some requests to sort it by some arbitrary rule
>>>> which was never communicated by DT maintainers.
>>>
>>> I don't think if you look through the history that you can find a
>>> consistent rule that was used to arrange the registers.
>>>
>>> So we are trying to have a consistent way of doing that. Thats why the
>>> last number of additions have been sort by name, because it seemed to be
>>> the most consistent.
>>
>>
>> Why are we discussing it again? You asked me the same here:
>> https://lore.kernel.org/all/8f11c99b-f3ca-4501-aec4-0795643fc3a9@kernel.org/
>>
>> and I already said - not sorting by name. You take the same order as
>> previous.
>>
>> If you ever want to sort by name, answer to yourself:
>> NO. Take the same order as other existing device.
>>
>> If you ever want to sort by value, answer to yourself:
>> NO.
>>
>> You both came with some new, invented rules of sorting, applied it, and
>> now you claim that "existing devices were sorted like that". What? NO!
>>
>> Best regards,
>> Krzysztof
>
> OK.
>
> Discussed this on Slack with Krzysztof.
The problem with private communications is that it produces
sacral knowledge.
> 8939 should be like 8916 because these are devices of a similar class.
>
What's about MSM8953 then?
Please see commit c830aff08d51 ("media: dt-bindings: Add qcom,msm8953-camss").
> x1e has a particular order if a new device x1e+1 comes along with a new
> register then
>
>
> I think I personally haven't understood what was meant by "devices of a
> class" but its clearer now.
>
And I still didn't get it, how to read this "devices of a class"?
In particular why is MSM8939 a device of MSM8916 class and MSM8953 is
not?
For sake of simplicity I list only accepted CAMSS dt bindings:
qcom,msm8916-camss.yaml
qcom,msm8953-camss.yaml
qcom,msm8996-camss.yaml
qcom,sc7280-camss.yaml
qcom,sc8280xp-camss.yaml
qcom,sdm660-camss.yaml
qcom,sdm670-camss.yaml
qcom,sdm845-camss.yaml
qcom,sm8250-camss.yaml
qcom,sm8550-camss.yaml
qcom,x1e80100-camss.yaml
I kindly ask to select a number of class defining IPs from the list,
so that all next ones will derive from those only, and not from
"another class". It's a task for a DT maintainer I presume.
Before completing this and getting a common understanding all next
work to provide CAMSS suppor for new platforms is not directed by
any policy, because the policy "do as it's been done before" is
applied inconsistently.
--
Best wishes,
Vladimir
On 26/06/2025 12:17, Vladimir Zapolskiy wrote:
> What's about MSM8953 then?
Should be fixed up to match 8916. We don't have an upstream user and we,
I, did the wrong thing.
> Please see commit c830aff08d51 ("media: dt-bindings: Add qcom,msm8953-
> camss").
>
>> x1e has a particular order if a new device x1e+1 comes along with a new
>> register then
>>
>
>>
>> I think I personally haven't understood what was meant by "devices of a
>> class" but its clearer now.
>>
>
> And I still didn't get it, how to read this "devices of a class"?
>
> In particular why is MSM8939 a device of MSM8916 class and MSM8953 is
> not?
>
> For sake of simplicity I list only accepted CAMSS dt bindings:
>
> qcom,msm8916-camss.yaml
> qcom,msm8953-camss.yaml
> qcom,msm8996-camss.yaml
> qcom,sc7280-camss.yaml
> qcom,sc8280xp-camss.yaml
> qcom,sdm660-camss.yaml
> qcom,sdm670-camss.yaml
> qcom,sdm845-camss.yaml
> qcom,sm8250-camss.yaml
> qcom,sm8550-camss.yaml
> qcom,x1e80100-camss.yaml
I mean some old commits in Linux wouldn't make it through the
upstreaming process now.
8953 is not right and can be changed.
8250, 845 may have bindings we wouldn't accept now but they have users
so we live with them.
> I kindly ask to select a number of class defining IPs from the list,
> so that all next ones will derive from those only, and not from
> "another class". It's a task for a DT maintainer I presume.
>
> Before completing this and getting a common understanding all next
> work to provide CAMSS suppor for new platforms is not directed by
> any policy, because the policy "do as it's been done before" is
> applied inconsistently.
>
I think I personally am clear on the rule from the DT people, even if I
may not get it right on subsequient submissions.
The sort order thing is a red herring, in simple terms. We should be
consistent in device classes.
For example TITAN 680 and 690 should look pretty similar, TITAN 340 and
990 probably can have greater divergence.
Either way the sort order thing is a dead end, anything upstream on that
basis like x1e is probably fine because it is of its particular class of
device.
8953 and 8939 should match their device class of 8916.
---
bod
On 6/13/25 12:33, Vincent Knecht via B4 Relay wrote: > From: Vincent Knecht <vincent.knecht@mailoo.org> > > Add bindings for qcom,msm8939-camss in order to support the camera > subsystem for MSM8939. > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> -- Best wishes, Vladimir
On 13/06/2025 10:33, Vincent Knecht via B4 Relay wrote:
> From: Vincent Knecht <vincent.knecht@mailoo.org>
>
> Add bindings for qcom,msm8939-camss in order to support the camera
> subsystem for MSM8939.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org>
> ---
> .../bindings/media/qcom,msm8939-camss.yaml | 254 +++++++++++++++++++++
> 1 file changed, 254 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..9fbb4b204ac8728b822864ad8336aa9d826d6b5b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml
> @@ -0,0 +1,254 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/qcom,msm8939-camss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm MSM8939 Camera Subsystem (CAMSS)
> +
> +maintainers:
> + - Vincent Knecht <vincent.knecht@mailoo.org>
> +
> +description:
> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
> +
> +properties:
> + compatible:
> + const: qcom,msm8939-camss
> +
> + reg:
> + maxItems: 11
> +
> + reg-names:
> + items:
> + - const: csi_clk_mux
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csiphy0
> + - const: csiphy0_clk_mux
> + - const: csiphy1
> + - const: csiphy1_clk_mux
> + - const: ispif
> + - const: vfe0
> + - const: vfe0_vbif
> +
> + clocks:
> + maxItems: 24
> +
> + clock-names:
> + items:
> + - const: ahb
> + - const: csi0
> + - const: csi0_ahb
> + - const: csi0_phy
> + - const: csi0_pix
> + - const: csi0_rdi
> + - const: csi1
> + - const: csi1_ahb
> + - const: csi1_phy
> + - const: csi1_pix
> + - const: csi1_rdi
> + - const: csi2
> + - const: csi2_ahb
> + - const: csi2_phy
> + - const: csi2_pix
> + - const: csi2_rdi
> + - const: csi_vfe0
> + - const: csiphy0_timer
> + - const: csiphy1_timer
> + - const: ispif_ahb
> + - const: top_ahb
> + - const: vfe0
> + - const: vfe_ahb
> + - const: vfe_axi
> +
> + interrupts:
> + maxItems: 7
> +
> + interrupt-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csiphy0
> + - const: csiphy1
> + - const: ispif
> + - const: vfe0
> +
> + iommus:
> + maxItems: 1
> +
> + power-domains:
> + items:
> + - description: VFE GDSC - Video Front End, Global Distributed Switch
> + Controller.
> +
> + vdda-supply:
> + description:
> + Definition of the regulator used as 1.2V analog power supply.
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + description:
> + CSI input ports.
> +
> + patternProperties:
> + "^port@[0-1]$":
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> +
> + description:
> + Input port for receiving CSI data.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + bus-type:
> + enum:
> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
> +
> + required:
> + - data-lanes
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-names
> + - iommus
> + - power-domains
> + - vdda-supply
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,gcc-msm8939.h>
> +
> + isp@1b00020 {
> + compatible = "qcom,msm8939-camss";
> +
> + reg = <0x01b00020 0x10>,
> + <0x01b08000 0x100>,
> + <0x01b08400 0x100>,
> + <0x01b08800 0x100>,
> + <0x01b0ac00 0x200>,
> + <0x01b00030 0x4>,
> + <0x01b0b000 0x200>,
> + <0x01b00038 0x4>,
> + <0x01b0a000 0x500>,
> + <0x01b10000 0x1000>,
> + <0x01b40000 0x200>;
> +
> + reg-names = "csi_clk_mux",
> + "csid0",
> + "csid1",
> + "csid2",
> + "csiphy0",
> + "csiphy0_clk_mux",
> + "csiphy1",
> + "csiphy1_clk_mux",
> + "ispif",
> + "vfe0",
> + "vfe0_vbif";
> +
> + clocks = <&gcc GCC_CAMSS_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI0_CLK>,
> + <&gcc GCC_CAMSS_CSI0_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI0PHY_CLK>,
> + <&gcc GCC_CAMSS_CSI0PIX_CLK>,
> + <&gcc GCC_CAMSS_CSI0RDI_CLK>,
> + <&gcc GCC_CAMSS_CSI1_CLK>,
> + <&gcc GCC_CAMSS_CSI1_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI1PHY_CLK>,
> + <&gcc GCC_CAMSS_CSI1PIX_CLK>,
> + <&gcc GCC_CAMSS_CSI1RDI_CLK>,
> + <&gcc GCC_CAMSS_CSI2_CLK>,
> + <&gcc GCC_CAMSS_CSI2_AHB_CLK>,
> + <&gcc GCC_CAMSS_CSI2PHY_CLK>,
> + <&gcc GCC_CAMSS_CSI2PIX_CLK>,
> + <&gcc GCC_CAMSS_CSI2RDI_CLK>,
> + <&gcc GCC_CAMSS_CSI_VFE0_CLK>,
> + <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
> + <&gcc GCC_CAMSS_TOP_AHB_CLK>,
> + <&gcc GCC_CAMSS_VFE0_CLK>,
> + <&gcc GCC_CAMSS_VFE_AHB_CLK>,
> + <&gcc GCC_CAMSS_VFE_AXI_CLK>;
> +
> + clock-names = "ahb",
> + "csi0",
> + "csi0_ahb",
> + "csi0_phy",
> + "csi0_pix",
> + "csi0_rdi",
> + "csi1",
> + "csi1_ahb",
> + "csi1_phy",
> + "csi1_pix",
> + "csi1_rdi",
> + "csi2",
> + "csi2_ahb",
> + "csi2_phy",
> + "csi2_pix",
> + "csi2_rdi",
> + "csi_vfe0",
> + "csiphy0_timer",
> + "csiphy1_timer",
> + "ispif_ahb",
> + "top_ahb",
> + "vfe0",
> + "vfe_ahb",
> + "vfe_axi";
> +
> + interrupts = <GIC_SPI 51 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 52 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 153 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 55 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
> +
> + interrupt-names = "csid0",
> + "csid1",
> + "csid2",
> + "csiphy0",
> + "csiphy1",
> + "ispif",
> + "vfe0";
> +
> + iommus = <&apps_iommu 3>;
> +
> + power-domains = <&gcc VFE_GDSC>;
> +
> + vdda-supply = <®_1v2>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + csiphy1_ep: endpoint {
> + data-lanes = <0 2>;
> + remote-endpoint = <&sensor_ep>;
> + };
> + };
> + };
> + };
>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
© 2016 - 2025 Red Hat, Inc.