On 2/16/26 10:54, Luca Weiss wrote:
Add a node for the CAMSS on the SM6350 SoC.
Signed-off-by: Luca Weiss <[email protected]>
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 233 +++++++++++++++++++++++++++++++++++
1 file changed, 233 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi
b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index 9f9b9f9af0da..9ff9508c5ce6 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -2161,6 +2161,239 @@ cci1_i2c0: i2c-bus@0 {
/* SM6350 seems to have cci1_i2c1 on gpio2 & gpio3 but
unused downstream */
};
+ camss: isp@acb3000 {
+ compatible = "qcom,sm6350-camss";
+
+ reg = <0x0 0x0acb3000 0x0 0x1000>,
+ <0x0 0x0acba000 0x0 0x1000>,
+ <0x0 0x0acc1000 0x0 0x1000>,
+ <0x0 0x0acc8000 0x0 0x1000>,
+ <0x0 0x0ac65000 0x0 0x1000>,
+ <0x0 0x0ac66000 0x0 0x1000>,
+ <0x0 0x0ac67000 0x0 0x1000>,
+ <0x0 0x0ac68000 0x0 0x1000>,
+ <0x0 0x0acaf000 0x0 0x4000>,
+ <0x0 0x0acb6000 0x0 0x4000>,
+ <0x0 0x0acbd000 0x0 0x4000>,
+ <0x0 0x0acc4000 0x0 0x4000>,
+ <0x0 0x0ac18000 0x0 0x3000>,
+ <0x0 0x0ac00000 0x0 0x6000>,
+ <0x0 0x0ac10000 0x0 0x8000>,
+ <0x0 0x0ac6f000 0x0 0x8000>,
+ <0x0 0x0ac42000 0x0 0x4600>,
+ <0x0 0x01fc0000 0x0 0x40000>,
I notice that this memory range is very distant, can somebody with
the access to the specs confirm that it is a part of CAMSS IP?
+ <0x0 0x0ac48000 0x0 0x1000>,
+ <0x0 0x0ac40000 0x0 0x1000>,
+ <0x0 0x0ac87000 0x0 0xa000>,
+ <0x0 0x0ac52000 0x0 0x4000>,
+ <0x0 0x0ac4e000 0x0 0x4000>,
+ <0x0 0x0ac6b000 0x0 0xa00>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite",
+ "a5_csr",
+ "a5_qgic",
+ "a5_sierra",
+ "bps",
+ "camnoc",
+ "core_top_csr_tcsr",
Looking at the memory map I have a feeling that this "core_top_csr_tcsr"
is not a natural part of CAMSS IPs, it should be clarified by someone
else.
+ "cpas_cdm",
+ "cpas_top",
+ "ipe",
+ "jpeg_dma",
+ "jpeg_enc",
+ "lrme";
+
The .dtsi change strictly follows the dt bindings description, won't
repeat previously given concerns here, so
Reviewed-by: Vladimir Zapolskiy <[email protected]>
--
Best wishes,
Vladimir
