Add bindings for the Camera Subsystem on the SM6150 SoC
The SM6150 platform provides:
- 2 x VFE (version 170), each with 3 RDI
- 1 x VFE Lite (version 170), each with 4 RDI
- 2 x CSID (version 170)
- 1 x CSID Lite (version 170)
- 3 x CSIPHY (version 2.0.0)
- 1 x BPS (Bayer Processing Segment)
- 1 x ICP (Imaging Control Processor)
- 1 x IPE (Image Postprocessing Engine)
- 1 x JPEG Encoder/Decoder
- 1 x LRME (Low Resolution Motion Estimation)
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
---
.../bindings/media/qcom,sm6150-camss.yaml | 439 +++++++++++++++++++++
1 file changed, 439 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,sm6150-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm6150-camss.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..aa2e44c94b9c0231f6d2f1a30c1e434c0313117f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm6150-camss.yaml
@@ -0,0 +1,439 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sm6150-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6150 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
+
+description:
+ This binding describes the camera subsystem hardware found on SM6150
+ 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.
+
+properties:
+ compatible:
+ const: qcom,sm6150-camss
+
+ reg:
+ items:
+ - description: Registers for CSID 0
+ - description: Registers for CSID 1
+ - description: Registers for CSID Lite
+ - description: Registers for CSIPHY 0
+ - description: Registers for CSIPHY 1
+ - description: Registers for CSIPHY 2
+ - description: Registers for VFE 0
+ - description: Registers for VFE 1
+ - description: Registers for VFE Lite
+ - description: Registers for BPS (Bayer Processing Segment)
+ - description: Registers for CAMNOC
+ - description: Registers for CPAS CDM
+ - description: Registers for CPAS TOP
+ - description: Registers for ICP (Imaging Control Processor) CSR (Control and Status Registers)
+ - description: Registers for ICP QGIC (Qualcomm Generic Interrupt Controller)
+ - description: Registers for ICP SIERRA ((A5 subsystem communication))
+ - description: Registers for IPE (Image Postprocessing Engine) 0
+ - description: Registers for JPEG DMA
+ - description: Registers for JPEG ENC
+ - description: Registers for LRME (Low Resolution Motion Estimation)
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid_lite
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite
+ - const: bps
+ - const: camnoc
+ - const: cpas_cdm
+ - const: cpas_top
+ - const: icp_csr
+ - const: icp_qgic
+ - const: icp_sierra
+ - const: ipe0
+ - const: jpeg_dma
+ - const: jpeg_enc
+ - const: lrme
+
+ clocks:
+ maxItems: 33
+
+ clock-names:
+ items:
+ - const: gcc_ahb
+ - const: gcc_axi_hf
+ - const: camnoc_axi
+ - const: cpas_ahb
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: soc_ahb
+ - const: vfe0
+ - const: vfe0_axi
+ - const: vfe0_cphy_rx
+ - const: vfe0_csid
+ - const: vfe1
+ - const: vfe1_axi
+ - const: vfe1_cphy_rx
+ - const: vfe1_csid
+ - const: vfe_lite
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+ - const: bps
+ - const: bps_ahb
+ - const: bps_axi
+ - const: bps_areg
+ - const: icp
+ - const: ipe0
+ - const: ipe0_ahb
+ - const: ipe0_areg
+ - const: ipe0_axi
+ - const: jpeg
+ - const: lrme
+
+ interrupts:
+ maxItems: 15
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid_lite
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite
+ - const: camnoc
+ - const: cdm
+ - const: icp
+ - const: jpeg_dma
+ - const: jpeg_enc
+ - const: lrme
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf0_mnoc
+ - const: hf1_mnoc
+ - const: sf_mnoc
+
+ iommus:
+ items:
+ - description: Camera IFE 0 non-protected stream
+ - description: Camera IFE 1 non-protected stream
+ - description: Camera IFE 3 non-protected stream
+ - description: Camera CDM non-protected stream
+ - description: Camera LRME read non-protected stream
+ - description: Camera IPE 0 read non-protected stream
+ - description: Camera BPS read non-protected stream
+ - description: Camera IPE 0 write non-protected stream
+ - description: Camera BPS write non-protected stream
+ - description: Camera LRME write non-protected stream
+ - description: Camera JPEG read non-protected stream
+ - description: Camera JPEG write non-protected stream
+ - description: Camera ICP stream
+
+ power-domains:
+ items:
+ - description:
+ IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description:
+ IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description:
+ Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
+ - description:
+ Titan BPS - Bayer Processing Segment, Global Distributed Switch Controller.
+ - description:
+ IPE GDSC - Image Postprocessing Engine, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: top
+ - const: bps
+ - const: ipe
+
+ vdd-csiphy-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSI PHYs.
+
+ vdd-csiphy-1p8-supply:
+ description:
+ Phandle to 1.8V regulator supply to CSI PHYs pll block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ patternProperties:
+ "^port@[0-2]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ description:
+ Input port for receiving CSI data from a CSIPHY.
+
+ 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/clock/qcom,qcs615-camcc.h>
+ #include <dt-bindings/clock/qcom,qcs615-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,qcs615-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss: isp@acb3000 {
+ compatible = "qcom,sm6150-camss";
+
+ reg = <0x0 0x0acb3000 0x0 0x1000>,
+ <0x0 0x0acba000 0x0 0x1000>,
+ <0x0 0x0acc8000 0x0 0x1000>,
+ <0x0 0x0ac65000 0x0 0x1000>,
+ <0x0 0x0ac66000 0x0 0x1000>,
+ <0x0 0x0ac67000 0x0 0x1000>,
+ <0x0 0x0acaf000 0x0 0x4000>,
+ <0x0 0x0acb6000 0x0 0x4000>,
+ <0x0 0x0acc4000 0x0 0x4000>,
+ <0x0 0x0ac6f000 0x0 0x3000>,
+ <0x0 0x0ac42000 0x0 0x5000>,
+ <0x0 0x0ac48000 0x0 0x1000>,
+ <0x0 0x0ac40000 0x0 0x1000>,
+ <0x0 0x0ac18000 0x0 0x3000>,
+ <0x0 0x0ac00000 0x0 0x6000>,
+ <0x0 0x0ac10000 0x0 0x8000>,
+ <0x0 0x0ac87000 0x0 0x3000>,
+ <0x0 0x0ac52000 0x0 0x4000>,
+ <0x0 0x0ac4e000 0x0 0x4000>,
+ <0x0 0x0ac6b000 0x0 0x0a00>;
+ reg-names = "csid0",
+ "csid1",
+ "csid_lite",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "vfe0",
+ "vfe1",
+ "vfe_lite",
+ "bps",
+ "camnoc",
+ "cpas_cdm",
+ "cpas_top",
+ "icp_csr",
+ "icp_qgic",
+ "icp_sierra",
+ "ipe0",
+ "jpeg_dma",
+ "jpeg_enc",
+ "lrme";
+
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_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_SOC_AHB_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_AXI_CLK>,
+ <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_0_CSID_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_1_AXI_CLK>,
+ <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_1_CSID_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
+ <&camcc CAM_CC_BPS_CLK>,
+ <&camcc CAM_CC_BPS_AHB_CLK>,
+ <&camcc CAM_CC_BPS_AXI_CLK>,
+ <&camcc CAM_CC_BPS_AREG_CLK>,
+ <&camcc CAM_CC_ICP_CLK>,
+ <&camcc CAM_CC_IPE_0_CLK>,
+ <&camcc CAM_CC_IPE_0_AHB_CLK>,
+ <&camcc CAM_CC_IPE_0_AREG_CLK>,
+ <&camcc CAM_CC_IPE_0_AXI_CLK>,
+ <&camcc CAM_CC_JPEG_CLK>,
+ <&camcc CAM_CC_LRME_CLK>;
+
+ clock-names = "gcc_ahb",
+ "gcc_axi_hf",
+ "camnoc_axi",
+ "cpas_ahb",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "soc_ahb",
+ "vfe0",
+ "vfe0_axi",
+ "vfe0_cphy_rx",
+ "vfe0_csid",
+ "vfe1",
+ "vfe1_axi",
+ "vfe1_cphy_rx",
+ "vfe1_csid",
+ "vfe_lite",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid",
+ "bps",
+ "bps_ahb",
+ "bps_axi",
+ "bps_areg",
+ "icp",
+ "ipe0",
+ "ipe0_ahb",
+ "ipe0_areg",
+ "ipe0_axi",
+ "jpeg",
+ "lrme";
+
+ 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_HF0 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_HF1 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",
+ "hf0_mnoc",
+ "hf1_mnoc",
+ "sf_mnoc";
+
+ interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 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 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 459 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 461 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 463 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 475 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 474 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 476 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid_lite",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "vfe0",
+ "vfe1",
+ "vfe_lite",
+ "camnoc",
+ "cdm",
+ "icp",
+ "jpeg_dma",
+ "jpeg_enc",
+ "lrme";
+
+ iommus = <&apps_smmu 0x0820 0x40>,
+ <&apps_smmu 0x0840 0x00>,
+ <&apps_smmu 0x0860 0x40>,
+ <&apps_smmu 0x0c00 0x00>,
+ <&apps_smmu 0x0cc0 0x00>,
+ <&apps_smmu 0x0c80 0x00>,
+ <&apps_smmu 0x0ca0 0x00>,
+ <&apps_smmu 0x0d00 0x00>,
+ <&apps_smmu 0x0d20 0x00>,
+ <&apps_smmu 0x0d40 0x00>,
+ <&apps_smmu 0x0d80 0x20>,
+ <&apps_smmu 0x0da0 0x20>,
+ <&apps_smmu 0x0de2 0x00>;
+
+ power-domains = <&camcc IFE_0_GDSC>,
+ <&camcc IFE_1_GDSC>,
+ <&camcc TITAN_TOP_GDSC>,
+ <&camcc BPS_GDSC>,
+ <&camcc IPE_0_GDSC>;
+ power-domain-names = "ife0",
+ "ife1",
+ "top",
+ "bps",
+ "ipe";
+
+ vdd-csiphy-1p2-supply = <&vreg_l11a_1p2>;
+ vdd-csiphy-1p8-supply = <&vreg_l12a_1p8>;
+
+ 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 Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: > + interconnects: > + maxItems: 4 > + > + interconnect-names: > + items: > + - const: ahb > + - const: hf0_mnoc > + - const: hf1_mnoc Same comments as before, do not invent names. I finish review here and ignore the rest. You did not respond to previous comments and I do not see any improvements. Also, way you send patches makes it difficult for us, so I see no reason why it should be my task to try to decipher all this. b4 diff '20251222-sm6150-camss-v2-1-df8469a8343a@oss.qualcomm.com' Checking for older revisions Grabbing search results from lore.kernel.org --- Analyzing 5 messages in the thread Could not find lower series to compare against. Best regards, Krzysztof
On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote: > On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: >> + interconnects: >> + maxItems: 4 >> + >> + interconnect-names: >> + items: >> + - const: ahb >> + - const: hf0_mnoc >> + - const: hf1_mnoc > > Same comments as before, do not invent names. <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, This platform(qcs615) is different from others. It has two types of sf, namely sf0 and sf1. The same as it is: sc7180 sc8180x sdm670 sdm845 sm8150 Do you have any suggestions about this? > > I finish review here and ignore the rest. You did not respond to > previous comments and I do not see any improvements. I'm sorry about this. However, the previous comments did not clearly point out the problem. > Also, way you send patches makes it difficult for us, so I see no reason > why it should be my task to try to decipher all this. > > b4 diff '20251222-sm6150-camss-v2-1-df8469a8343a@oss.qualcomm.com' > Checking for older revisions > Grabbing search results from lore.kernel.org > --- > Analyzing 5 messages in the thread > Could not find lower series to compare against. --in-reply-to, will pay attention in the next version. Thanks,Wenmeng
On 24/12/2025 04:18, Wenmeng Liu wrote: > > > On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote: >> On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: >>> + interconnects: >>> + maxItems: 4 >>> + >>> + interconnect-names: >>> + items: >>> + - const: ahb >>> + - const: hf0_mnoc >>> + - const: hf1_mnoc >> >> Same comments as before, do not invent names. > > <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, > <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, How is it relevant to the names? > > This platform(qcs615) is different from others. It has two types of sf, > namely sf0 and sf1. How is it relevant to the names? > The same as it is: > sc7180 sc8180x sdm670 sdm845 sm8150 > Do you have any suggestions about this? Open any other binding. What are the names there? > >> >> I finish review here and ignore the rest. You did not respond to >> previous comments and I do not see any improvements. > > I'm sorry about this. However, the previous comments did not clearly > point out the problem. > >> Also, way you send patches makes it difficult for us, so I see no reason >> why it should be my task to try to decipher all this. >> >> b4 diff '20251222-sm6150-camss-v2-1-df8469a8343a@oss.qualcomm.com' >> Checking for older revisions >> Grabbing search results from lore.kernel.org >> --- >> Analyzing 5 messages in the thread >> Could not find lower series to compare against. > > --in-reply-to, will pay attention in the next version. What? No. You are supposed to use properly b4, which solves all these problems. Best regards, Krzysztof
On Wed, Dec 24, 2025 at 11:18:02AM +0800, Wenmeng Liu wrote: > > > On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote: > > On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: > > > + interconnects: > > > + maxItems: 4 > > > + > > > + interconnect-names: > > > + items: > > > + - const: ahb > > > + - const: hf0_mnoc > > > + - const: hf1_mnoc > > > > Same comments as before, do not invent names. > > <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, > <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, > > This platform(qcs615) is different from others. It has two types of sf, > namely sf0 and sf1. > The same as it is: > sc7180 sc8180x sdm670 sdm845 sm8150 > Do you have any suggestions about this? Which _names_ are used on other platforms? This question is quite clear from Krzysztof's comment. > > > > > I finish review here and ignore the rest. You did not respond to > > previous comments and I do not see any improvements. > > I'm sorry about this. However, the previous comments did not clearly point > out the problem. > > > Also, way you send patches makes it difficult for us, so I see no reason > > why it should be my task to try to decipher all this. > > > > b4 diff '20251222-sm6150-camss-v2-1-df8469a8343a@oss.qualcomm.com' > > Checking for older revisions > > Grabbing search results from lore.kernel.org > > --- > > Analyzing 5 messages in the thread > > Could not find lower series to compare against. > > --in-reply-to, will pay attention in the next version. Or even better, just use b4 tool. > > Thanks,Wenmeng > -- With best wishes Dmitry
On 12/24/2025 12:21 PM, Dmitry Baryshkov wrote: > On Wed, Dec 24, 2025 at 11:18:02AM +0800, Wenmeng Liu wrote: >> >> >> On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote: >>> On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: >>>> + interconnects: >>>> + maxItems: 4 >>>> + >>>> + interconnect-names: >>>> + items: >>>> + - const: ahb >>>> + - const: hf0_mnoc >>>> + - const: hf1_mnoc >>> >>> Same comments as before, do not invent names. >> >> <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS >> &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, >> <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS >> &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, >> >> This platform(qcs615) is different from others. It has two types of sf, >> namely sf0 and sf1. >> The same as it is: >> sc7180 sc8180x sdm670 sdm845 sm8150 >> Do you have any suggestions about this? > > Which _names_ are used on other platforms? This question is quite clear > from Krzysztof's comment. The platform mentioned above either has no camss ICC node or no support for CAMSS on the upstream, so this is a new one. Thanks, Wenmeng
On Wed, Dec 24, 2025 at 12:31:33PM +0800, Wenmeng Liu wrote: > > > On 12/24/2025 12:21 PM, Dmitry Baryshkov wrote: > > On Wed, Dec 24, 2025 at 11:18:02AM +0800, Wenmeng Liu wrote: > > > > > > > > > On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote: > > > > On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: > > > > > + interconnects: > > > > > + maxItems: 4 > > > > > + > > > > > + interconnect-names: > > > > > + items: > > > > > + - const: ahb > > > > > + - const: hf0_mnoc > > > > > + - const: hf1_mnoc > > > > > > > > Same comments as before, do not invent names. > > > > > > <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS > > > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, > > > <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS > > > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, > > > > > > This platform(qcs615) is different from others. It has two types of sf, > > > namely sf0 and sf1. > > > The same as it is: > > > sc7180 sc8180x sdm670 sdm845 sm8150 > > > Do you have any suggestions about this? > > > > Which _names_ are used on other platforms? This question is quite clear > > from Krzysztof's comment. > > The platform mentioned above either has no camss ICC node or no support for > CAMSS on the upstream, so this is a new one. I did a quick look for you. kodiak, lemans, monaco: ahb, hf_0 x1e80100: ahb, hf_mnoc, sf_mnoc, sf_icp_mnoc sm8650: ahb, hf_mnoc agatti: ahb, hf_mnoc, sf_mnoc sm8550: ahb, hf_0_mnoc sc8280xp: cam_ahb, cam_hf_mnoc, cam_sf_mnoc, cam_sf_icp_mnoc sm8250: cam_ahb, cam_hf_0_mnoc, cam_sf_0_mnoc, cam_sf_icp_mnoc sdm660: vfe-mem I'd obviously hope for some unification here. Other than that, we have two clean winners: KLM and X Elite+SM8650+Agatti. Yours proposal is different from either of the options. In fact, none of the platforms have the same _approach_ as yours. Why? -- With best wishes Dmitry
On 12/24/2025 1:03 PM, Dmitry Baryshkov wrote: > On Wed, Dec 24, 2025 at 12:31:33PM +0800, Wenmeng Liu wrote: >> >> >> On 12/24/2025 12:21 PM, Dmitry Baryshkov wrote: >>> On Wed, Dec 24, 2025 at 11:18:02AM +0800, Wenmeng Liu wrote: >>>> >>>> >>>> On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote: >>>>> On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: >>>>>> + interconnects: >>>>>> + maxItems: 4 >>>>>> + >>>>>> + interconnect-names: >>>>>> + items: >>>>>> + - const: ahb >>>>>> + - const: hf0_mnoc >>>>>> + - const: hf1_mnoc >>>>> >>>>> Same comments as before, do not invent names. >>>> >>>> <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS >>>> &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, >>>> <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS >>>> &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, >>>> >>>> This platform(qcs615) is different from others. It has two types of sf, >>>> namely sf0 and sf1. >>>> The same as it is: >>>> sc7180 sc8180x sdm670 sdm845 sm8150 >>>> Do you have any suggestions about this? >>> >>> Which _names_ are used on other platforms? This question is quite clear >>> from Krzysztof's comment. >> >> The platform mentioned above either has no camss ICC node or no support for >> CAMSS on the upstream, so this is a new one. > > I did a quick look for you. > > kodiak, lemans, monaco: ahb, hf_0 > > x1e80100: ahb, hf_mnoc, sf_mnoc, sf_icp_mnoc > sm8650: ahb, hf_mnoc > agatti: ahb, hf_mnoc, sf_mnoc > sm8550: ahb, hf_0_mnoc > > sc8280xp: cam_ahb, cam_hf_mnoc, cam_sf_mnoc, cam_sf_icp_mnoc > sm8250: cam_ahb, cam_hf_0_mnoc, cam_sf_0_mnoc, cam_sf_icp_mnoc > sdm660: vfe-mem > > I'd obviously hope for some unification here. Other than that, we have > two clean winners: KLM and X Elite+SM8650+Agatti. Yours proposal is > different from either of the options. In fact, none of the platforms > have the same _approach_ as yours. Why? > Yes, you're right. But none of the above cases involved having two hf_mnoc simultaneously, so do you have any good suggestions for handling such a situation? Thanks, Wenmeng
On 24/12/2025 06:36, Wenmeng Liu wrote: > > > On 12/24/2025 1:03 PM, Dmitry Baryshkov wrote: >> On Wed, Dec 24, 2025 at 12:31:33PM +0800, Wenmeng Liu wrote: >>> >>> >>> On 12/24/2025 12:21 PM, Dmitry Baryshkov wrote: >>>> On Wed, Dec 24, 2025 at 11:18:02AM +0800, Wenmeng Liu wrote: >>>>> >>>>> >>>>> On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote: >>>>>> On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: >>>>>>> + interconnects: >>>>>>> + maxItems: 4 >>>>>>> + >>>>>>> + interconnect-names: >>>>>>> + items: >>>>>>> + - const: ahb >>>>>>> + - const: hf0_mnoc >>>>>>> + - const: hf1_mnoc >>>>>> >>>>>> Same comments as before, do not invent names. >>>>> >>>>> <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS >>>>> &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, >>>>> <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS >>>>> &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, >>>>> >>>>> This platform(qcs615) is different from others. It has two types of sf, >>>>> namely sf0 and sf1. >>>>> The same as it is: >>>>> sc7180 sc8180x sdm670 sdm845 sm8150 >>>>> Do you have any suggestions about this? >>>> >>>> Which _names_ are used on other platforms? This question is quite clear >>>> from Krzysztof's comment. >>> >>> The platform mentioned above either has no camss ICC node or no support for >>> CAMSS on the upstream, so this is a new one. >> >> I did a quick look for you. >> >> kodiak, lemans, monaco: ahb, hf_0 >> >> x1e80100: ahb, hf_mnoc, sf_mnoc, sf_icp_mnoc >> sm8650: ahb, hf_mnoc >> agatti: ahb, hf_mnoc, sf_mnoc >> sm8550: ahb, hf_0_mnoc >> >> sc8280xp: cam_ahb, cam_hf_mnoc, cam_sf_mnoc, cam_sf_icp_mnoc >> sm8250: cam_ahb, cam_hf_0_mnoc, cam_sf_0_mnoc, cam_sf_icp_mnoc >> sdm660: vfe-mem >> >> I'd obviously hope for some unification here. Other than that, we have >> two clean winners: KLM and X Elite+SM8650+Agatti. Yours proposal is >> different from either of the options. In fact, none of the platforms >> have the same _approach_ as yours. Why? >> > > Yes, you're right. > But none of the above cases involved having two hf_mnoc simultaneously, > so do you have any good suggestions for handling such a situation? And this is your answer to use completely different style? This makes no sense. This is your logic: 1. If there is one HF, I will add underscore. 2. If there is more than one HF, I will remove underscore. This makes absolutely NO SENSE. Best regards, Krzysztof
On 12/24/2025 5:46 PM, Krzysztof Kozlowski wrote: > On 24/12/2025 06:36, Wenmeng Liu wrote: >> >> >> On 12/24/2025 1:03 PM, Dmitry Baryshkov wrote: >>> On Wed, Dec 24, 2025 at 12:31:33PM +0800, Wenmeng Liu wrote: >>>> >>>> >>>> On 12/24/2025 12:21 PM, Dmitry Baryshkov wrote: >>>>> On Wed, Dec 24, 2025 at 11:18:02AM +0800, Wenmeng Liu wrote: >>>>>> >>>>>> >>>>>> On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote: >>>>>>> On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: >>>>>>>> + interconnects: >>>>>>>> + maxItems: 4 >>>>>>>> + >>>>>>>> + interconnect-names: >>>>>>>> + items: >>>>>>>> + - const: ahb >>>>>>>> + - const: hf0_mnoc >>>>>>>> + - const: hf1_mnoc >>>>>>> >>>>>>> Same comments as before, do not invent names. >>>>>> >>>>>> <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS >>>>>> &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, >>>>>> <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS >>>>>> &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, >>>>>> >>>>>> This platform(qcs615) is different from others. It has two types of sf, >>>>>> namely sf0 and sf1. >>>>>> The same as it is: >>>>>> sc7180 sc8180x sdm670 sdm845 sm8150 >>>>>> Do you have any suggestions about this? >>>>> >>>>> Which _names_ are used on other platforms? This question is quite clear >>>>> from Krzysztof's comment. >>>> >>>> The platform mentioned above either has no camss ICC node or no support for >>>> CAMSS on the upstream, so this is a new one. >>> >>> I did a quick look for you. >>> >>> kodiak, lemans, monaco: ahb, hf_0 >>> >>> x1e80100: ahb, hf_mnoc, sf_mnoc, sf_icp_mnoc >>> sm8650: ahb, hf_mnoc >>> agatti: ahb, hf_mnoc, sf_mnoc >>> sm8550: ahb, hf_0_mnoc >>> >>> sc8280xp: cam_ahb, cam_hf_mnoc, cam_sf_mnoc, cam_sf_icp_mnoc >>> sm8250: cam_ahb, cam_hf_0_mnoc, cam_sf_0_mnoc, cam_sf_icp_mnoc >>> sdm660: vfe-mem >>> >>> I'd obviously hope for some unification here. Other than that, we have >>> two clean winners: KLM and X Elite+SM8650+Agatti. Yours proposal is >>> different from either of the options. In fact, none of the platforms >>> have the same _approach_ as yours. Why? >>> >> >> Yes, you're right. >> But none of the above cases involved having two hf_mnoc simultaneously, >> so do you have any good suggestions for handling such a situation? > > And this is your answer to use completely different style? This makes no > sense. > > This is your logic: > 1. If there is one HF, I will add underscore. > 2. If there is more than one HF, I will remove underscore. > > This makes absolutely NO SENSE. > Would it make sense to use hf_0_mnoc and hf_1_mnoc to differentiate the two paths? Thanks, Wenmeng
On Wed, Dec 24, 2025 at 06:29:43PM +0800, Wenmeng Liu wrote: > > > On 12/24/2025 5:46 PM, Krzysztof Kozlowski wrote: > > On 24/12/2025 06:36, Wenmeng Liu wrote: > > > > > > > > > On 12/24/2025 1:03 PM, Dmitry Baryshkov wrote: > > > > On Wed, Dec 24, 2025 at 12:31:33PM +0800, Wenmeng Liu wrote: > > > > > > > > > > > > > > > On 12/24/2025 12:21 PM, Dmitry Baryshkov wrote: > > > > > > On Wed, Dec 24, 2025 at 11:18:02AM +0800, Wenmeng Liu wrote: > > > > > > > > > > > > > > > > > > > > > On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote: > > > > > > > > On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: > > > > > > > > > + interconnects: > > > > > > > > > + maxItems: 4 > > > > > > > > > + > > > > > > > > > + interconnect-names: > > > > > > > > > + items: > > > > > > > > > + - const: ahb > > > > > > > > > + - const: hf0_mnoc > > > > > > > > > + - const: hf1_mnoc > > > > > > > > > > > > > > > > Same comments as before, do not invent names. > > > > > > > > > > > > > > <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS > > > > > > > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, > > > > > > > <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS > > > > > > > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, > > > > > > > > > > > > > > This platform(qcs615) is different from others. It has two types of sf, > > > > > > > namely sf0 and sf1. > > > > > > > The same as it is: > > > > > > > sc7180 sc8180x sdm670 sdm845 sm8150 > > > > > > > Do you have any suggestions about this? > > > > > > > > > > > > Which _names_ are used on other platforms? This question is quite clear > > > > > > from Krzysztof's comment. > > > > > > > > > > The platform mentioned above either has no camss ICC node or no support for > > > > > CAMSS on the upstream, so this is a new one. > > > > > > > > I did a quick look for you. > > > > > > > > kodiak, lemans, monaco: ahb, hf_0 > > > > > > > > x1e80100: ahb, hf_mnoc, sf_mnoc, sf_icp_mnoc > > > > sm8650: ahb, hf_mnoc > > > > agatti: ahb, hf_mnoc, sf_mnoc > > > > sm8550: ahb, hf_0_mnoc > > > > > > > > sc8280xp: cam_ahb, cam_hf_mnoc, cam_sf_mnoc, cam_sf_icp_mnoc > > > > sm8250: cam_ahb, cam_hf_0_mnoc, cam_sf_0_mnoc, cam_sf_icp_mnoc > > > > sdm660: vfe-mem > > > > > > > > I'd obviously hope for some unification here. Other than that, we have > > > > two clean winners: KLM and X Elite+SM8650+Agatti. Yours proposal is > > > > different from either of the options. In fact, none of the platforms > > > > have the same _approach_ as yours. Why? > > > > > > > > > > Yes, you're right. > > > But none of the above cases involved having two hf_mnoc simultaneously, > > > so do you have any good suggestions for handling such a situation? > > > > And this is your answer to use completely different style? This makes no > > sense. > > > > This is your logic: > > 1. If there is one HF, I will add underscore. > > 2. If there is more than one HF, I will remove underscore. > > > > This makes absolutely NO SENSE. > > > > Would it make sense to use hf_0_mnoc and hf_1_mnoc to differentiate the two > paths? Or just hf_0 / hf_1. -- With best wishes Dmitry
On Wed, Dec 24, 2025 at 01:36:26PM +0800, Wenmeng Liu wrote: > > > On 12/24/2025 1:03 PM, Dmitry Baryshkov wrote: > > On Wed, Dec 24, 2025 at 12:31:33PM +0800, Wenmeng Liu wrote: > > > > > > > > > On 12/24/2025 12:21 PM, Dmitry Baryshkov wrote: > > > > On Wed, Dec 24, 2025 at 11:18:02AM +0800, Wenmeng Liu wrote: > > > > > > > > > > > > > > > On 12/23/2025 9:38 PM, Krzysztof Kozlowski wrote: > > > > > > On Mon, Dec 22, 2025 at 04:28:39PM +0800, Wenmeng Liu wrote: > > > > > > > + interconnects: > > > > > > > + maxItems: 4 > > > > > > > + > > > > > > > + interconnect-names: > > > > > > > + items: > > > > > > > + - const: ahb > > > > > > > + - const: hf0_mnoc > > > > > > > + - const: hf1_mnoc > > > > > > > > > > > > Same comments as before, do not invent names. > > > > > > > > > > <&mmss_noc MASTER_CAMNOC_HF0 QCOM_ICC_TAG_ALWAYS > > > > > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, > > > > > <&mmss_noc MASTER_CAMNOC_HF1 QCOM_ICC_TAG_ALWAYS > > > > > &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, > > > > > > > > > > This platform(qcs615) is different from others. It has two types of sf, > > > > > namely sf0 and sf1. > > > > > The same as it is: > > > > > sc7180 sc8180x sdm670 sdm845 sm8150 > > > > > Do you have any suggestions about this? > > > > > > > > Which _names_ are used on other platforms? This question is quite clear > > > > from Krzysztof's comment. > > > > > > The platform mentioned above either has no camss ICC node or no support for > > > CAMSS on the upstream, so this is a new one. > > > > I did a quick look for you. > > > > kodiak, lemans, monaco: ahb, hf_0 > > > > x1e80100: ahb, hf_mnoc, sf_mnoc, sf_icp_mnoc > > sm8650: ahb, hf_mnoc > > agatti: ahb, hf_mnoc, sf_mnoc > > sm8550: ahb, hf_0_mnoc > > > > sc8280xp: cam_ahb, cam_hf_mnoc, cam_sf_mnoc, cam_sf_icp_mnoc > > sm8250: cam_ahb, cam_hf_0_mnoc, cam_sf_0_mnoc, cam_sf_icp_mnoc > > sdm660: vfe-mem > > > > I'd obviously hope for some unification here. Other than that, we have > > two clean winners: KLM and X Elite+SM8650+Agatti. Yours proposal is > > different from either of the options. In fact, none of the platforms > > have the same _approach_ as yours. Why? > > > > Yes, you're right. > But none of the above cases involved having two hf_mnoc simultaneously, so > do you have any good suggestions for handling such a situation? I'd suggest hf_0 / hf_1, or hf_0_mnoc / hf_1_mnoc. I'd ask Krzysztof comment on which of those two options is a better one. -- With best wishes Dmitry
© 2016 - 2026 Red Hat, Inc.