Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
From: Bryan O'Donoghue
Date: Fri Oct 24 2025 - 04:50:31 EST
On 23/10/2025 19:06, Vijay Kumar Tumati wrote:
On 10/23/2025 4:13 AM, Vladimir Zapolskiy wrote:
Hi Vijay.
On 10/23/25 07:52, Vijay Kumar Tumati wrote:
On 10/16/2025 5:27 PM, Vladimir Zapolskiy wrote:
On 10/17/25 02:53, Vijay Kumar Tumati wrote:
On 10/15/2025 12:45 PM, Vladimir Zapolskiy wrote:
On 10/15/25 05:56, Hangxiang Ma wrote:
Add bindings for qcom,kaanapali-camss in order to support the camera
subsystem for Kaanapali.
Signed-off-by: Hangxiang Ma <hangxiang.ma@xxxxxxxxxxxxxxxx>
---
.../bindings/media/qcom,kaanapali-camss.yaml | 494
+++++++++++++++++++++
1 file changed, 494 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..d04c21103cfd
--- /dev/null
+++
b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
@@ -0,0 +1,494 @@
+# 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@xxxxxxxxxxxxxxxx>
+
+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
The list of 'clock-names' values is not alphanumerically sorted.
+
+ interrupts:
+ maxItems: 16
+ interrupt-names:
Missing empty line to separate properties.
+ 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_0_mnoc
Please rename "hf_0_mnoc" to "hf_mnoc", see qcom,qcm2290-camss.yaml
etc.
+
+ 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
Please remove all 'tfeX' power domains, they are not going to be
utilized
any time soon.
When 'power-domains' list is just a single Titan GDSC,
'power-domain-names'
property is not needed.
+ - const: top
+
+ vdda-pll-supply:
+ description:
+ Phandle to 1.2V regulator supply to PHY refclk pll block.
+
+ vdda-phy0-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ vdda-phy1-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ vdda-phy2-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ vdda-phy3-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ vdda-phy4-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ vdda-phy5-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
What is the difference between vdda-phyX-supply properties, why do
you
need so many of them, when their descriptions say they are all the
same?
Each of these supply power to a specific CSIPHY and could be different
based on the board architecture. But I agree that the description
should
probably capture that than just relying on the name.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ properties:
+ port@0:
Please use
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:
+ clock-lanes:
+ maxItems: 1
Please remove 'clock-lanes' property, it is non-configurable,
redundant
and tends to store some irrelevant value.
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
The 'clock-lanes' property is expected to be removed.
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI1.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI2.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI3.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - vdda-pll-supply
+ - vdda-phy0-supply
+ - vdda-phy1-supply
+ - vdda-phy2-supply
+ - vdda-phy3-supply
+ - vdda-phy4-supply
+ - vdda-phy5-supply
Please exclude supplies from the list of required properties.
One of these supplies is required based which PHY the use case is
being
run. Can you please advise how to handle that? Thanks.
1. Please rename all of them, reference to qcom,x1e80100-camss.yaml,
qcom,qcm2290-camss.yaml or published on linux-media
qcom,sm8650-camss.yaml
2. Remove all of them from the list of required properties, and in a
board
specific dts file add only the neccesary ones, that's it.
Thanks. We will try to follow the same for rev3. Just a caveat though.
If, for instance, two CSIPHYs have different 1.2 supplies and they are
required to be operated concurrently, it may be is a problem? as we can
It should not be a problem, you can add two regulators, and it's fine,
anyway all of them shall be optional properties, because it's unknown in
advance which ones are actually needed.
put only one of those in the board specific DTS for the 1.2 supply node
(ex: vdd-csiphy-1p2 in SM2290). Is it not? However, if we don't have
such a use case requirement on the upstream may be it's OK. Thank you.
Link to the published SM8650 CAMSS dt bindings, please follow this model:
https://lore.kernel.org/linux-media/20251017031131.2232687-2-
vladimir.zapolskiy@xxxxxxxxxx/
Please note the chosen naming scheme, when the supply property names
follow the SoC pad namings one to one.
Thanks @Vladimir. Yes, this make sense if all of the reference and
customer boards follow the internal power grid design. But agreed that
this is all board specific. Please let us know your thoughts on the v3
bindings for KNP. They mimic the existing 2290 and x1e80100 bindings.
Thank you.
I'd expect to see both the 1p2 and 0p8 for each PHY listed in your bindings.
Without looking at the KNP docs it would be very strange to find the
PHYs share one of these power-rails as an external input from the PCB.
Even if they do, the established pattern for bindings is to describe
each as an individual rail.
Also including the voltage level is
- More consistent with other PHY bindings
- Information that is actually useful when reading a binding
or aligning a binding to a schematic.
---
bod