Add bindings for the Camera Subsystem on the SM6350 SoC.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
.../bindings/media/qcom,sm6350-camss.yaml | 349 +++++++++++++++++++++
1 file changed, 349 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,sm6350-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm6350-camss.yaml
new file mode 100644
index 000000000000..e816986c8d84
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm6350-camss.yaml
@@ -0,0 +1,349 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sm6350-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6350 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,sm6350-camss
+
+ reg:
+ maxItems: 12
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite
+
+ clocks:
+ maxItems: 30
+
+ clock-names:
+ items:
+ - const: cam_ahb_clk
+ - const: cam_axi
+ - const: soc_ahb
+ - const: camnoc_axi
+ - const: core_ahb
+ - const: cpas_ahb
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: slow_ahb_src
+ - const: vfe0_axi
+ - const: vfe0
+ - const: vfe0_cphy_rx
+ - const: vfe0_csid
+ - const: vfe1_axi
+ - const: vfe1
+ - const: vfe1_cphy_rx
+ - const: vfe1_csid
+ - const: vfe2_axi
+ - const: vfe2
+ - const: vfe2_cphy_rx
+ - const: vfe2_csid
+ - const: vfe_lite
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+
+ interrupts:
+ maxItems: 12
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: cam_ahb
+ - const: cam_hf_0_mnoc
+ - const: cam_sf_0_mnoc
+ - const: cam_sf_icp_mnoc
+
+ 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: IFE2 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: ife2
+ - const: top
+
+ vdda-0.9-supply:
+ description:
+ Phandle to a 0.9V regulator supply to a PHY.
+
+ vdda-1.25-supply:
+ description:
+ Phandle to a 1.25V regulator supply to a PHY.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ patternProperties:
+ "^port@[0-3]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ description:
+ Input port for receiving CSI data from a CSIPHY.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - vdda-0.9-supply
+ - vdda-1.25-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm6350.h>
+ #include <dt-bindings/clock/qcom,sm6350-camcc.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,sm6350.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/media/video-interfaces.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@acb3000 {
+ compatible = "qcom,sm6350-camss";
+
+ reg = <0x0 0x0acb3000 0x0 0x1000>,
+ <0x0 0x0acba000 0x0 0x1000>,
+ <0x0 0x0acc1000 0x0 0x1000>,
+ <0x0 0x0acc8000 0x0 0x1000>,
+ <0x0 0x0ac65000 0x0 0x1000>,
+ <0x0 0x0ac66000 0x0 0x1000>,
+ <0x0 0x0ac67000 0x0 0x1000>,
+ <0x0 0x0ac68000 0x0 0x1000>,
+ <0x0 0x0acaf000 0x0 0x4000>,
+ <0x0 0x0acb6000 0x0 0x4000>,
+ <0x0 0x0acbd000 0x0 0x4000>,
+ <0x0 0x0acc4000 0x0 0x4000>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite";
+
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&gcc GCC_CAMERA_AXI_CLK>,
+ <&camcc CAMCC_SOC_AHB_CLK>,
+ <&camcc CAMCC_CAMNOC_AXI_CLK>,
+ <&camcc CAMCC_CORE_AHB_CLK>,
+ <&camcc CAMCC_CPAS_AHB_CLK>,
+ <&camcc CAMCC_CSIPHY0_CLK>,
+ <&camcc CAMCC_CSI0PHYTIMER_CLK>,
+ <&camcc CAMCC_CSIPHY1_CLK>,
+ <&camcc CAMCC_CSI1PHYTIMER_CLK>,
+ <&camcc CAMCC_CSIPHY2_CLK>,
+ <&camcc CAMCC_CSI2PHYTIMER_CLK>,
+ <&camcc CAMCC_CSIPHY3_CLK>,
+ <&camcc CAMCC_CSI3PHYTIMER_CLK>,
+ <&camcc CAMCC_SLOW_AHB_CLK_SRC>,
+ <&camcc CAMCC_IFE_0_AXI_CLK>,
+ <&camcc CAMCC_IFE_0_CLK>,
+ <&camcc CAMCC_IFE_0_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_0_CSID_CLK>,
+ <&camcc CAMCC_IFE_1_AXI_CLK>,
+ <&camcc CAMCC_IFE_1_CLK>,
+ <&camcc CAMCC_IFE_1_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_1_CSID_CLK>,
+ <&camcc CAMCC_IFE_2_AXI_CLK>,
+ <&camcc CAMCC_IFE_2_CLK>,
+ <&camcc CAMCC_IFE_2_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_2_CSID_CLK>,
+ <&camcc CAMCC_IFE_LITE_CLK>,
+ <&camcc CAMCC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_LITE_CSID_CLK>;
+ clock-names = "cam_ahb_clk",
+ "cam_axi",
+ "soc_ahb",
+ "camnoc_axi",
+ "core_ahb",
+ "cpas_ahb",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "slow_ahb_src",
+ "vfe0_axi",
+ "vfe0",
+ "vfe0_cphy_rx",
+ "vfe0_csid",
+ "vfe1_axi",
+ "vfe1",
+ "vfe1_cphy_rx",
+ "vfe1_csid",
+ "vfe2_axi",
+ "vfe2",
+ "vfe2_cphy_rx",
+ "vfe2_csid",
+ "vfe_lite",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ interrupts = <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 717 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 461 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 718 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite";
+
+ interconnects = <&gem_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &clk_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS
+ &clk_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_ICP QCOM_ICC_TAG_ALWAYS
+ &clk_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "cam_ahb",
+ "cam_hf_0_mnoc",
+ "cam_sf_0_mnoc",
+ "cam_sf_icp_mnoc";
+
+ iommus = <&apps_smmu 0x820 0xc0>,
+ <&apps_smmu 0x840 0x0>,
+ <&apps_smmu 0x860 0xc0>,
+ <&apps_smmu 0x880 0x0>;
+
+ power-domains = <&camcc IFE_0_GDSC>,
+ <&camcc IFE_1_GDSC>,
+ <&camcc IFE_2_GDSC>,
+ <&camcc TITAN_TOP_GDSC>;
+ power-domain-names = "ife0",
+ "ife1",
+ "ife2",
+ "top";
+
+ vdda-0.9-supply = <&vreg_l18a>;
+ vdda-1.25-supply = <&vreg_l22a>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ csiphy0_ep: endpoint {
+ data-lanes = <0 1 2 3>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
--
2.51.1On Fri, Oct 24, 2025 at 02:23:59PM +0200, Luca Weiss wrote: + > + clock-names: > + items: > + - const: cam_ahb_clk > + - const: cam_axi > + - const: soc_ahb > + - const: camnoc_axi > + - const: core_ahb > + - const: cpas_ahb > + - const: csiphy0 > + - const: csiphy0_timer > + - const: csiphy1 > + - const: csiphy1_timer > + - const: csiphy2 > + - const: csiphy2_timer > + - const: csiphy3 > + - const: csiphy3_timer > + - const: slow_ahb_src > + - const: vfe0_axi > + - const: vfe0 > + - const: vfe0_cphy_rx > + - const: vfe0_csid > + - const: vfe1_axi > + - const: vfe1 > + - const: vfe1_cphy_rx > + - const: vfe1_csid > + - const: vfe2_axi > + - const: vfe2 > + - const: vfe2_cphy_rx > + - const: vfe2_csid > + - const: vfe_lite > + - const: vfe_lite_cphy_rx > + - const: vfe_lite_csid > + > + interrupts: > + maxItems: 12 > + > + interrupt-names: > + items: > + - const: csid0 > + - const: csid1 > + - const: csid2 > + - const: csid_lite > + - const: csiphy0 > + - const: csiphy1 > + - const: csiphy2 > + - const: csiphy3 > + - const: vfe0 > + - const: vfe1 > + - const: vfe2 > + - const: vfe_lite > + > + interconnects: > + maxItems: 4 > + > + interconnect-names: > + items: > + - const: cam_ahb > + - const: cam_hf_0_mnoc > + - const: cam_sf_0_mnoc > + - const: cam_sf_icp_mnoc Please share the list with the previous generation of this device. Which one was used here as "previous"? For example x1e has quite different names - nothing with "cam". No "cam" in qcs8300, either. > + > + iommus: > + maxItems: 4 I was told iommus might differ. Are you sure all of them represent the same (e.g. not specific iommus for specific purposes)? > + > + power-domains: > + items: > + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. > + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. > + - description: IFE2 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: ife2 > + - const: top Uh, not your fault, but who came with this list in previous generations? Instead of simple and obvious "top+ifeX" which allows growing/shrinking, someone put "top" at the end which means this cannot follow same order as X1E for example... Heh, it follows at least sm8550. > + > + vdda-0.9-supply: There are no dots in property names. Are you sure these are called VDDA_0.9 in the device datasheet (not schematics)? Please look at other bindings how this is being named, depending whether this is PHY or PLL supply (or only PHY). > + description: > + Phandle to a 0.9V regulator supply to a PHY. > + > + vdda-1.25-supply: > + description: > + Phandle to a 1.25V regulator supply to a PHY. Best regards, Krzysztof
Hi Krzysztof,
On Tue Oct 28, 2025 at 9:54 AM CET, Krzysztof Kozlowski wrote:
> On Fri, Oct 24, 2025 at 02:23:59PM +0200, Luca Weiss wrote:
> +
>> + clock-names:
>> + items:
>> + - const: cam_ahb_clk
>> + - const: cam_axi
>> + - const: soc_ahb
>> + - const: camnoc_axi
>> + - const: core_ahb
>> + - const: cpas_ahb
>> + - const: csiphy0
>> + - const: csiphy0_timer
>> + - const: csiphy1
>> + - const: csiphy1_timer
>> + - const: csiphy2
>> + - const: csiphy2_timer
>> + - const: csiphy3
>> + - const: csiphy3_timer
>> + - const: slow_ahb_src
>> + - const: vfe0_axi
>> + - const: vfe0
>> + - const: vfe0_cphy_rx
>> + - const: vfe0_csid
>> + - const: vfe1_axi
>> + - const: vfe1
>> + - const: vfe1_cphy_rx
>> + - const: vfe1_csid
>> + - const: vfe2_axi
>> + - const: vfe2
>> + - const: vfe2_cphy_rx
>> + - const: vfe2_csid
>> + - const: vfe_lite
>> + - const: vfe_lite_cphy_rx
>> + - const: vfe_lite_csid
>> +
>> + interrupts:
>> + maxItems: 12
>> +
>> + interrupt-names:
>> + items:
>> + - const: csid0
>> + - const: csid1
>> + - const: csid2
>> + - const: csid_lite
>> + - const: csiphy0
>> + - const: csiphy1
>> + - const: csiphy2
>> + - const: csiphy3
>> + - const: vfe0
>> + - const: vfe1
>> + - const: vfe2
>> + - const: vfe_lite
>> +
>> + interconnects:
>> + maxItems: 4
>> +
>> + interconnect-names:
>> + items:
>> + - const: cam_ahb
>> + - const: cam_hf_0_mnoc
>> + - const: cam_sf_0_mnoc
>> + - const: cam_sf_icp_mnoc
>
> Please share the list with the previous generation of this device. Which
> one was used here as "previous"? For example x1e has quite different
> names - nothing with "cam". No "cam" in qcs8300, either.
sm8250 is the big sibling for sm6350, so it's matching the names from
there upstream. These exact names are also used downstream for
"qcom,msm-bus,name".
I don't think there's anything preventing removing the cam_ prefix though.
>
>
>> +
>> + iommus:
>> + maxItems: 4
>
> I was told iommus might differ. Are you sure all of them represent the
> same (e.g. not specific iommus for specific purposes)?
I don't really know.
These 4 iommus are labelled 'msm_cam_smmu_ife' downstream. There's still
more iommus for more hardware blocks: jpeg, icp, cpas_cdm and lrme.
Maybe someone from Qualcomm/Linaro can explain this further if
necessary?
>
>> +
>> + power-domains:
>> + items:
>> + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
>> + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
>> + - description: IFE2 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: ife2
>> + - const: top
>
> Uh, not your fault, but who came with this list in previous generations?
> Instead of simple and obvious "top+ifeX" which allows growing/shrinking,
> someone put "top" at the end which means this cannot follow same order
> as X1E for example... Heh, it follows at least sm8550.
Shall we put top as first power-domain? I don't think it's an issue to
change the order.
>
>
>> +
>> + vdda-0.9-supply:
>
> There are no dots in property names. Are you sure these are called
> VDDA_0.9 in the device datasheet (not schematics)? Please look at other
> bindings how this is being named, depending whether this is PHY or PLL
> supply (or only PHY).
The following power supplies are mentioned:
* VDD_CAMSS_PLL_0P9 - Camera SS PLL 0.9 V circuits
(not referenced in downstream kernel, connected to vreg_s5a in
schematics)
* VDD_A_CSI_x_0P9 - MIPI CSIx 0.9 V circuits
With pad names VDD_A_CSI_0_0P9 to VDD_A_CSI_3_0P9
* VDD_A_CSI_x_1P25 - MIPI CSIx 1.25 V circuits
With pad names VDD_A_CSI_0_1P25 to VDD_A_CSI_3_1P25
Regards
Luca
>
>
>> + description:
>> + Phandle to a 0.9V regulator supply to a PHY.
>> +
>> + vdda-1.25-supply:
>> + description:
>> + Phandle to a 1.25V regulator supply to a PHY.
>
> Best regards,
> Krzysztof
On 10/28/25 10:24 AM, Luca Weiss wrote: > Hi Krzysztof, > > On Tue Oct 28, 2025 at 9:54 AM CET, Krzysztof Kozlowski wrote: >> On Fri, Oct 24, 2025 at 02:23:59PM +0200, Luca Weiss wrote: [...] >> There are no dots in property names. Are you sure these are called >> VDDA_0.9 in the device datasheet (not schematics)? Please look at other >> bindings how this is being named, depending whether this is PHY or PLL >> supply (or only PHY). > > The following power supplies are mentioned: > > * VDD_CAMSS_PLL_0P9 - Camera SS PLL 0.9 V circuits > (not referenced in downstream kernel, connected to vreg_s5a in > schematics) > * VDD_A_CSI_x_0P9 - MIPI CSIx 0.9 V circuits > With pad names VDD_A_CSI_0_0P9 to VDD_A_CSI_3_0P9 > * VDD_A_CSI_x_1P25 - MIPI CSIx 1.25 V circuits > With pad names VDD_A_CSI_0_1P25 to VDD_A_CSI_3_1P25 I can corroborate this Konrad
On 28/10/2025 10:24, Luca Weiss wrote: > Hi Krzysztof, > > On Tue Oct 28, 2025 at 9:54 AM CET, Krzysztof Kozlowski wrote: >> On Fri, Oct 24, 2025 at 02:23:59PM +0200, Luca Weiss wrote: >> + >>> + clock-names: >>> + items: >>> + - const: cam_ahb_clk >>> + - const: cam_axi >>> + - const: soc_ahb >>> + - const: camnoc_axi >>> + - const: core_ahb >>> + - const: cpas_ahb >>> + - const: csiphy0 >>> + - const: csiphy0_timer >>> + - const: csiphy1 >>> + - const: csiphy1_timer >>> + - const: csiphy2 >>> + - const: csiphy2_timer >>> + - const: csiphy3 >>> + - const: csiphy3_timer >>> + - const: slow_ahb_src >>> + - const: vfe0_axi >>> + - const: vfe0 >>> + - const: vfe0_cphy_rx >>> + - const: vfe0_csid >>> + - const: vfe1_axi >>> + - const: vfe1 >>> + - const: vfe1_cphy_rx >>> + - const: vfe1_csid >>> + - const: vfe2_axi >>> + - const: vfe2 >>> + - const: vfe2_cphy_rx >>> + - const: vfe2_csid >>> + - const: vfe_lite >>> + - const: vfe_lite_cphy_rx >>> + - const: vfe_lite_csid >>> + >>> + interrupts: >>> + maxItems: 12 >>> + >>> + interrupt-names: >>> + items: >>> + - const: csid0 >>> + - const: csid1 >>> + - const: csid2 >>> + - const: csid_lite >>> + - const: csiphy0 >>> + - const: csiphy1 >>> + - const: csiphy2 >>> + - const: csiphy3 >>> + - const: vfe0 >>> + - const: vfe1 >>> + - const: vfe2 >>> + - const: vfe_lite >>> + >>> + interconnects: >>> + maxItems: 4 >>> + >>> + interconnect-names: >>> + items: >>> + - const: cam_ahb >>> + - const: cam_hf_0_mnoc >>> + - const: cam_sf_0_mnoc >>> + - const: cam_sf_icp_mnoc >> >> Please share the list with the previous generation of this device. Which >> one was used here as "previous"? For example x1e has quite different >> names - nothing with "cam". No "cam" in qcs8300, either. > > sm8250 is the big sibling for sm6350, so it's matching the names from Ah, ok, good to know. > there upstream. These exact names are also used downstream for > "qcom,msm-bus,name". > > I don't think there's anything preventing removing the cam_ prefix though. Let's use the X1E names here. > >> >> >>> + >>> + iommus: >>> + maxItems: 4 >> >> I was told iommus might differ. Are you sure all of them represent the >> same (e.g. not specific iommus for specific purposes)? > > I don't really know. > > These 4 iommus are labelled 'msm_cam_smmu_ife' downstream. There's still > more iommus for more hardware blocks: jpeg, icp, cpas_cdm and lrme. OK, that's fine then. > > Maybe someone from Qualcomm/Linaro can explain this further if > necessary? > >> >>> + >>> + power-domains: >>> + items: >>> + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. >>> + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. >>> + - description: IFE2 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: ife2 >>> + - const: top >> >> Uh, not your fault, but who came with this list in previous generations? >> Instead of simple and obvious "top+ifeX" which allows growing/shrinking, >> someone put "top" at the end which means this cannot follow same order >> as X1E for example... Heh, it follows at least sm8550. > > Shall we put top as first power-domain? I don't think it's an issue to > change the order. Well, it matches sm8550, so I am just grumpy complaining. It's fine. > >> >> >>> + >>> + vdda-0.9-supply: >> >> There are no dots in property names. Are you sure these are called >> VDDA_0.9 in the device datasheet (not schematics)? Please look at other >> bindings how this is being named, depending whether this is PHY or PLL >> supply (or only PHY). > > The following power supplies are mentioned: > > * VDD_CAMSS_PLL_0P9 - Camera SS PLL 0.9 V circuits > (not referenced in downstream kernel, connected to vreg_s5a in > schematics) So that's vdda-pll-supply > * VDD_A_CSI_x_0P9 - MIPI CSIx 0.9 V circuits > With pad names VDD_A_CSI_0_0P9 to VDD_A_CSI_3_0P9 vdd-csiphy-0p9-supply > * VDD_A_CSI_x_1P25 - MIPI CSIx 1.25 V circuits > With pad names VDD_A_CSI_0_1P25 to VDD_A_CSI_3_1P25 vdd-csiphy-1p25-supply Best regards, Krzysztof
On Tue Oct 28, 2025 at 10:46 AM CET, Krzysztof Kozlowski wrote: > On 28/10/2025 10:24, Luca Weiss wrote: >> Hi Krzysztof, >> >> On Tue Oct 28, 2025 at 9:54 AM CET, Krzysztof Kozlowski wrote: >>> On Fri, Oct 24, 2025 at 02:23:59PM +0200, Luca Weiss wrote: >>> + >>>> + clock-names: >>>> + items: >>>> + - const: cam_ahb_clk >>>> + - const: cam_axi >>>> + - const: soc_ahb >>>> + - const: camnoc_axi >>>> + - const: core_ahb >>>> + - const: cpas_ahb >>>> + - const: csiphy0 >>>> + - const: csiphy0_timer >>>> + - const: csiphy1 >>>> + - const: csiphy1_timer >>>> + - const: csiphy2 >>>> + - const: csiphy2_timer >>>> + - const: csiphy3 >>>> + - const: csiphy3_timer >>>> + - const: slow_ahb_src >>>> + - const: vfe0_axi >>>> + - const: vfe0 >>>> + - const: vfe0_cphy_rx >>>> + - const: vfe0_csid >>>> + - const: vfe1_axi >>>> + - const: vfe1 >>>> + - const: vfe1_cphy_rx >>>> + - const: vfe1_csid >>>> + - const: vfe2_axi >>>> + - const: vfe2 >>>> + - const: vfe2_cphy_rx >>>> + - const: vfe2_csid >>>> + - const: vfe_lite >>>> + - const: vfe_lite_cphy_rx >>>> + - const: vfe_lite_csid >>>> + >>>> + interrupts: >>>> + maxItems: 12 >>>> + >>>> + interrupt-names: >>>> + items: >>>> + - const: csid0 >>>> + - const: csid1 >>>> + - const: csid2 >>>> + - const: csid_lite >>>> + - const: csiphy0 >>>> + - const: csiphy1 >>>> + - const: csiphy2 >>>> + - const: csiphy3 >>>> + - const: vfe0 >>>> + - const: vfe1 >>>> + - const: vfe2 >>>> + - const: vfe_lite >>>> + >>>> + interconnects: >>>> + maxItems: 4 >>>> + >>>> + interconnect-names: >>>> + items: >>>> + - const: cam_ahb >>>> + - const: cam_hf_0_mnoc >>>> + - const: cam_sf_0_mnoc >>>> + - const: cam_sf_icp_mnoc >>> >>> Please share the list with the previous generation of this device. Which >>> one was used here as "previous"? For example x1e has quite different >>> names - nothing with "cam". No "cam" in qcs8300, either. >> >> sm8250 is the big sibling for sm6350, so it's matching the names from > > Ah, ok, good to know. > >> there upstream. These exact names are also used downstream for >> "qcom,msm-bus,name". >> >> I don't think there's anything preventing removing the cam_ prefix though. > > Let's use the X1E names here. > >> >>> >>> >>>> + >>>> + iommus: >>>> + maxItems: 4 >>> >>> I was told iommus might differ. Are you sure all of them represent the >>> same (e.g. not specific iommus for specific purposes)? >> >> I don't really know. >> >> These 4 iommus are labelled 'msm_cam_smmu_ife' downstream. There's still >> more iommus for more hardware blocks: jpeg, icp, cpas_cdm and lrme. > > OK, that's fine then. > >> >> Maybe someone from Qualcomm/Linaro can explain this further if >> necessary? >> >>> >>>> + >>>> + power-domains: >>>> + items: >>>> + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. >>>> + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. >>>> + - description: IFE2 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: ife2 >>>> + - const: top >>> >>> Uh, not your fault, but who came with this list in previous generations? >>> Instead of simple and obvious "top+ifeX" which allows growing/shrinking, >>> someone put "top" at the end which means this cannot follow same order >>> as X1E for example... Heh, it follows at least sm8550. >> >> Shall we put top as first power-domain? I don't think it's an issue to >> change the order. > > Well, it matches sm8550, so I am just grumpy complaining. It's fine. > >> >>> >>> >>>> + >>>> + vdda-0.9-supply: >>> >>> There are no dots in property names. Are you sure these are called >>> VDDA_0.9 in the device datasheet (not schematics)? Please look at other >>> bindings how this is being named, depending whether this is PHY or PLL >>> supply (or only PHY). >> >> The following power supplies are mentioned: >> >> * VDD_CAMSS_PLL_0P9 - Camera SS PLL 0.9 V circuits >> (not referenced in downstream kernel, connected to vreg_s5a in >> schematics) > > So that's vdda-pll-supply Just noticed, this S5A regulator is the MX power-domain, so we cannot add it as vdda-pll-supply. From what I can see, so far no other camss bindings take in an rpmhpd power domain, and given it's not referenced in downstream kernel, it doesn't look like it's necessary to control it, from camss. Maybe it should be added to camcc though? Still not quite sure how downstream vdd_class should translate to upstream... Thanks for helping with the other points, those are clear. Regards Luca > >> * VDD_A_CSI_x_0P9 - MIPI CSIx 0.9 V circuits >> With pad names VDD_A_CSI_0_0P9 to VDD_A_CSI_3_0P9 > > vdd-csiphy-0p9-supply > >> * VDD_A_CSI_x_1P25 - MIPI CSIx 1.25 V circuits >> With pad names VDD_A_CSI_0_1P25 to VDD_A_CSI_3_1P25 > > vdd-csiphy-1p25-supply > > > Best regards, > Krzysztof
On 28/10/2025 10:28, Luca Weiss wrote: >> So that's vdda-pll-supply > Just noticed, this S5A regulator is the MX power-domain, so we cannot > add it as vdda-pll-supply. > > From what I can see, so far no other camss bindings take in an rpmhpd > power domain, and given it's not referenced in downstream kernel, it > doesn't look like it's necessary to control it, from camss. > > Maybe it should be added to camcc though? Still not quite sure how > downstream vdd_class should translate to upstream... > > Thanks for helping with the other points, those are clear. > > Regards > Luca Standard practice here is for MX and MMXC in newer parts. MX certain pertains to the clock-controller in this case. --- bod
On 28/10/2025 09:46, Krzysztof Kozlowski wrote: >>>> + power-domain-names: >>>> + items: >>>> + - const: ife0 >>>> + - const: ife1 >>>> + - const: ife2 >>>> + - const: top >>> Uh, not your fault, but who came with this list in previous generations? >>> Instead of simple and obvious "top+ifeX" which allows growing/shrinking, >>> someone put "top" at the end which means this cannot follow same order >>> as X1E for example... Heh, it follows at least sm8550. >> Shall we put top as first power-domain? I don't think it's an issue to >> change the order. > Well, it matches sm8550, so I am just grumpy complaining. It's fine. The provenance here is "top" was required to be added last because the code depended on magic indexing in dtb to know which was the TOP GDSC. But since power-domain names are now required, you can have any order you want. > >>> >>>> + >>>> + vdda-0.9-supply: >>> There are no dots in property names. Are you sure these are called >>> VDDA_0.9 in the device datasheet (not schematics)? Please look at other >>> bindings how this is being named, depending whether this is PHY or PLL >>> supply (or only PHY). >> The following power supplies are mentioned: >> >> * VDD_CAMSS_PLL_0P9 - Camera SS PLL 0.9 V circuits >> (not referenced in downstream kernel, connected to vreg_s5a in >> schematics) > So that's vdda-pll-supply > >> * VDD_A_CSI_x_0P9 - MIPI CSIx 0.9 V circuits >> With pad names VDD_A_CSI_0_0P9 to VDD_A_CSI_3_0P9 > vdd-csiphy-0p9-supply > >> * VDD_A_CSI_x_1P25 - MIPI CSIx 1.25 V circuits >> With pad names VDD_A_CSI_0_1P25 to VDD_A_CSI_3_1P25 > vdd-csiphy-1p25-supply @Luca VDD_A_CSI_X_0P9 VDD_A_CSI_X_1P25 Agree see this on schematics. and look indeed there it is VDD_CAMSS_PLL_0P9 but if you look at where that rail comes from its SM_VDD_MX So I believe the MX power-domain should cover this instead of having a new separate rail defined in CAMSS for this. --- bod
On 28/10/2025 11:24, Bryan O'Donoghue wrote: > On 28/10/2025 09:46, Krzysztof Kozlowski wrote: >>>>> + power-domain-names: >>>>> + items: >>>>> + - const: ife0 >>>>> + - const: ife1 >>>>> + - const: ife2 >>>>> + - const: top >>>> Uh, not your fault, but who came with this list in previous generations? >>>> Instead of simple and obvious "top+ifeX" which allows growing/shrinking, >>>> someone put "top" at the end which means this cannot follow same order >>>> as X1E for example... Heh, it follows at least sm8550. >>> Shall we put top as first power-domain? I don't think it's an issue to >>> change the order. >> Well, it matches sm8550, so I am just grumpy complaining. It's fine. > > The provenance here is "top" was required to be added last because the > code depended on magic indexing in dtb to know which was the TOP GDSC. That's silly, because if it was first element would be much easier. Best regards, Krzysztof
On 28/10/2025 10:39, Krzysztof Kozlowski wrote: > On 28/10/2025 11:24, Bryan O'Donoghue wrote: >> On 28/10/2025 09:46, Krzysztof Kozlowski wrote: >>>>>> + power-domain-names: >>>>>> + items: >>>>>> + - const: ife0 >>>>>> + - const: ife1 >>>>>> + - const: ife2 >>>>>> + - const: top >>>>> Uh, not your fault, but who came with this list in previous generations? >>>>> Instead of simple and obvious "top+ifeX" which allows growing/shrinking, >>>>> someone put "top" at the end which means this cannot follow same order >>>>> as X1E for example... Heh, it follows at least sm8550. >>>> Shall we put top as first power-domain? I don't think it's an issue to >>>> change the order. >>> Well, it matches sm8550, so I am just grumpy complaining. It's fine. >> >> The provenance here is "top" was required to be added last because the >> code depended on magic indexing in dtb to know which was the TOP GDSC. > > > That's silly, because if it was first element would be much easier. > > Best regards, > Krzysztof I'm sure it was an accident. A bug, we fixed it. Anyway that's why. --- bod
© 2016 - 2026 Red Hat, Inc.