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 | 406 +++++++++++++++++++++
1 file changed, 406 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..c34867022fd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
@@ -0,0 +1,406 @@
+# 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:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,kaanapali-camss
+
+ reg:
+ maxItems: 16
+
+ 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
+
+ clocks:
+ maxItems: 34
+
+ 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
+
+ interrupts:
+ maxItems: 16
+
+ 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
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_mnoc
+
+ iommus:
+ maxItems: 1
+
+ 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 GDSC - Titan ISP Block Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: ife2
+ - const: top
+
+ 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>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc_cam_cc_camnoc_nrt_axi_clk>,
+ <&camcc_cam_cc_camnoc_rt_axi_clk>,
+ <&camcc_cam_cc_camnoc_rt_tfe_0_main_clk>,
+ <&camcc_cam_cc_camnoc_rt_tfe_1_main_clk>,
+ <&camcc_cam_cc_camnoc_rt_tfe_2_main_clk>,
+ <&camcc_cam_cc_camnoc_rt_ife_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_tfe_0_main_clk>,
+ <&camcc_cam_cc_tfe_0_main_fast_ahb_clk>,
+ <&camcc_cam_cc_tfe_1_main_clk>,
+ <&camcc_cam_cc_tfe_1_main_fast_ahb_clk>,
+ <&camcc_cam_cc_tfe_2_main_clk>,
+ <&camcc_cam_cc_tfe_2_main_fast_ahb_clk>,
+ <&camcc_cam_cc_ife_lite_clk>,
+ <&camcc_cam_cc_ife_lite_ahb_clk>,
+ <&camcc_cam_cc_ife_lite_cphy_rx_clk>,
+ <&camcc_cam_cc_ife_lite_csid_clk>,
+ <&camcc_cam_cc_qdss_debug_xo_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";
+
+ 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>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ 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>;
+ interconnect-names = "ahb",
+ "hf_mnoc";
+
+ iommus = <&apps_smmu 0x1c00 0x00>;
+
+ power-domains = <&camcc_cam_cc_tfe_0_gdsc>,
+ <&camcc_cam_cc_tfe_1_gdsc>,
+ <&camcc_cam_cc_tfe_2_gdsc>,
+ <&camcc_cam_cc_titan_top_gdsc>;
+ power-domain-names = "ife0",
+ "ife1",
+ "ife2",
+ "top";
+
+ 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 31/10/2025 02:59, 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 | 406 +++++++++++++++++++++ > 1 file changed, 406 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..c34867022fd1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml > @@ -0,0 +1,406 @@ > +# 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: > + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. > + > +properties: > + compatible: > + const: qcom,kaanapali-camss > + > + reg: > + maxItems: 16 > + > + 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 No test pattern generator on this part ? We have patches in-flight to add TPG so it makes no sense to omit these registers from current or new submissions. https://lore.kernel.org/linux-media/20251017-camss_tpg-v5-1-cafe3ad42163@oss.qualcomm.com/ While we're at it we should consider adding in the other key functional blocks. OFE, IPE etc, there's no harm in including the registers even if the intention and outcome is never switching that functionality on. > + > + clocks: > + maxItems: 34 > + > + 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 > + > + interrupts: > + maxItems: 16 > + > + 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 > + > + interconnects: > + maxItems: 2 > + > + interconnect-names: > + items: > + - const: ahb > + - const: hf_mnoc > + > + iommus: > + maxItems: 1 This can't be right. The experience we are having with Iris for example shows that restricting the iommus is wrong. For this and future bindings I'm expecting to see the full list of AC_VM_HLOS S2 VMID targets. The second we try to switch on say something like the JPEG encoder this list and its upstream binding becomes a problem. - S1_IFE_HLOS @ 0x1c00 - S1_CDM_BPS_IPS_HLOS @ 0x1820 - S1_CDM_BPS_IPS_HLOS @ 0x18c0 - S1_CDM_BPS_IPS_HLOS @ 0x1980 - S1_CDM_BPS_IPS_HLOS @ 0x1800 - S1_JPEG_HLOS @ 0x18a0 - S1_RT_CDM_HLOS @ 0x1860 - S1_CDM_BPS_IPE_HLOS @ 0x1840 - S1_CDM_BPS_IPE_HLOS @ 0x1880 - S1_CRE_HLOS @ 0x18e0 The ICP mappings can come later if ever via iommu-maps.. --- bod
On 10/31/2025 6:50 AM, Bryan O'Donoghue wrote: > On 31/10/2025 02:59, 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 | 406 >> +++++++++++++++++++++ >> 1 file changed, 406 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..c34867022fd1 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml >> @@ -0,0 +1,406 @@ >> +# 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: >> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. >> + >> +properties: >> + compatible: >> + const: qcom,kaanapali-camss >> + >> + reg: >> + maxItems: 16 >> + >> + 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 > > No test pattern generator on this part ? > > We have patches in-flight to add TPG so it makes no sense to omit > these registers from current or new submissions. > > https://lore.kernel.org/linux-media/20251017-camss_tpg-v5-1-cafe3ad42163@oss.qualcomm.com/ > > > While we're at it we should consider adding in the other key > functional blocks. > > OFE, IPE etc, there's no harm in including the registers even if the > intention and outcome is never switching that functionality on. > Hi Bryan, we have quite a few register spaces on Kaanapali or any other target that are not required for the RDI only CAMSS driver, including ICP, JPEG, OFE, IPE, CDMs and some custom modules like CRE along with the TPG. So do I understand your suggestion correctly that you advise all of those are enlisted in the DTSI and the bindings although the driver doesn't make use of or map them? >> + >> + clocks: >> + maxItems: 34 >> + >> + 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 >> + >> + interrupts: >> + maxItems: 16 >> + >> + 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 >> + >> + interconnects: >> + maxItems: 2 >> + >> + interconnect-names: >> + items: >> + - const: ahb >> + - const: hf_mnoc >> + >> + iommus: >> + maxItems: 1 > > > This can't be right. > > The experience we are having with Iris for example shows that > restricting the iommus is wrong. > > For this and future bindings I'm expecting to see the full list of > AC_VM_HLOS S2 VMID targets. > > The second we try to switch on say something like the JPEG encoder > this list and its upstream binding becomes a problem. > > - S1_IFE_HLOS @ 0x1c00 > - S1_CDM_BPS_IPS_HLOS @ 0x1820 > - S1_CDM_BPS_IPS_HLOS @ 0x18c0 > - S1_CDM_BPS_IPS_HLOS @ 0x1980 > - S1_CDM_BPS_IPS_HLOS @ 0x1800 > - S1_JPEG_HLOS @ 0x18a0 > - S1_RT_CDM_HLOS @ 0x1860 > - S1_CDM_BPS_IPE_HLOS @ 0x1840 > - S1_CDM_BPS_IPE_HLOS @ 0x1880 > - S1_CRE_HLOS @ 0x18e0 > > The ICP mappings can come later if ever via iommu-maps.. > > --- > bod > Similar to the above, You are advising to declare all the S2 HLOS mapped streams in the bindings and the DTSI? If we do that in the DTSI, I wonder how we can specifically map the RDI output buffers to the IFE context bank only, for instance, going by the current CAMSS driver implementation. Perhaps, IFE should be the first one in the list for now and the driver will be extended later when we support more devices? I will explore on that. Good to understand these details and practices. Thank you.
On Fri, Oct 31, 2025 at 10:39:44AM -0700, Vijay Kumar Tumati wrote: > > On 10/31/2025 6:50 AM, Bryan O'Donoghue wrote: > > On 31/10/2025 02:59, 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 | 406 > > > +++++++++++++++++++++ > > > 1 file changed, 406 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..c34867022fd1 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml > > > @@ -0,0 +1,406 @@ > > > +# 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: > > > + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. > > > + > > > +properties: > > > + compatible: > > > + const: qcom,kaanapali-camss > > > + > > > + reg: > > > + maxItems: 16 > > > + > > > + 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 > > > > No test pattern generator on this part ? > > > > We have patches in-flight to add TPG so it makes no sense to omit these > > registers from current or new submissions. > > > > https://lore.kernel.org/linux-media/20251017-camss_tpg-v5-1-cafe3ad42163@oss.qualcomm.com/ > > > > > > While we're at it we should consider adding in the other key functional > > blocks. > > > > OFE, IPE etc, there's no harm in including the registers even if the > > intention and outcome is never switching that functionality on. > > > Hi Bryan, we have quite a few register spaces on Kaanapali or any other > target that are not required for the RDI only CAMSS driver, including ICP, Please read writing bindings doc. It answers this question exactly. I'm marking it as changes requested in DT patchwork. Best regards, Krzysztof
On 11/2/2025 8:06 AM, Krzysztof Kozlowski wrote: > On Fri, Oct 31, 2025 at 10:39:44AM -0700, Vijay Kumar Tumati wrote: >> On 10/31/2025 6:50 AM, Bryan O'Donoghue wrote: >>> On 31/10/2025 02:59, 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 | 406 >>>> +++++++++++++++++++++ >>>> 1 file changed, 406 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..c34867022fd1 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml >>>> @@ -0,0 +1,406 @@ >>>> +# 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: >>>> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. >>>> + >>>> +properties: >>>> + compatible: >>>> + const: qcom,kaanapali-camss >>>> + >>>> + reg: >>>> + maxItems: 16 >>>> + >>>> + 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 >>> No test pattern generator on this part ? >>> >>> We have patches in-flight to add TPG so it makes no sense to omit these >>> registers from current or new submissions. >>> >>> https://lore.kernel.org/linux-media/20251017-camss_tpg-v5-1-cafe3ad42163@oss.qualcomm.com/ >>> >>> >>> While we're at it we should consider adding in the other key functional >>> blocks. >>> >>> OFE, IPE etc, there's no harm in including the registers even if the >>> intention and outcome is never switching that functionality on. >>> >> Hi Bryan, we have quite a few register spaces on Kaanapali or any other >> target that are not required for the RDI only CAMSS driver, including ICP, > Please read writing bindings doc. It answers this question exactly. > > I'm marking it as changes requested in DT patchwork. > > Best regards, > Krzysztof Sure, thank you Bryan, Krzysztof. Appreciate your inputs and patience. We will address this in the next revision.
On 31/10/2025 17:39, Vijay Kumar Tumati wrote: > > On 10/31/2025 6:50 AM, Bryan O'Donoghue wrote: >> On 31/10/2025 02:59, 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 | 406 ++++++++++ >>> +++++++++++ >>> 1 file changed, 406 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..c34867022fd1 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml >>> @@ -0,0 +1,406 @@ >>> +# 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: >>> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. >>> + >>> +properties: >>> + compatible: >>> + const: qcom,kaanapali-camss >>> + >>> + reg: >>> + maxItems: 16 >>> + >>> + 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 >> >> No test pattern generator on this part ? >> >> We have patches in-flight to add TPG so it makes no sense to omit >> these registers from current or new submissions. >> >> https://lore.kernel.org/linux-media/20251017-camss_tpg-v5-1- >> cafe3ad42163@oss.qualcomm.com/ >> >> While we're at it we should consider adding in the other key >> functional blocks. >> >> OFE, IPE etc, there's no harm in including the registers even if the >> intention and outcome is never switching that functionality on. >> > Hi Bryan, we have quite a few register spaces on Kaanapali or any other > target that are not required for the RDI only CAMSS driver, including > ICP, JPEG, OFE, IPE, CDMs and some custom modules like CRE along with > the TPG. So do I understand your suggestion correctly that you advise > all of those are enlisted in the DTSI and the bindings although the > driver doesn't make use of or map them? TPG is in process of being upstreamed by qcom. I think the list of registers above should be included in the dts because the DTS is a description of hardware, not a description of camss/rdi. The point of DTS is to do that, describe hardware and to be consumable outside of the upstream linux kernel. u-boot, BSD, potentially even a downstream Linux kernel or driver. >>> + >>> + clocks: >>> + maxItems: 34 >>> + >>> + 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 >>> + >>> + interrupts: >>> + maxItems: 16 >>> + >>> + 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 >>> + >>> + interconnects: >>> + maxItems: 2 >>> + >>> + interconnect-names: >>> + items: >>> + - const: ahb >>> + - const: hf_mnoc >>> + >>> + iommus: >>> + maxItems: 1 >> >> >> This can't be right. >> >> The experience we are having with Iris for example shows that >> restricting the iommus is wrong. >> >> For this and future bindings I'm expecting to see the full list of >> AC_VM_HLOS S2 VMID targets. >> >> The second we try to switch on say something like the JPEG encoder >> this list and its upstream binding becomes a problem. >> >> - S1_IFE_HLOS @ 0x1c00 >> - S1_CDM_BPS_IPS_HLOS @ 0x1820 >> - S1_CDM_BPS_IPS_HLOS @ 0x18c0 >> - S1_CDM_BPS_IPS_HLOS @ 0x1980 >> - S1_CDM_BPS_IPS_HLOS @ 0x1800 >> - S1_JPEG_HLOS @ 0x18a0 >> - S1_RT_CDM_HLOS @ 0x1860 >> - S1_CDM_BPS_IPE_HLOS @ 0x1840 >> - S1_CDM_BPS_IPE_HLOS @ 0x1880 >> - S1_CRE_HLOS @ 0x18e0 >> >> The ICP mappings can come later if ever via iommu-maps.. >> >> --- >> bod >> > Similar to the above, You are advising to declare all the S2 HLOS mapped > streams in the bindings and the DTSI? If we do that in the DTSI, I > wonder how we can specifically map the RDI output buffers to the IFE > context bank only, for instance, going by the current CAMSS driver > implementation. Perhaps, IFE should be the first one in the list for now > and the driver will be extended later when we support more devices? I > will explore on that. Good to understand these details and practices. > Thank you. > We've run into trouble with that in Iris. https://lore.kernel.org/linux-arm-msm/c9d8f76a-513f-4a09-bba4-cb8f0df1d2fe@kernel.org/ The right thing to do is to describe everything that targets the HLOS - main CPU. For non CPU targets - like say setting up the SMMU for the ICP - we could add those mappings in with iommu-map later. The CPU side SID map should be complete. It doesn't divulge any propitiatory information or secret sauce, it just makes our lives easier in the end. --- bod
© 2016 - 2026 Red Hat, Inc.