Add the compatible string "qcom,kaanapali-camss" to support the Camera
Subsystem (CAMSS) on the Qualcomm Kaanapali platform.
The Kaanapali platform provides:
- 3 x VFE, 5 RDI per VFE
- 2 x VFE Lite, 4 RDI per VFE Lite
- 3 x CSID
- 2 x CSID Lite
- 6 x CSIPHY
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../bindings/media/qcom,kaanapali-camss.yaml | 639 +++++++++++++++++++++
1 file changed, 639 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
new file mode 100644
index 000000000000..673a3e8b68a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
@@ -0,0 +1,639 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
+
+maintainers:
+ - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
+
+description:
+ This binding describes the camera subsystem hardware found on Kaanapali
+ Qualcomm SoCs. It includes submodules such as CSIPHY (CSI Physical layer)
+ and CSID (CSI Decoder), which comply with the MIPI CSI2 protocol.
+
+ The subsystem also integrates a set of real-time image processing engines
+ and their associated configuration modules, as well as non-real-time engines.
+
+ Additionally, it encompasses a test pattern generator (TPG) submodule.
+
+properties:
+ compatible:
+ const: qcom,kaanapali-camss
+
+ reg:
+ items:
+ - description: Registers for CSID 0
+ - description: Registers for CSID 1
+ - description: Registers for CSID 2
+ - description: Registers for CSID Lite 0
+ - description: Registers for CSID Lite 1
+ - description: Registers for CSIPHY 0
+ - description: Registers for CSIPHY 1
+ - description: Registers for CSIPHY 2
+ - description: Registers for CSIPHY 3
+ - description: Registers for CSIPHY 4
+ - description: Registers for CSIPHY 5
+ - description: Registers for VFE (Video Front End) 0
+ - description: Registers for VFE 1
+ - description: Registers for VFE 2
+ - description: Registers for VFE Lite 0
+ - description: Registers for VFE Lite 1
+ - description: Registers for ICP (Imaging Control Processor) 0
+ - description: Registers for ICP 1
+ - description: Registers for IPE (Image Processing Engine)
+ - description: Registers for JPEG DMA & Downscaler
+ - description: Registers for JPEG Encoder
+ - description: Registers for OFE (Offline Front End)
+ - description: Registers for RT CDM (Camera Data Mover) 0
+ - description: Registers for RT CDM 1
+ - description: Registers for RT CDM 2
+ - description: Registers for RT CDM 3
+ - description: Registers for RT CDM 4
+ - description: Registers for TPG 0
+ - description: Registers for TPG 1
+ - description: Registers for TPG 2
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+ - const: icp0
+ - const: icp1
+ - const: ipe
+ - const: jpeg_dma
+ - const: jpeg_enc
+ - const: ofe
+ - const: rt_cdm0
+ - const: rt_cdm1
+ - const: rt_cdm2
+ - const: rt_cdm3
+ - const: rt_cdm4
+ - const: tpg0
+ - const: tpg1
+ - const: tpg2
+
+ clocks:
+ maxItems: 60
+
+ clock-names:
+ items:
+ - const: camnoc_nrt_axi
+ - const: camnoc_rt_axi
+ - const: camnoc_rt_vfe0
+ - const: camnoc_rt_vfe1
+ - const: camnoc_rt_vfe2
+ - const: camnoc_rt_vfe_lite
+ - const: cam_top_ahb
+ - const: cam_top_fast_ahb
+ - const: csid
+ - const: csid_csiphy_rx
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: csiphy5
+ - const: csiphy5_timer
+ - const: gcc_hf_axi
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe1
+ - const: vfe1_fast_ahb
+ - const: vfe2
+ - const: vfe2_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+ - const: qdss_debug_xo
+ - const: camnoc_ipe_nps
+ - const: camnoc_ofe
+ - const: gcc_sf_axi
+ - const: icp0
+ - const: icp0_ahb
+ - const: icp1
+ - const: icp1_ahb
+ - const: ipe_nps
+ - const: ipe_nps_ahb
+ - const: ipe_nps_fast_ahb
+ - const: ipe_pps
+ - const: ipe_pps_fast_ahb
+ - const: jpeg
+ - const: ofe_ahb
+ - const: ofe_anchor
+ - const: ofe_anchor_fast_ahb
+ - const: ofe_hdr
+ - const: ofe_hdr_fast_ahb
+ - const: ofe_main
+ - const: ofe_main_fast_ahb
+ - const: vfe0_bayer
+ - const: vfe0_bayer_fast_ahb
+ - const: vfe1_bayer
+ - const: vfe1_bayer_fast_ahb
+ - const: vfe2_bayer
+ - const: vfe2_bayer_fast_ahb
+
+ interrupts:
+ maxItems: 30
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+ - const: camnoc_nrt
+ - const: camnoc_rt
+ - const: icp0
+ - const: icp1
+ - const: jpeg_dma
+ - const: jpeg_enc
+ - const: rt_cdm0
+ - const: rt_cdm1
+ - const: rt_cdm2
+ - const: rt_cdm3
+ - const: rt_cdm4
+ - const: tpg0
+ - const: tpg1
+ - const: tpg2
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_mnoc
+ - const: sf_icp_mnoc
+ - const: sf_mnoc
+
+ iommus:
+ items:
+ - description: VFE non-protected stream
+ - description: ICP0 shared stream
+ - description: ICP1 shared stream
+ - description: IPE CDM non-protected stream
+ - description: IPE non-protected stream
+ - description: JPEG non-protected stream
+ - description: OFE CDM non-protected stream
+ - description: OFE non-protected stream
+ - description: VFE / VFE Lite CDM non-protected stream
+
+ power-domains:
+ items:
+ - description:
+ VFE0 GDSC - Global Distributed Switch Controller for VFE0.
+ - description:
+ VFE1 GDSC - Global Distributed Switch Controller for VFE1.
+ - description:
+ VFE2 GDSC - Global Distributed Switch Controller for VFE2.
+ - description:
+ Titan GDSC - Global Distributed Switch Controller for the entire camss.
+ - description:
+ IPE GDSC - Global Distributed Switch Controller for IPE.
+ - description:
+ OFE GDSC - Block Global Distributed Switch Controller for OFE.
+
+ power-domain-names:
+ items:
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: top
+ - const: ipe
+ - const: ofe
+
+ vdd-csiphy0-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY0 core block.
+
+ vdd-csiphy0-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY0 pll block.
+
+ vdd-csiphy1-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY1 core block.
+
+ vdd-csiphy1-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY1 pll block.
+
+ vdd-csiphy2-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY2 core block.
+
+ vdd-csiphy2-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY2 pll block.
+
+ vdd-csiphy3-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY3 core block.
+
+ vdd-csiphy3-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY3 pll block.
+
+ vdd-csiphy4-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY4 core block.
+
+ vdd-csiphy4-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY4 pll block.
+
+ vdd-csiphy5-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY5 core block.
+
+ vdd-csiphy5-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY5 pll block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+patternProperties:
+ "^port@[0-5]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input ports for receiving CSI data on CSIPHY 0-5.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@9253000 {
+ compatible = "qcom,kaanapali-camss";
+
+ reg = <0x0 0x09253000 0x0 0x5e80>,
+ <0x0 0x09263000 0x0 0x5e80>,
+ <0x0 0x09273000 0x0 0x5e80>,
+ <0x0 0x092d3000 0x0 0x3880>,
+ <0x0 0x092e7000 0x0 0x3880>,
+ <0x0 0x09523000 0x0 0x2000>,
+ <0x0 0x09525000 0x0 0x2000>,
+ <0x0 0x09527000 0x0 0x2000>,
+ <0x0 0x09529000 0x0 0x2000>,
+ <0x0 0x0952b000 0x0 0x2000>,
+ <0x0 0x0952d000 0x0 0x2000>,
+ <0x0 0x09151000 0x0 0x20000>,
+ <0x0 0x09171000 0x0 0x20000>,
+ <0x0 0x09191000 0x0 0x20000>,
+ <0x0 0x092dc000 0x0 0x1300>,
+ <0x0 0x092f0000 0x0 0x1300>,
+ <0x0 0x0900e000 0x0 0x1000>,
+ <0x0 0x0902e000 0x0 0x1000>,
+ <0x0 0x090d7000 0x0 0x20000>,
+ <0x0 0x0904e000 0x0 0x1000>,
+ <0x0 0x0904d000 0x0 0x1000>,
+ <0x0 0x09057000 0x0 0x40000>,
+ <0x0 0x09147000 0x0 0x580>,
+ <0x0 0x09148000 0x0 0x580>,
+ <0x0 0x09149000 0x0 0x580>,
+ <0x0 0x0914a000 0x0 0x580>,
+ <0x0 0x0914b000 0x0 0x580>,
+ <0x0 0x093fd000 0x0 0x400>,
+ <0x0 0x093fe000 0x0 0x400>,
+ <0x0 0x093ff000 0x0 0x400>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1",
+ "icp0",
+ "icp1",
+ "ipe",
+ "jpeg_dma",
+ "jpeg_enc",
+ "ofe",
+ "rt_cdm0",
+ "rt_cdm1",
+ "rt_cdm2",
+ "rt_cdm3",
+ "rt_cdm4",
+ "tpg0",
+ "tpg1",
+ "tpg2";
+
+ clocks = <&camcc_cam_cc_camnoc_nrt_axi_clk>,
+ <&camcc_cam_cc_camnoc_rt_axi_clk>,
+ <&camcc_cam_cc_camnoc_rt_vfe_0_main_clk>,
+ <&camcc_cam_cc_camnoc_rt_vfe_1_main_clk>,
+ <&camcc_cam_cc_camnoc_rt_vfe_2_main_clk>,
+ <&camcc_cam_cc_camnoc_rt_vfe_lite_clk>,
+ <&camcc_cam_cc_cam_top_ahb_clk>,
+ <&camcc_cam_cc_cam_top_fast_ahb_clk>,
+ <&camcc_cam_cc_csid_clk>,
+ <&camcc_cam_cc_csid_csiphy_rx_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_csiphy3_clk>,
+ <&camcc_cam_cc_csi3phytimer_clk>,
+ <&camcc_cam_cc_csiphy4_clk>,
+ <&camcc_cam_cc_csi4phytimer_clk>,
+ <&camcc_cam_cc_csiphy5_clk>,
+ <&camcc_cam_cc_csi5phytimer_clk>,
+ <&gcc_gcc_camera_hf_axi_clk>,
+ <&camcc_cam_cc_vfe_0_main_clk>,
+ <&camcc_cam_cc_vfe_0_main_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_1_main_clk>,
+ <&camcc_cam_cc_vfe_1_main_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_2_main_clk>,
+ <&camcc_cam_cc_vfe_2_main_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_lite_clk>,
+ <&camcc_cam_cc_vfe_lite_ahb_clk>,
+ <&camcc_cam_cc_vfe_lite_cphy_rx_clk>,
+ <&camcc_cam_cc_vfe_lite_csid_clk>,
+ <&camcc_cam_cc_qdss_debug_xo_clk>,
+ <&camcc_cam_cc_camnoc_nrt_ipe_nps_clk>,
+ <&camcc_cam_cc_camnoc_nrt_ofe_main_clk>,
+ <&gcc_gcc_camera_sf_axi_clk>,
+ <&camcc_cam_cc_icp_0_clk>,
+ <&camcc_cam_cc_icp_0_ahb_clk>,
+ <&camcc_cam_cc_icp_1_clk>,
+ <&camcc_cam_cc_icp_1_ahb_clk>,
+ <&camcc_cam_cc_ipe_nps_clk>,
+ <&camcc_cam_cc_ipe_nps_ahb_clk>,
+ <&camcc_cam_cc_ipe_nps_fast_ahb_clk>,
+ <&camcc_cam_cc_ipe_pps_clk>,
+ <&camcc_cam_cc_ipe_pps_fast_ahb_clk>,
+ <&camcc_cam_cc_jpeg_clk>,
+ <&camcc_cam_cc_ofe_ahb_clk>,
+ <&camcc_cam_cc_ofe_anchor_clk>,
+ <&camcc_cam_cc_ofe_anchor_fast_ahb_clk>,
+ <&camcc_cam_cc_ofe_hdr_clk>,
+ <&camcc_cam_cc_ofe_hdr_fast_ahb_clk>,
+ <&camcc_cam_cc_ofe_main_clk>,
+ <&camcc_cam_cc_ofe_main_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_0_bayer_clk>,
+ <&camcc_cam_cc_vfe_0_bayer_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_1_bayer_clk>,
+ <&camcc_cam_cc_vfe_1_bayer_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_2_bayer_clk>,
+ <&camcc_cam_cc_vfe_2_bayer_fast_ahb_clk>;
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "camnoc_rt_vfe0",
+ "camnoc_rt_vfe1",
+ "camnoc_rt_vfe2",
+ "camnoc_rt_vfe_lite",
+ "cam_top_ahb",
+ "cam_top_fast_ahb",
+ "csid",
+ "csid_csiphy_rx",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "csiphy5",
+ "csiphy5_timer",
+ "gcc_hf_axi",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe2",
+ "vfe2_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid",
+ "qdss_debug_xo",
+ "camnoc_ipe_nps",
+ "camnoc_ofe",
+ "gcc_sf_axi",
+ "icp0",
+ "icp0_ahb",
+ "icp1",
+ "icp1_ahb",
+ "ipe_nps",
+ "ipe_nps_ahb",
+ "ipe_nps_fast_ahb",
+ "ipe_pps",
+ "ipe_pps_fast_ahb",
+ "jpeg",
+ "ofe_ahb",
+ "ofe_anchor",
+ "ofe_anchor_fast_ahb",
+ "ofe_hdr",
+ "ofe_hdr_fast_ahb",
+ "ofe_main",
+ "ofe_main_fast_ahb",
+ "vfe0_bayer",
+ "vfe0_bayer_fast_ahb",
+ "vfe1_bayer",
+ "vfe1_bayer_fast_ahb",
+ "vfe2_bayer",
+ "vfe2_bayer_fast_ahb";
+
+ interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 376 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 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 271 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 277 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 463 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 657 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 372 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 475 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 456 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 664 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 702 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 348 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 349 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 413 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 416 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 417 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1",
+ "camnoc_nrt",
+ "camnoc_rt",
+ "icp0",
+ "icp1",
+ "jpeg_dma",
+ "jpeg_enc",
+ "rt_cdm0",
+ "rt_cdm1",
+ "rt_cdm2",
+ "rt_cdm3",
+ "rt_cdm4",
+ "tpg0",
+ "tpg1",
+ "tpg2";
+
+ interconnects = <&gem_noc_master_appss_proc QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc_slave_camera_cfg QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc_master_camnoc_hf QCOM_ICC_TAG_ALWAYS
+ &mc_virt_slave_ebi1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc_master_camnoc_sf_icp QCOM_ICC_TAG_ALWAYS
+ &mc_virt_slave_ebi1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc_master_camnoc_sf QCOM_ICC_TAG_ALWAYS
+ &mc_virt_slave_ebi1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_mnoc",
+ "sf_icp_mnoc",
+ "sf_mnoc";
+
+ iommus = <&apps_smmu 0x1c00 0x00>,
+ <&apps_smmu 0x18c0 0x00>,
+ <&apps_smmu 0x1980 0x00>,
+ <&apps_smmu 0x1840 0x00>,
+ <&apps_smmu 0x1800 0x00>,
+ <&apps_smmu 0x18a0 0x00>,
+ <&apps_smmu 0x1880 0x00>,
+ <&apps_smmu 0x1820 0x00>,
+ <&apps_smmu 0x1860 0x00>;
+
+ power-domains = <&camcc_cam_cc_vfe_0_gdsc>,
+ <&camcc_cam_cc_vfe_1_gdsc>,
+ <&camcc_cam_cc_vfe_2_gdsc>,
+ <&camcc_cam_cc_titan_top_gdsc>,
+ <&camcc_cam_cc_ipe_gdsc>,
+ <&camcc_cam_cc_ofe_gdsc>;
+ power-domain-names = "vfe0",
+ "vfe1",
+ "vfe2",
+ "top",
+ "ipe",
+ "ofe";
+
+ vdd-csiphy0-0p8-supply = <&vreg_0p8_supply>;
+ vdd-csiphy0-1p2-supply = <&vreg_1p2_supply>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csiphy_ep0: endpoint {
+ data-lanes = <0 1>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
--
2.34.1On 14/11/2025 03:29, Hangxiang Ma wrote: > + <0x0 0x0900e000 0x0 0x1000>, Why aren't you starting @ 0x0900e000 ? seems to be omitting some of the registers in the ICP block. Should start at +0xd000 not +0xe000 ? > + <0x0 0x0902e000 0x0 0x1000>, Same here. > + <0x0 0x090d7000 0x0 0x20000>, > + <0x0 0x0904e000 0x0 0x1000>, > + <0x0 0x0904d000 0x0 0x1000>, > + <0x0 0x09057000 0x0 0x40000>, > + <0x0 0x09147000 0x0 0x580>, > + <0x0 0x09148000 0x0 0x580>, > + <0x0 0x09149000 0x0 0x580>, > + <0x0 0x0914a000 0x0 0x580>, > + <0x0 0x0914b000 0x0 0x580>, > + <0x0 0x093fd000 0x0 0x400>, > + <0x0 0x093fe000 0x0 0x400>, > + <0x0 0x093ff000 0x0 0x400>; The rest of these registers start at the defined block addresses in the documentation. Unless there's a very good reason for that, please amend. --- bod
On 11/18/2025 7:00 AM, Bryan O'Donoghue wrote: > On 14/11/2025 03:29, Hangxiang Ma wrote: >> + <0x0 0x0900e000 0x0 0x1000>, > > Why aren't you starting @ 0x0900e000 ? seems to be omitting some of > the registers in the ICP block. Should start at +0xd000 not +0xe000 ? > >> + <0x0 0x0902e000 0x0 0x1000>, > > Same here. Hi Bryan, HLOS does not have access to those registers. They are configured by the Hyp. > >> + <0x0 0x090d7000 0x0 0x20000>, >> + <0x0 0x0904e000 0x0 0x1000>, >> + <0x0 0x0904d000 0x0 0x1000>, >> + <0x0 0x09057000 0x0 0x40000>, >> + <0x0 0x09147000 0x0 0x580>, >> + <0x0 0x09148000 0x0 0x580>, >> + <0x0 0x09149000 0x0 0x580>, >> + <0x0 0x0914a000 0x0 0x580>, >> + <0x0 0x0914b000 0x0 0x580>, >> + <0x0 0x093fd000 0x0 0x400>, >> + <0x0 0x093fe000 0x0 0x400>, >> + <0x0 0x093ff000 0x0 0x400>; > > The rest of these registers start at the defined block addresses in > the documentation. > > Unless there's a very good reason for that, please amend. Sorry, is there an additional concern here or you were just pointing these as reference for the above? > > --- > bod > Thanks, Vijay.
On 11/18/25 7:25 PM, Vijay Kumar Tumati wrote: > > On 11/18/2025 7:00 AM, Bryan O'Donoghue wrote: >> On 14/11/2025 03:29, Hangxiang Ma wrote: >>> + <0x0 0x0900e000 0x0 0x1000>, >> >> Why aren't you starting @ 0x0900e000 ? seems to be omitting some of the registers in the ICP block. Should start at +0xd000 not +0xe000 ? >> >>> + <0x0 0x0902e000 0x0 0x1000>, >> >> Same here. > Hi Bryan, HLOS does not have access to those registers. They are configured by the Hyp. If that's hyp, please add them. We already have platforms without Gunyah. Remember, bindings are defined once and for good and I wouldn't call it impossible that someone would want to run that configuration on Kaanapali some day Konrad
On 11/18/25 20:44, Konrad Dybcio wrote: > On 11/18/25 7:25 PM, Vijay Kumar Tumati wrote: >> >> On 11/18/2025 7:00 AM, Bryan O'Donoghue wrote: >>> On 14/11/2025 03:29, Hangxiang Ma wrote: >>>> + <0x0 0x0900e000 0x0 0x1000>, >>> >>> Why aren't you starting @ 0x0900e000 ? seems to be omitting some of the registers in the ICP block. Should start at +0xd000 not +0xe000 ? >>> >>>> + <0x0 0x0902e000 0x0 0x1000>, >>> >>> Same here. >> Hi Bryan, HLOS does not have access to those registers. They are configured by the Hyp. > > If that's hyp, please add them. We already have platforms without > Gunyah. Remember, bindings are defined once and for good and I wouldn't > call it impossible that someone would want to run that configuration on > Kaanapali some day > If the ICP register block is added now, then it will practically exclude an option to run hardware demosaic on Kaanapali. There were notorious and still unresolved problems with CSIPHY blocks, which shall be split from CSID/VFE CAMSS on device tree level also, for similar reasons the same should be done with ICP or other blocks. It makes exactly zero sense to pile everything into a monolythic device tree node, and doing so undermines any future advances in CAMSS support in the upstream Linux, the hardware description in downstream is done thoughtfully better, and not for no reason. -- Best wishes, Vladimir
On 12/12/2025 12:49, Vladimir Zapolskiy wrote: > > If the ICP register block is added now, then it will practically exclude > an option to run hardware demosaic on Kaanapali. Why ? --- bod
On 12/12/2025 4:49 AM, Vladimir Zapolskiy wrote: > On 11/18/25 20:44, Konrad Dybcio wrote: >> On 11/18/25 7:25 PM, Vijay Kumar Tumati wrote: >>> >>> On 11/18/2025 7:00 AM, Bryan O'Donoghue wrote: >>>> On 14/11/2025 03:29, Hangxiang Ma wrote: >>>>> + <0x0 0x0900e000 0x0 0x1000>, >>>> >>>> Why aren't you starting @ 0x0900e000 ? seems to be omitting some of >>>> the registers in the ICP block. Should start at +0xd000 not +0xe000 ? >>>> >>>>> + <0x0 0x0902e000 0x0 0x1000>, >>>> >>>> Same here. >>> Hi Bryan, HLOS does not have access to those registers. They are >>> configured by the Hyp. >> >> If that's hyp, please add them. We already have platforms without >> Gunyah. Remember, bindings are defined once and for good and I wouldn't >> call it impossible that someone would want to run that configuration on >> Kaanapali some day >> > > If the ICP register block is added now, then it will practically exclude > an option to run hardware demosaic on Kaanapali. There were notorious > and still unresolved problems with CSIPHY blocks, which shall be split > from CSID/VFE CAMSS on device tree level also, for similar reasons the > same should be done with ICP or other blocks. It makes exactly zero > sense to pile everything into a monolythic device tree node, and doing > so undermines any future advances in CAMSS support in the upstream > Linux, the hardware description in downstream is done thoughtfully > better, > and not for no reason. > Hi Vladimir, yes, this has been discussed in the past and the general consensus from everyone is for not blocking KNP series on this. But yes, there is an ongoing effort to modularize the bindings for future chipsets and when it's ready, we can review, discuss and take it forward. As for your ICP concern, if you are referring to the Demosaic in OFE, I believe we might still be able to do it either with direct OFE config from CPU or using the firmware (preferred), given that we properly establish the shared memory and SID IOVA ranges for ICP, assuming that the load and authenticate will be taken care by Hyp or TZ. Please share your thoughts if I missed something. Hi Bryan, please feel free to add your thoughts. Thanks, Vijay.
Hi Vijay. On 12/16/25 19:55, Vijay Kumar Tumati wrote: > > On 12/12/2025 4:49 AM, Vladimir Zapolskiy wrote: >> On 11/18/25 20:44, Konrad Dybcio wrote: >>> On 11/18/25 7:25 PM, Vijay Kumar Tumati wrote: >>>> >>>> On 11/18/2025 7:00 AM, Bryan O'Donoghue wrote: >>>>> On 14/11/2025 03:29, Hangxiang Ma wrote: >>>>>> + <0x0 0x0900e000 0x0 0x1000>, >>>>> >>>>> Why aren't you starting @ 0x0900e000 ? seems to be omitting some of >>>>> the registers in the ICP block. Should start at +0xd000 not +0xe000 ? >>>>> >>>>>> + <0x0 0x0902e000 0x0 0x1000>, >>>>> >>>>> Same here. >>>> Hi Bryan, HLOS does not have access to those registers. They are >>>> configured by the Hyp. >>> >>> If that's hyp, please add them. We already have platforms without >>> Gunyah. Remember, bindings are defined once and for good and I wouldn't >>> call it impossible that someone would want to run that configuration on >>> Kaanapali some day >>> >> >> If the ICP register block is added now, then it will practically exclude >> an option to run hardware demosaic on Kaanapali. There were notorious >> and still unresolved problems with CSIPHY blocks, which shall be split >> from CSID/VFE CAMSS on device tree level also, for similar reasons the >> same should be done with ICP or other blocks. It makes exactly zero >> sense to pile everything into a monolythic device tree node, and doing >> so undermines any future advances in CAMSS support in the upstream >> Linux, the hardware description in downstream is done thoughtfully >> better, >> and not for no reason. >> > Hi Vladimir, yes, this has been discussed in the past and the general > consensus from everyone is for not blocking KNP series on this. But yes, > there is an ongoing effort to modularize the bindings for future > chipsets and when it's ready, we can review, discuss and take it My concern is that it makes very little sense to throw any not clearly defined hardware properties and interconnections into an unorganized and unmanageable pile of everything, because this closes the door to ever update the upstream CAMSS driver by adding better CAMSS IP support for any already manufactured and sold Qualcomm SoC powered board with done CAMSS support. If some user already holds a phone, a laptop and expects to offload CPU to CAMSS IP one happy day, it's pretty unsatisfactory to say that it will never happen on legacy hardware, because there was done an unrecoverable mistake by adding never tested properties into CAMSS DT bindings, and the remained option is to "wait for future chipsets". Each added unsupported and unused property boards up the window of better CAMSS support on manufactured boards. I don't understand a reason why to do worse for the upstream, when there is a clear and feasible alternative not to do worse, thus my misunderstanding and my grief for upstream CAMSS are my concerns. > forward. As for your ICP concern, if you are referring to the Demosaic > in OFE, I believe we might still be able to do it either with direct OFE > config from CPU or using the firmware (preferred), given that we > properly establish the shared memory and SID IOVA ranges for ICP, > assuming that the load and authenticate will be taken care by Hyp or TZ. > Please share your thoughts if I missed something. > > Hi Bryan, please feel free to add your thoughts. > -- Best wishes, Vladimir
On 17/12/2025 00:02, Vladimir Zapolskiy wrote: > My concern is that it makes very little sense to throw any not clearly > defined hardware properties and interconnections into an unorganized and > unmanageable pile of everything, because this closes the door to ever > update > the upstream CAMSS driver by adding better CAMSS IP support for any already > manufactured and sold Qualcomm SoC powered board with done CAMSS support. > > If some user already holds a phone, a laptop and expects to offload CPU to > CAMSS IP one happy day, it's pretty unsatisfactory to say that it will > never > happen on legacy hardware, because there was done an unrecoverable mistake > by adding never tested properties into CAMSS DT bindings, and the remained > option is to "wait for future chipsets". Each added unsupported and unused > property boards up the window of better CAMSS support on manufactured > boards. > > I don't understand a reason why to do worse for the upstream, when there is > a clear and feasible alternative not to do worse, thus my misunderstanding > and my grief for upstream CAMSS are my concerns. I don't think this answers the question on how describing all of the CAMSS hardware precludes switching on demosiac. To be frank, I don't see any specific arguments here at all. --- bod
On 12/16/2025 4:02 PM, Vladimir Zapolskiy wrote: > Hi Vijay. > > On 12/16/25 19:55, Vijay Kumar Tumati wrote: >> >> On 12/12/2025 4:49 AM, Vladimir Zapolskiy wrote: >>> On 11/18/25 20:44, Konrad Dybcio wrote: >>>> On 11/18/25 7:25 PM, Vijay Kumar Tumati wrote: >>>>> >>>>> On 11/18/2025 7:00 AM, Bryan O'Donoghue wrote: >>>>>> On 14/11/2025 03:29, Hangxiang Ma wrote: >>>>>>> + <0x0 0x0900e000 0x0 0x1000>, >>>>>> >>>>>> Why aren't you starting @ 0x0900e000 ? seems to be omitting some of >>>>>> the registers in the ICP block. Should start at +0xd000 not >>>>>> +0xe000 ? >>>>>> >>>>>>> + <0x0 0x0902e000 0x0 0x1000>, >>>>>> >>>>>> Same here. >>>>> Hi Bryan, HLOS does not have access to those registers. They are >>>>> configured by the Hyp. >>>> >>>> If that's hyp, please add them. We already have platforms without >>>> Gunyah. Remember, bindings are defined once and for good and I >>>> wouldn't >>>> call it impossible that someone would want to run that >>>> configuration on >>>> Kaanapali some day >>>> >>> >>> If the ICP register block is added now, then it will practically >>> exclude >>> an option to run hardware demosaic on Kaanapali. There were notorious >>> and still unresolved problems with CSIPHY blocks, which shall be split >>> from CSID/VFE CAMSS on device tree level also, for similar reasons the >>> same should be done with ICP or other blocks. It makes exactly zero >>> sense to pile everything into a monolythic device tree node, and doing >>> so undermines any future advances in CAMSS support in the upstream >>> Linux, the hardware description in downstream is done thoughtfully >>> better, >>> and not for no reason. >>> >> Hi Vladimir, yes, this has been discussed in the past and the general >> consensus from everyone is for not blocking KNP series on this. But yes, >> there is an ongoing effort to modularize the bindings for future >> chipsets and when it's ready, we can review, discuss and take it > > My concern is that it makes very little sense to throw any not clearly > defined hardware properties and interconnections into an unorganized and > unmanageable pile of everything, because this closes the door to ever > update > the upstream CAMSS driver by adding better CAMSS IP support for any > already > manufactured and sold Qualcomm SoC powered board with done CAMSS support. > > If some user already holds a phone, a laptop and expects to offload > CPU to > CAMSS IP one happy day, it's pretty unsatisfactory to say that it will > never > happen on legacy hardware, because there was done an unrecoverable > mistake > by adding never tested properties into CAMSS DT bindings, and the > remained > option is to "wait for future chipsets". Each added unsupported and > unused > property boards up the window of better CAMSS support on manufactured > boards. > > I don't understand a reason why to do worse for the upstream, when > there is > a clear and feasible alternative not to do worse, thus my > misunderstanding > and my grief for upstream CAMSS are my concerns. > Thanks for the comments, Vladimir. Bryan's and Krzysztof's argument was that the bindings are required to describe the full hardware regardless of the driver support and either way not modifiable in the future, so they preferred having the HW properties of the key functional blocks in the bindings. And we were specifically asked to add the properties into this node in this patch series. Having said that, my knowledge on how the bindings are handled upstream in the long run as the requirements evolve, is limited. So I will look for some expert advise from Bryan here as he strongly advised for these. Thanks again. >> forward. As for your ICP concern, if you are referring to the Demosaic >> in OFE, I believe we might still be able to do it either with direct OFE >> config from CPU or using the firmware (preferred), given that we >> properly establish the shared memory and SID IOVA ranges for ICP, >> assuming that the load and authenticate will be taken care by Hyp or TZ. >> Please share your thoughts if I missed something. >> >> Hi Bryan, please feel free to add your thoughts. >> >
On 17/12/2025 00:46, Vijay Kumar Tumati wrote: >> I don't understand a reason why to do worse for the upstream, when >> there is >> a clear and feasible alternative not to do worse, thus my >> misunderstanding >> and my grief for upstream CAMSS are my concerns. >> > Thanks for the comments, Vladimir. Bryan's and Krzysztof's argument was > that the bindings are required to describe the full hardware regardless > of the driver support and either way not modifiable in the future, so > they preferred having the HW properties of the key functional blocks in > the bindings. And we were specifically asked to add the properties into > this node in this patch series. Having said that, my knowledge on how > the bindings are handled upstream in the long run as the requirements > evolve, is limited. So I will look for some expert advise from Bryan > here as he strongly advised for these. Thanks again. I see no technical reason why describing the whole hardware block precludes any further work. How could it ? Anyway, I'll repeat my ask to describe: - The full register set - The interconnects - The clocks and resets - The SIDs --- bod
On 12/16/2025 7:29 PM, Bryan O'Donoghue wrote: > On 17/12/2025 00:46, Vijay Kumar Tumati wrote: >>> I don't understand a reason why to do worse for the upstream, when >>> there is >>> a clear and feasible alternative not to do worse, thus my >>> misunderstanding >>> and my grief for upstream CAMSS are my concerns. >>> >> Thanks for the comments, Vladimir. Bryan's and Krzysztof's argument >> was that the bindings are required to describe the full hardware >> regardless of the driver support and either way not modifiable in the >> future, so they preferred having the HW properties of the key >> functional blocks in the bindings. And we were specifically asked to >> add the properties into this node in this patch series. Having said >> that, my knowledge on how the bindings are handled upstream in the >> long run as the requirements evolve, is limited. So I will look for >> some expert advise from Bryan here as he strongly advised for these. >> Thanks again. > > I see no technical reason why describing the whole hardware block > precludes any further work. How could it ? > > Anyway, I'll repeat my ask to describe: > > - The full register set > - The interconnects > - The clocks and resets > - The SIDs > > --- > bod Yes, it is what's been done. Assuming this thread is closed then. Thanks, Vijay.
On 11/18/2025 10:44 AM, Konrad Dybcio wrote: > On 11/18/25 7:25 PM, Vijay Kumar Tumati wrote: >> On 11/18/2025 7:00 AM, Bryan O'Donoghue wrote: >>> On 14/11/2025 03:29, Hangxiang Ma wrote: >>>> + <0x0 0x0900e000 0x0 0x1000>, >>> Why aren't you starting @ 0x0900e000 ? seems to be omitting some of the registers in the ICP block. Should start at +0xd000 not +0xe000 ? >>> >>>> + <0x0 0x0902e000 0x0 0x1000>, >>> Same here. >> Hi Bryan, HLOS does not have access to those registers. They are configured by the Hyp. > If that's hyp, please add them. We already have platforms without > Gunyah. Remember, bindings are defined once and for good and I wouldn't > call it impossible that someone would want to run that configuration on > Kaanapali some day > > Konrad Sure, if that's the standard. But even on systems without Gunyah (say, KVM/PKVM), these will not be configured from HLOS in the regular flow. It will be done from TZ. Thanks, Vijay.
On 18/11/2025 21:45, Vijay Kumar Tumati wrote: >>> Hi Bryan, HLOS does not have access to those registers. They are >>> configured by the Hyp. >> If that's hyp, please add them. We already have platforms without >> Gunyah. Remember, bindings are defined once and for good and I wouldn't >> call it impossible that someone would want to run that configuration on >> Kaanapali some day >> >> Konrad > > Sure, if that's the standard. But even on systems without Gunyah (say, > KVM/PKVM), these will not be configured from HLOS in the regular flow. > It will be done from TZ. By the bootloader/s or by runtime TZ app ? --- bod
On 11/19/2025 1:21 AM, Bryan O'Donoghue wrote: > On 18/11/2025 21:45, Vijay Kumar Tumati wrote: >>>> Hi Bryan, HLOS does not have access to those registers. They are >>>> configured by the Hyp. >>> If that's hyp, please add them. We already have platforms without >>> Gunyah. Remember, bindings are defined once and for good and I wouldn't >>> call it impossible that someone would want to run that configuration on >>> Kaanapali some day >>> >>> Konrad >> >> Sure, if that's the standard. But even on systems without Gunyah >> (say, KVM/PKVM), these will not be configured from HLOS in the >> regular flow. It will be done from TZ. > > By the bootloader/s or by runtime TZ app ? > > --- > bod The proposed architecture is for it to be done by the TZ (Secure EL1). Thanks, Vijay.
On 14/11/2025 03:29, Hangxiang Ma wrote:
> Add the compatible string "qcom,kaanapali-camss" to support the Camera
> Subsystem (CAMSS) on the Qualcomm Kaanapali platform.
>
> The Kaanapali platform provides:
> - 3 x VFE, 5 RDI per VFE
> - 2 x VFE Lite, 4 RDI per VFE Lite
> - 3 x CSID
> - 2 x CSID Lite
> - 6 x CSIPHY
>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,kaanapali-camss.yaml | 639 +++++++++++++++++++++
> 1 file changed, 639 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> new file mode 100644
> index 000000000000..673a3e8b68a2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> @@ -0,0 +1,639 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
> +
> +maintainers:
> + - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> +
> +description:
> + This binding describes the camera subsystem hardware found on Kaanapali
> + Qualcomm SoCs. It includes submodules such as CSIPHY (CSI Physical layer)
> + and CSID (CSI Decoder), which comply with the MIPI CSI2 protocol.
> +
> + The subsystem also integrates a set of real-time image processing engines
> + and their associated configuration modules, as well as non-real-time engines.
> +
> + Additionally, it encompasses a test pattern generator (TPG) submodule.
> +
> +properties:
> + compatible:
> + const: qcom,kaanapali-camss
> +
> + reg:
> + items:
> + - description: Registers for CSID 0
> + - description: Registers for CSID 1
> + - description: Registers for CSID 2
> + - description: Registers for CSID Lite 0
> + - description: Registers for CSID Lite 1
> + - description: Registers for CSIPHY 0
> + - description: Registers for CSIPHY 1
> + - description: Registers for CSIPHY 2
> + - description: Registers for CSIPHY 3
> + - description: Registers for CSIPHY 4
> + - description: Registers for CSIPHY 5
> + - description: Registers for VFE (Video Front End) 0
> + - description: Registers for VFE 1
> + - description: Registers for VFE 2
> + - description: Registers for VFE Lite 0
> + - description: Registers for VFE Lite 1
> + - description: Registers for ICP (Imaging Control Processor) 0
> + - description: Registers for ICP 1
> + - description: Registers for IPE (Image Processing Engine)
> + - description: Registers for JPEG DMA & Downscaler
> + - description: Registers for JPEG Encoder
> + - description: Registers for OFE (Offline Front End)
> + - description: Registers for RT CDM (Camera Data Mover) 0
> + - description: Registers for RT CDM 1
> + - description: Registers for RT CDM 2
> + - description: Registers for RT CDM 3
> + - description: Registers for RT CDM 4
> + - description: Registers for TPG 0
> + - description: Registers for TPG 1
> + - description: Registers for TPG 2
> +
> + reg-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csiphy0
> + - const: csiphy1
> + - const: csiphy2
> + - const: csiphy3
> + - const: csiphy4
> + - const: csiphy5
> + - const: vfe0
> + - const: vfe1
> + - const: vfe2
> + - const: vfe_lite0
> + - const: vfe_lite1
> + - const: icp0
> + - const: icp1
> + - const: ipe
> + - const: jpeg_dma
> + - const: jpeg_enc
> + - const: ofe
> + - const: rt_cdm0
> + - const: rt_cdm1
> + - const: rt_cdm2
> + - const: rt_cdm3
> + - const: rt_cdm4
> + - const: tpg0
> + - const: tpg1
> + - const: tpg2
> +
> + clocks:
> + maxItems: 60
> +
> + clock-names:
> + items:
> + - const: camnoc_nrt_axi
> + - const: camnoc_rt_axi
> + - const: camnoc_rt_vfe0
> + - const: camnoc_rt_vfe1
> + - const: camnoc_rt_vfe2
> + - const: camnoc_rt_vfe_lite
> + - const: cam_top_ahb
> + - const: cam_top_fast_ahb
> + - const: csid
> + - const: csid_csiphy_rx
> + - const: csiphy0
> + - const: csiphy0_timer
> + - const: csiphy1
> + - const: csiphy1_timer
> + - const: csiphy2
> + - const: csiphy2_timer
> + - const: csiphy3
> + - const: csiphy3_timer
> + - const: csiphy4
> + - const: csiphy4_timer
> + - const: csiphy5
> + - const: csiphy5_timer
> + - const: gcc_hf_axi
> + - const: vfe0
> + - const: vfe0_fast_ahb
> + - const: vfe1
> + - const: vfe1_fast_ahb
> + - const: vfe2
> + - const: vfe2_fast_ahb
> + - const: vfe_lite
> + - const: vfe_lite_ahb
> + - const: vfe_lite_cphy_rx
> + - const: vfe_lite_csid
> + - const: qdss_debug_xo
> + - const: camnoc_ipe_nps
> + - const: camnoc_ofe
> + - const: gcc_sf_axi
> + - const: icp0
> + - const: icp0_ahb
> + - const: icp1
> + - const: icp1_ahb
> + - const: ipe_nps
> + - const: ipe_nps_ahb
> + - const: ipe_nps_fast_ahb
> + - const: ipe_pps
> + - const: ipe_pps_fast_ahb
> + - const: jpeg
> + - const: ofe_ahb
> + - const: ofe_anchor
> + - const: ofe_anchor_fast_ahb
> + - const: ofe_hdr
> + - const: ofe_hdr_fast_ahb
> + - const: ofe_main
> + - const: ofe_main_fast_ahb
> + - const: vfe0_bayer
> + - const: vfe0_bayer_fast_ahb
> + - const: vfe1_bayer
> + - const: vfe1_bayer_fast_ahb
> + - const: vfe2_bayer
> + - const: vfe2_bayer_fast_ahb
> +
> + interrupts:
> + maxItems: 30
> +
> + interrupt-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csiphy0
> + - const: csiphy1
> + - const: csiphy2
> + - const: csiphy3
> + - const: csiphy4
> + - const: csiphy5
> + - const: vfe0
> + - const: vfe1
> + - const: vfe2
> + - const: vfe_lite0
> + - const: vfe_lite1
> + - const: camnoc_nrt
> + - const: camnoc_rt
> + - const: icp0
> + - const: icp1
> + - const: jpeg_dma
> + - const: jpeg_enc
> + - const: rt_cdm0
> + - const: rt_cdm1
> + - const: rt_cdm2
> + - const: rt_cdm3
> + - const: rt_cdm4
> + - const: tpg0
> + - const: tpg1
> + - const: tpg2
> +
> + interconnects:
> + maxItems: 4
> +
> + interconnect-names:
> + items:
> + - const: ahb
> + - const: hf_mnoc
> + - const: sf_icp_mnoc
> + - const: sf_mnoc
> +
> + iommus:
> + items:
> + - description: VFE non-protected stream
> + - description: ICP0 shared stream
> + - description: ICP1 shared stream
> + - description: IPE CDM non-protected stream
> + - description: IPE non-protected stream
> + - description: JPEG non-protected stream
> + - description: OFE CDM non-protected stream
> + - description: OFE non-protected stream
> + - description: VFE / VFE Lite CDM non-protected stream
> +
> + power-domains:
> + items:
> + - description:
> + VFE0 GDSC - Global Distributed Switch Controller for VFE0.
> + - description:
> + VFE1 GDSC - Global Distributed Switch Controller for VFE1.
> + - description:
> + VFE2 GDSC - Global Distributed Switch Controller for VFE2.
> + - description:
> + Titan GDSC - Global Distributed Switch Controller for the entire camss.
> + - description:
> + IPE GDSC - Global Distributed Switch Controller for IPE.
> + - description:
> + OFE GDSC - Block Global Distributed Switch Controller for OFE.
> +
> + power-domain-names:
> + items:
> + - const: vfe0
> + - const: vfe1
> + - const: vfe2
> + - const: top
> + - const: ipe
> + - const: ofe
> +
> + vdd-csiphy0-0p8-supply:
> + description:
> + Phandle to a 0.8V regulator supply to CSIPHY0 core block.
> +
> + vdd-csiphy0-1p2-supply:
> + description:
> + Phandle to a 1.2V regulator supply to CSIPHY0 pll block.
> +
> + vdd-csiphy1-0p8-supply:
> + description:
> + Phandle to a 0.8V regulator supply to CSIPHY1 core block.
> +
> + vdd-csiphy1-1p2-supply:
> + description:
> + Phandle to a 1.2V regulator supply to CSIPHY1 pll block.
> +
> + vdd-csiphy2-0p8-supply:
> + description:
> + Phandle to a 0.8V regulator supply to CSIPHY2 core block.
> +
> + vdd-csiphy2-1p2-supply:
> + description:
> + Phandle to a 1.2V regulator supply to CSIPHY2 pll block.
> +
> + vdd-csiphy3-0p8-supply:
> + description:
> + Phandle to a 0.8V regulator supply to CSIPHY3 core block.
> +
> + vdd-csiphy3-1p2-supply:
> + description:
> + Phandle to a 1.2V regulator supply to CSIPHY3 pll block.
> +
> + vdd-csiphy4-0p8-supply:
> + description:
> + Phandle to a 0.8V regulator supply to CSIPHY4 core block.
> +
> + vdd-csiphy4-1p2-supply:
> + description:
> + Phandle to a 1.2V regulator supply to CSIPHY4 pll block.
> +
> + vdd-csiphy5-0p8-supply:
> + description:
> + Phandle to a 0.8V regulator supply to CSIPHY5 core block.
> +
> + vdd-csiphy5-1p2-supply:
> + description:
> + Phandle to a 1.2V regulator supply to CSIPHY5 pll block.
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + description:
> + CSI input ports.
> +
> +patternProperties:
> + "^port@[0-5]$":
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input ports for receiving CSI data on CSIPHY 0-5.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + required:
> + - data-lanes
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-names
> + - interconnects
> + - interconnect-names
> + - iommus
> + - power-domains
> + - power-domain-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interconnect/qcom,icc.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/power/qcom,rpmhpd.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + isp@9253000 {
> + compatible = "qcom,kaanapali-camss";
> +
> + reg = <0x0 0x09253000 0x0 0x5e80>,
> + <0x0 0x09263000 0x0 0x5e80>,
> + <0x0 0x09273000 0x0 0x5e80>,
> + <0x0 0x092d3000 0x0 0x3880>,
> + <0x0 0x092e7000 0x0 0x3880>,
> + <0x0 0x09523000 0x0 0x2000>,
> + <0x0 0x09525000 0x0 0x2000>,
> + <0x0 0x09527000 0x0 0x2000>,
> + <0x0 0x09529000 0x0 0x2000>,
> + <0x0 0x0952b000 0x0 0x2000>,
> + <0x0 0x0952d000 0x0 0x2000>,
> + <0x0 0x09151000 0x0 0x20000>,
> + <0x0 0x09171000 0x0 0x20000>,
> + <0x0 0x09191000 0x0 0x20000>,
> + <0x0 0x092dc000 0x0 0x1300>,
> + <0x0 0x092f0000 0x0 0x1300>,
> + <0x0 0x0900e000 0x0 0x1000>,
> + <0x0 0x0902e000 0x0 0x1000>,
> + <0x0 0x090d7000 0x0 0x20000>,
> + <0x0 0x0904e000 0x0 0x1000>,
> + <0x0 0x0904d000 0x0 0x1000>,
> + <0x0 0x09057000 0x0 0x40000>,
> + <0x0 0x09147000 0x0 0x580>,
> + <0x0 0x09148000 0x0 0x580>,
> + <0x0 0x09149000 0x0 0x580>,
> + <0x0 0x0914a000 0x0 0x580>,
> + <0x0 0x0914b000 0x0 0x580>,
> + <0x0 0x093fd000 0x0 0x400>,
> + <0x0 0x093fe000 0x0 0x400>,
> + <0x0 0x093ff000 0x0 0x400>;
> + reg-names = "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
> + "csiphy4",
> + "csiphy5",
> + "vfe0",
> + "vfe1",
> + "vfe2",
> + "vfe_lite0",
> + "vfe_lite1",
> + "icp0",
> + "icp1",
> + "ipe",
> + "jpeg_dma",
> + "jpeg_enc",
> + "ofe",
> + "rt_cdm0",
> + "rt_cdm1",
> + "rt_cdm2",
> + "rt_cdm3",
> + "rt_cdm4",
> + "tpg0",
> + "tpg1",
> + "tpg2";
> +
> + clocks = <&camcc_cam_cc_camnoc_nrt_axi_clk>,
> + <&camcc_cam_cc_camnoc_rt_axi_clk>,
> + <&camcc_cam_cc_camnoc_rt_vfe_0_main_clk>,
> + <&camcc_cam_cc_camnoc_rt_vfe_1_main_clk>,
> + <&camcc_cam_cc_camnoc_rt_vfe_2_main_clk>,
> + <&camcc_cam_cc_camnoc_rt_vfe_lite_clk>,
> + <&camcc_cam_cc_cam_top_ahb_clk>,
> + <&camcc_cam_cc_cam_top_fast_ahb_clk>,
> + <&camcc_cam_cc_csid_clk>,
> + <&camcc_cam_cc_csid_csiphy_rx_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_csiphy3_clk>,
> + <&camcc_cam_cc_csi3phytimer_clk>,
> + <&camcc_cam_cc_csiphy4_clk>,
> + <&camcc_cam_cc_csi4phytimer_clk>,
> + <&camcc_cam_cc_csiphy5_clk>,
> + <&camcc_cam_cc_csi5phytimer_clk>,
> + <&gcc_gcc_camera_hf_axi_clk>,
> + <&camcc_cam_cc_vfe_0_main_clk>,
> + <&camcc_cam_cc_vfe_0_main_fast_ahb_clk>,
> + <&camcc_cam_cc_vfe_1_main_clk>,
> + <&camcc_cam_cc_vfe_1_main_fast_ahb_clk>,
> + <&camcc_cam_cc_vfe_2_main_clk>,
> + <&camcc_cam_cc_vfe_2_main_fast_ahb_clk>,
> + <&camcc_cam_cc_vfe_lite_clk>,
> + <&camcc_cam_cc_vfe_lite_ahb_clk>,
> + <&camcc_cam_cc_vfe_lite_cphy_rx_clk>,
> + <&camcc_cam_cc_vfe_lite_csid_clk>,
> + <&camcc_cam_cc_qdss_debug_xo_clk>,
> + <&camcc_cam_cc_camnoc_nrt_ipe_nps_clk>,
> + <&camcc_cam_cc_camnoc_nrt_ofe_main_clk>,
> + <&gcc_gcc_camera_sf_axi_clk>,
> + <&camcc_cam_cc_icp_0_clk>,
> + <&camcc_cam_cc_icp_0_ahb_clk>,
> + <&camcc_cam_cc_icp_1_clk>,
> + <&camcc_cam_cc_icp_1_ahb_clk>,
> + <&camcc_cam_cc_ipe_nps_clk>,
> + <&camcc_cam_cc_ipe_nps_ahb_clk>,
> + <&camcc_cam_cc_ipe_nps_fast_ahb_clk>,
> + <&camcc_cam_cc_ipe_pps_clk>,
> + <&camcc_cam_cc_ipe_pps_fast_ahb_clk>,
> + <&camcc_cam_cc_jpeg_clk>,
> + <&camcc_cam_cc_ofe_ahb_clk>,
> + <&camcc_cam_cc_ofe_anchor_clk>,
> + <&camcc_cam_cc_ofe_anchor_fast_ahb_clk>,
> + <&camcc_cam_cc_ofe_hdr_clk>,
> + <&camcc_cam_cc_ofe_hdr_fast_ahb_clk>,
> + <&camcc_cam_cc_ofe_main_clk>,
> + <&camcc_cam_cc_ofe_main_fast_ahb_clk>,
> + <&camcc_cam_cc_vfe_0_bayer_clk>,
> + <&camcc_cam_cc_vfe_0_bayer_fast_ahb_clk>,
> + <&camcc_cam_cc_vfe_1_bayer_clk>,
> + <&camcc_cam_cc_vfe_1_bayer_fast_ahb_clk>,
> + <&camcc_cam_cc_vfe_2_bayer_clk>,
> + <&camcc_cam_cc_vfe_2_bayer_fast_ahb_clk>;
> + clock-names = "camnoc_nrt_axi",
> + "camnoc_rt_axi",
> + "camnoc_rt_vfe0",
> + "camnoc_rt_vfe1",
> + "camnoc_rt_vfe2",
> + "camnoc_rt_vfe_lite",
> + "cam_top_ahb",
> + "cam_top_fast_ahb",
> + "csid",
> + "csid_csiphy_rx",
> + "csiphy0",
> + "csiphy0_timer",
> + "csiphy1",
> + "csiphy1_timer",
> + "csiphy2",
> + "csiphy2_timer",
> + "csiphy3",
> + "csiphy3_timer",
> + "csiphy4",
> + "csiphy4_timer",
> + "csiphy5",
> + "csiphy5_timer",
> + "gcc_hf_axi",
> + "vfe0",
> + "vfe0_fast_ahb",
> + "vfe1",
> + "vfe1_fast_ahb",
> + "vfe2",
> + "vfe2_fast_ahb",
> + "vfe_lite",
> + "vfe_lite_ahb",
> + "vfe_lite_cphy_rx",
> + "vfe_lite_csid",
> + "qdss_debug_xo",
> + "camnoc_ipe_nps",
> + "camnoc_ofe",
> + "gcc_sf_axi",
> + "icp0",
> + "icp0_ahb",
> + "icp1",
> + "icp1_ahb",
> + "ipe_nps",
> + "ipe_nps_ahb",
> + "ipe_nps_fast_ahb",
> + "ipe_pps",
> + "ipe_pps_fast_ahb",
> + "jpeg",
> + "ofe_ahb",
> + "ofe_anchor",
> + "ofe_anchor_fast_ahb",
> + "ofe_hdr",
> + "ofe_hdr_fast_ahb",
> + "ofe_main",
> + "ofe_main_fast_ahb",
> + "vfe0_bayer",
> + "vfe0_bayer_fast_ahb",
> + "vfe1_bayer",
> + "vfe1_bayer_fast_ahb",
> + "vfe2_bayer",
> + "vfe2_bayer_fast_ahb";
> +
> + interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 376 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 448 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 271 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 277 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 463 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 657 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 372 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 475 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 456 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 664 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 702 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 348 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 349 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 413 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 416 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 417 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
> + "csiphy4",
> + "csiphy5",
> + "vfe0",
> + "vfe1",
> + "vfe2",
> + "vfe_lite0",
> + "vfe_lite1",
> + "camnoc_nrt",
> + "camnoc_rt",
> + "icp0",
> + "icp1",
> + "jpeg_dma",
> + "jpeg_enc",
> + "rt_cdm0",
> + "rt_cdm1",
> + "rt_cdm2",
> + "rt_cdm3",
> + "rt_cdm4",
> + "tpg0",
> + "tpg1",
> + "tpg2";
> +
> + interconnects = <&gem_noc_master_appss_proc QCOM_ICC_TAG_ACTIVE_ONLY
> + &config_noc_slave_camera_cfg QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mmss_noc_master_camnoc_hf QCOM_ICC_TAG_ALWAYS
> + &mc_virt_slave_ebi1 QCOM_ICC_TAG_ALWAYS>,
> + <&mmss_noc_master_camnoc_sf_icp QCOM_ICC_TAG_ALWAYS
> + &mc_virt_slave_ebi1 QCOM_ICC_TAG_ALWAYS>,
> + <&mmss_noc_master_camnoc_sf QCOM_ICC_TAG_ALWAYS
> + &mc_virt_slave_ebi1 QCOM_ICC_TAG_ALWAYS>;
> + interconnect-names = "ahb",
> + "hf_mnoc",
> + "sf_icp_mnoc",
> + "sf_mnoc";
> +
> + iommus = <&apps_smmu 0x1c00 0x00>,
> + <&apps_smmu 0x18c0 0x00>,
> + <&apps_smmu 0x1980 0x00>,
> + <&apps_smmu 0x1840 0x00>,
> + <&apps_smmu 0x1800 0x00>,
> + <&apps_smmu 0x18a0 0x00>,
> + <&apps_smmu 0x1880 0x00>,
> + <&apps_smmu 0x1820 0x00>,
> + <&apps_smmu 0x1860 0x00>;
> +
> + power-domains = <&camcc_cam_cc_vfe_0_gdsc>,
> + <&camcc_cam_cc_vfe_1_gdsc>,
> + <&camcc_cam_cc_vfe_2_gdsc>,
> + <&camcc_cam_cc_titan_top_gdsc>,
> + <&camcc_cam_cc_ipe_gdsc>,
> + <&camcc_cam_cc_ofe_gdsc>;
> + power-domain-names = "vfe0",
> + "vfe1",
> + "vfe2",
> + "top",
> + "ipe",
> + "ofe";
> +
> + vdd-csiphy0-0p8-supply = <&vreg_0p8_supply>;
> + vdd-csiphy0-1p2-supply = <&vreg_1p2_supply>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + csiphy_ep0: endpoint {
> + data-lanes = <0 1>;
> + remote-endpoint = <&sensor_ep>;
> + };
> + };
> + };
> + };
> + };
>
Thanks for following up on this.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
On Thu, Nov 13, 2025 at 07:29:18PM -0800, Hangxiang Ma wrote: > Add the compatible string "qcom,kaanapali-camss" to support the Camera > Subsystem (CAMSS) on the Qualcomm Kaanapali platform. > > The Kaanapali platform provides: > - 3 x VFE, 5 RDI per VFE > - 2 x VFE Lite, 4 RDI per VFE Lite > - 3 x CSID > - 2 x CSID Lite > - 6 x CSIPHY > > Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com> > --- > .../bindings/media/qcom,kaanapali-camss.yaml | 639 +++++++++++++++++++++ > 1 file changed, 639 insertions(+) Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.