Add bindings for qcom,kaanapali-camss in order to support the camera
subsystem for Kaanapali.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../bindings/media/qcom,kaanapali-camss.yaml | 369 +++++++++++++++++++++
1 file changed, 369 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..82f427bd036b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
@@ -0,0 +1,369 @@
+# 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: qdss_debug_xo
+ - 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
+
+ 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:
+ TFE0 GDSC - Thin Front End, Global Distributed Switch Controller.
+ - description:
+ TFE1 GDSC - Thin Front End, Global Distributed Switch Controller.
+ - description:
+ TFE2 GDSC - Thin Front End, Global Distributed Switch Controller.
+ - description:
+ Titan GDSC - Titan ISP Block Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: tfe0
+ - const: tfe1
+ - const: tfe2
+ - const: top
+
+ vdd-csiphy-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSI PHYs core block.
+
+ vdd-csiphy-1p2-supply:
+ description:
+ Phandle to 1.2V regulator supply to CSI PHYs pll block.
+
+ 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 on CSI0.
+
+ 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
+ - vdd-csiphy-0p8-supply
+ - vdd-csiphy-1p2-supply
+ - ports
+
+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>;
+
+ camss: 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_qdss_debug_xo_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>;
+
+ 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",
+ "qdss_debug_xo",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe2",
+ "vfe2_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ 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 = "tfe0",
+ "tfe1",
+ "tfe2",
+ "top";
+
+ vdd-csiphy-0p8-supply = <&csiphy_0p8_supply>;
+ vdd-csiphy-1p2-supply = <&csiphy_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 Thu, Oct 23, 2025 at 02:14:34AM -0700, Hangxiang Ma wrote:
> Add bindings for qcom,kaanapali-camss in order to support the camera
What is qcom,kaanapali-camss? Sounds like a compatible and you cannot
add bindings for a compatible. Instead add bindings for hardware, so
explain here hardware.
You could easily use `git log` to see how such commits are written
instead of pasting here your downstream practice.
> subsystem for Kaanapali.
>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,kaanapali-camss.yaml | 369 +++++++++++++++++++++
> 1 file changed, 369 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..82f427bd036b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> @@ -0,0 +1,369 @@
> +# 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: qdss_debug_xo
No, I told many times you are supposed to use same order as last
generation. Stop doing this alphabetical ordering or ordering by value.
The previous generation has here vfe0.
> + - 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
> +
> + 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
Why previously this was called hf_0 but now hf?
> +
> + iommus:
> + maxItems: 1
> +
> + power-domains:
> + items:
> + - description:
> + TFE0 GDSC - Thin Front End, Global Distributed Switch Controller.
> + - description:
> + TFE1 GDSC - Thin Front End, Global Distributed Switch Controller.
> + - description:
> + TFE2 GDSC - Thin Front End, Global Distributed Switch Controller.
> + - description:
> + Titan GDSC - Titan ISP Block Global Distributed Switch Controller.
> +
> + power-domain-names:
> + items:
> + - const: tfe0
> + - const: tfe1
> + - const: tfe2
Why not using the same names as before? It really does not matter that
it is thin or image, all of them are the same because only the
difference against top matters.
> + - const: top
> +
> + vdd-csiphy-0p8-supply:
> + description:
> + Phandle to a 0.8V regulator supply to CSI PHYs core block.
> +
> + vdd-csiphy-1p2-supply:
> + description:
> + Phandle to 1.2V regulator supply to CSI PHYs pll block.
> +
> + 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 on CSI0.
> +
> + 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
> + - vdd-csiphy-0p8-supply
> + - vdd-csiphy-1p2-supply
> + - ports
> +
> +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>;
> +
> + camss: isp@9253000 {
Drop unused label
> + compatible = "qcom,kaanapali-camss";
Best regards,
Krzysztof
On 10/28/2025 1:09 AM, Krzysztof Kozlowski wrote:
> On Thu, Oct 23, 2025 at 02:14:34AM -0700, Hangxiang Ma wrote:
>> Add bindings for qcom,kaanapali-camss in order to support the camera
> What is qcom,kaanapali-camss? Sounds like a compatible and you cannot
> add bindings for a compatible. Instead add bindings for hardware, so
> explain here hardware.
>
> You could easily use `git log` to see how such commits are written
> instead of pasting here your downstream practice.
>
>> subsystem for Kaanapali.
>>
>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>> ---
>> .../bindings/media/qcom,kaanapali-camss.yaml | 369 +++++++++++++++++++++
>> 1 file changed, 369 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..82f427bd036b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>> @@ -0,0 +1,369 @@
>> +# 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: qdss_debug_xo
> No, I told many times you are supposed to use same order as last
> generation. Stop doing this alphabetical ordering or ordering by value.
> The previous generation has here vfe0.
>
>> + - 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
>> +
>> + 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
> Why previously this was called hf_0 but now hf?
Hi Krzysztof, the interconnect driver exposes only one node 'camnoc_hf'
to the camera driver, with it internally managing the voting on hf_0 and
hf_1 clients. The traffic from the Real Time blocks in camera go through
both HF_0 and HF_1, with the former being the primary. This change
correctly represents that the BW voting is for the whole of the HF
client. Please let me know if you have any further questions and we
would be happy to answer. Thank you.
>> +
>> + iommus:
>> + maxItems: 1
>> +
>> + power-domains:
>> + items:
>> + - description:
>> + TFE0 GDSC - Thin Front End, Global Distributed Switch Controller.
>> + - description:
>> + TFE1 GDSC - Thin Front End, Global Distributed Switch Controller.
>> + - description:
>> + TFE2 GDSC - Thin Front End, Global Distributed Switch Controller.
>> + - description:
>> + Titan GDSC - Titan ISP Block Global Distributed Switch Controller.
>> +
>> + power-domain-names:
>> + items:
>> + - const: tfe0
>> + - const: tfe1
>> + - const: tfe2
> Why not using the same names as before? It really does not matter that
> it is thin or image, all of them are the same because only the
> difference against top matters.
Right, this is done to maintain the consistency with the clock driver on
Kaanapali along with the terminology used elsewhere in the Kaanapali
camss patches (wherever feasible). However, we don't mind updating this
if you think otherwise, please advise.
>> + - const: top
>> +
>> + vdd-csiphy-0p8-supply:
>> + description:
>> + Phandle to a 0.8V regulator supply to CSI PHYs core block.
>> +
>> + vdd-csiphy-1p2-supply:
>> + description:
>> + Phandle to 1.2V regulator supply to CSI PHYs pll block.
>> +
>> + 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 on CSI0.
>> +
>> + 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
>> + - vdd-csiphy-0p8-supply
>> + - vdd-csiphy-1p2-supply
>> + - ports
>> +
>> +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>;
>> +
>> + camss: isp@9253000 {
> Drop unused label
>
>> + compatible = "qcom,kaanapali-camss";
> Best regards,
> Krzysztof
>
>
On 28/10/2025 16:22, Vijay Kumar Tumati wrote: >>> + interconnects: >>> + maxItems: 2 >>> + >>> + interconnect-names: >>> + items: >>> + - const: ahb >>> + - const: hf_mnoc >> Why previously this was called hf_0 but now hf? > Hi Krzysztof, the interconnect driver exposes only one node 'camnoc_hf' Drivers don't matter. Interconnect driver does not matter here. You describe this hardware, not interconnect driver. Keep it consistent with previous devices, whichever these are. > to the camera driver, with it internally managing the voting on hf_0 and > hf_1 clients. The traffic from the Real Time blocks in camera go through > both HF_0 and HF_1, with the former being the primary. This change > correctly represents that the BW voting is for the whole of the HF > client. Please let me know if you have any further questions and we > would be happy to answer. Thank you. >>> + >>> + iommus: >>> + maxItems: 1 >>> + >>> + power-domains: >>> + items: >>> + - description: >>> + TFE0 GDSC - Thin Front End, Global Distributed Switch Controller. >>> + - description: >>> + TFE1 GDSC - Thin Front End, Global Distributed Switch Controller. >>> + - description: >>> + TFE2 GDSC - Thin Front End, Global Distributed Switch Controller. >>> + - description: >>> + Titan GDSC - Titan ISP Block Global Distributed Switch Controller. >>> + >>> + power-domain-names: >>> + items: >>> + - const: tfe0 >>> + - const: tfe1 >>> + - const: tfe2 >> Why not using the same names as before? It really does not matter that >> it is thin or image, all of them are the same because only the >> difference against top matters. > Right, this is done to maintain the consistency with the clock driver on Sorry, this makes no sense. This device has nothing to do with clock driver. Don't ever use clock drivers as arguments for doing something in completely different place. Not mentioning that drivers don't matter much for the bindings, so I really do not get what you try to explain here. Best regards, Krzysztof
On 10/28/2025 9:56 AM, Krzysztof Kozlowski wrote: > On 28/10/2025 16:22, Vijay Kumar Tumati wrote: >>>> + interconnects: >>>> + maxItems: 2 >>>> + >>>> + interconnect-names: >>>> + items: >>>> + - const: ahb >>>> + - const: hf_mnoc >>> Why previously this was called hf_0 but now hf? >> Hi Krzysztof, the interconnect driver exposes only one node 'camnoc_hf' > Drivers don't matter. Interconnect driver does not matter here. You > describe this hardware, not interconnect driver. > > Keep it consistent with previous devices, whichever these are. There has been a mixed usage in the previous devices but this (hf) is consistent with the recently added ones, like x1e80100 and 2290. > >> to the camera driver, with it internally managing the voting on hf_0 and >> hf_1 clients. The traffic from the Real Time blocks in camera go through >> both HF_0 and HF_1, with the former being the primary. This change >> correctly represents that the BW voting is for the whole of the HF >> client. Please let me know if you have any further questions and we >> would be happy to answer. Thank you. >>>> + >>>> + iommus: >>>> + maxItems: 1 >>>> + >>>> + power-domains: >>>> + items: >>>> + - description: >>>> + TFE0 GDSC - Thin Front End, Global Distributed Switch Controller. >>>> + - description: >>>> + TFE1 GDSC - Thin Front End, Global Distributed Switch Controller. >>>> + - description: >>>> + TFE2 GDSC - Thin Front End, Global Distributed Switch Controller. >>>> + - description: >>>> + Titan GDSC - Titan ISP Block Global Distributed Switch Controller. >>>> + >>>> + power-domain-names: >>>> + items: >>>> + - const: tfe0 >>>> + - const: tfe1 >>>> + - const: tfe2 >>> Why not using the same names as before? It really does not matter that >>> it is thin or image, all of them are the same because only the >>> difference against top matters. >> Right, this is done to maintain the consistency with the clock driver on > Sorry, this makes no sense. This device has nothing to do with clock > driver. Don't ever use clock drivers as arguments for doing something in > completely different place. > > Not mentioning that drivers don't matter much for the bindings, so I > really do not get what you try to explain here. Understood. I meant to say that it is consistent with the naming for the TFE device that is available on Kaanapali. If our intention is to keep the names in the bindings same as previous generations despite the changing HW architectures, we could change these to IFEs, to be consistent with previous generations. Please advise. Appreciate your inputs here. > > Best regards, > Krzysztof
On 28/10/2025 18:45, Vijay Kumar Tumati wrote: >>>>> + - const: tfe1 >>>>> + - const: tfe2 >>>> Why not using the same names as before? It really does not matter that >>>> it is thin or image, all of them are the same because only the >>>> difference against top matters. >>> Right, this is done to maintain the consistency with the clock driver on >> Sorry, this makes no sense. This device has nothing to do with clock >> driver. Don't ever use clock drivers as arguments for doing something in >> completely different place. >> >> Not mentioning that drivers don't matter much for the bindings, so I >> really do not get what you try to explain here. > > Understood. I meant to say that it is consistent with the naming for the > TFE device that is available on Kaanapali. If our intention is to keep > the names in the bindings same as previous generations despite the > changing HW architectures, we could change these to IFEs, to be > consistent with previous generations. Please advise. Appreciate your > inputs here. You name these based on the provider, the clock controller or whatever controller, and that's the mistake. Names are coming from this device point of view, from the consumer. This device does not care whether this is Thin or Image or Whatever GDSC. Best regards, Krzysztof
On 10/28/2025 11:39 AM, Krzysztof Kozlowski wrote: > On 28/10/2025 18:45, Vijay Kumar Tumati wrote: >>>>>> + - const: tfe1 >>>>>> + - const: tfe2 >>>>> Why not using the same names as before? It really does not matter that >>>>> it is thin or image, all of them are the same because only the >>>>> difference against top matters. >>>> Right, this is done to maintain the consistency with the clock driver on >>> Sorry, this makes no sense. This device has nothing to do with clock >>> driver. Don't ever use clock drivers as arguments for doing something in >>> completely different place. >>> >>> Not mentioning that drivers don't matter much for the bindings, so I >>> really do not get what you try to explain here. >> Understood. I meant to say that it is consistent with the naming for the >> TFE device that is available on Kaanapali. If our intention is to keep >> the names in the bindings same as previous generations despite the >> changing HW architectures, we could change these to IFEs, to be >> consistent with previous generations. Please advise. Appreciate your >> inputs here. > > You name these based on the provider, the clock controller or whatever > controller, and that's the mistake. Names are coming from this device > point of view, from the consumer. This device does not care whether this > is Thin or Image or Whatever GDSC. > > > Best regards, > Krzysztof Gotcha. Thanks for the explanation, Krzysztof. Agree with you, we are just trying to differentiate the GDSCs / power domains for TOP and to each of the front end modules, to control them independently based on the usage, as we have one common device 'camss' in the DT. Looking at this device as a whole (as a consumer), it has one TOP GDSC and one GDSC to each of the TFEs (the front end device itself in this architecture is called TFE) separately for clock gating. TFE_0_GDSC is enabled only when TFE0 is used, for instance. That way it seemed fitting too. But if that's not OK, we have two options. One, we change this to "ife" to be consistent with previous targets or the second, use even more superficial name like "xfe_0", "xfe_1"etc. for power domain names that represent any front end (thin or otherwise, which like you said doesn't matter here) and can be adopted to all future targets. Please let us know your thoughts. Thank you very much.
On 28/10/2025 09:09, Krzysztof Kozlowski wrote: > On Thu, Oct 23, 2025 at 02:14:34AM -0700, Hangxiang Ma wrote: >> Add bindings for qcom,kaanapali-camss in order to support the camera > > What is qcom,kaanapali-camss? Sounds like a compatible and you cannot > add bindings for a compatible. Instead add bindings for hardware, so > explain here hardware. > > You could easily use `git log` to see how such commits are written > instead of pasting here your downstream practice. > And of course standard comment: A nit, subject: drop second/last, redundant "binding". The "dt-bindings" prefix is already stating that these are bindings. See also: https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18 Best regards, Krzysztof
On 10/28/2025 4:10 PM, Krzysztof Kozlowski wrote: > On 28/10/2025 09:09, Krzysztof Kozlowski wrote: >> On Thu, Oct 23, 2025 at 02:14:34AM -0700, Hangxiang Ma wrote: >>> Add bindings for qcom,kaanapali-camss in order to support the camera >> >> What is qcom,kaanapali-camss? Sounds like a compatible and you cannot >> add bindings for a compatible. Instead add bindings for hardware, so >> explain here hardware. >> >> You could easily use `git log` to see how such commits are written >> instead of pasting here your downstream practice. >> > > > And of course standard comment: > > A nit, subject: drop second/last, redundant "binding". The "dt-bindings" > prefix is already stating that these are bindings. > See also: > https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18 > > > Best regards, > Krzysztof Will address other comments and follow this standard in next revision. --- Hangxiang
© 2016 - 2026 Red Hat, Inc.