devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v10 0/4] arm64: dts: qcom: aim300: add AIM300 AIoT
@ 2024-06-18  7:21 Tengfei Fan
  2024-06-18  7:21 ` [PATCH v10 1/4] dt-bindings: arm: qcom: Document QCS8550 SoC and the AIM300 AIoT board Tengfei Fan
                   ` (4 more replies)
  0 siblings, 5 replies; 16+ messages in thread
From: Tengfei Fan @ 2024-06-18  7:21 UTC (permalink / raw)
  To: andersson, konrad.dybcio, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Tengfei Fan

Add AIM300 AIoT support along with usb, ufs, regulators, serial, PCIe,
and PMIC functions.
AIM300 Series is a highly optimized family of modules designed to
support AIoT applications. It integrates QCS8550 SoC, UFS and PMIC
chip etc.
Here is a diagram of AIM300 AIoT Carrie Board and SoM
 +--------------------------------------------------+
 |             AIM300 AIOT Carrier Board            |
 |                                                  |
 |           +-----------------+                    |
 |power----->| Fixed regulator |---------+          |
 |           +-----------------+         |          |
 |                                       |          |
 |                                       v VPH_PWR  |
 | +----------------------------------------------+ |
 | |                          AIM300 SOM |        | |
 | |                                     |VPH_PWR | |
 | |                                     v        | |
 | |   +-------+       +--------+     +------+    | |
 | |   | UFS   |       | QCS8550|     |PMIC  |    | |
 | |   +-------+       +--------+     +------+    | |
 | |                                              | |
 | +----------------------------------------------+ |
 |                                                  |
 |                    +----+          +------+      |
 |                    |USB |          | UART |      |
 |                    +----+          +------+      |
 +--------------------------------------------------+
The following functions have been verified:
  - uart
  - usb
  - ufs
  - PCIe
  - PMIC
  - display
  - adsp
  - cdsp
  - tlmm

Documentation for qcs8550[1] and sm8550[2]
[1] https://docs.qualcomm.com/bundle/publicresource/87-61717-1_REV_A_Qualcomm_QCS8550_QCM8550_Processors_Product_Brief.pdf
[2] https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/Snapdragon-8-Gen-2-Product-Brief.pdf

Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
---

v9 -> v10:
  - update the patch commit message and some code comments
  - use *_dtbs.mbn instead of *_dtbs.elf
  - use "te-default-state" instead of "te-active-state" and
    "te-suspend-state"
v8 -> v9:
  - Update the patch commit message and some code comments
v7 -> v8:
  - rebase patch series on top of:
    https://lore.kernel.org/linux-arm-msm/20240502-topic-sm8x50-upstream-pcie-1-phy-aux-clk-v5-0-10c650cfeade@linaro.org/
  - add pinctrl configurations for pcie0 and pcie1 in AIM300 SOM dtsi
  - move some common usb node settings to SoC dtsi
  - verified with dtb check, and result is expected, because those
    warnings are not introduced by current patch series.
    arch/arm64/boot/dts/qcom/sm8550.dtsi:3037.27-3092.6: Warning
    (avoid_unnecessary_addr_size): /soc@0/display-subsystem@ae00000/dsi@ae96000: unnecessary
    #address-cells/#size-cells without "ranges" or child "reg" property
v6 -> v7:
  - correct typos in the commit message
  - move mdss_dsi0, mdss_dsi0_phy, pcie0_phy, pcie1_phy and usb_dp_qmpphy
    vdda supply to qcs8550-aim300.dtsi
  - move the perst and wake gpio settings of pcie0 and pcie1 to
    qcs8550-aim300.dtsi
  - move the clock frequency settings of pcie_1_phy_aux_clk, sleep_clk
    and xo_board to qcs8550-aim300.dtsi
  - verified with dtb check, and result is expected, because those
    warnings are not introduced by current patch series.
    arch/arm64/boot/dts/qcom/sm8550.dtsi:3037.27-3092.6: Warning
    (avoid_unnecessary_addr_size): /soc@0/display-subsystem@ae00000/dsi@ae96000: unnecessary
    #address-cells/#size-cells without "ranges" or child "reg" property
    arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb:
    phy@1c0e000: clock-output-names: ['pcie1_pipe_clk'] is too short
        from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml#
    arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb: phy@1c0e000: #clock-cells:0:0: 1 was expected
        from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml#
v5 -> v6:
  - move qcs8550 board info bebind sm8550 boards info in qcom.yaml
v4 -> v5:
  - "2023-2024" instead of "2023~2024" for License
  - update patch commit message to previous comments and with an updated
    board diagram
  - use qcs8550.dtsi instead of qcm8550.dtsi
  - remove the reserved memory regions which will be handled by
    bootloader
  - remove pm8550_flash, pm8550_pwm nodes, Type-C USB/DP function node,
    remoteproc_mpss function node, audio sound DTS node, new patch will
    be updated after respective team's end to end full verification
  - address comments to vph_pwr, move vph_pwr node and related
    references to qcs8550-aim300-aiot.dts
  - use "regulator-vph-pwr" instead of "vph_pwr_regulator"
  - add pcie0I AND pcie1 support together
  - the following patches were applied, so remove these patches from new
    patch series:
      - https://lore.kernel.org/linux-arm-msm/20240119100621.11788-3-quic_tengfan@quicinc.com
      - https://lore.kernel.org/linux-arm-msm/20240119100621.11788-4-quic_tengfan@quicinc.com
  - verified with dtb check, and result is expected, because those
    warnings are not introduced by current patch series.
    DTC_CHK arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb
    arch/arm64/boot/dts/qcom/sm8550.dtsi:3015.27-3070.6: Warning
    (avoid_unnecessary_addr_size): /soc@0/display-subsystem@ae00000/dsi@ae96000: unnecessary
    #address-cells/#size-cells without "ranges" or child "reg" property
    arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb:
    opp-table: opp-75000000:opp-hz:0: [75000000, 0, 0, 75000000, 0, 0, 0, 0] is too long
        from schema $id: http://devicetree.org/schemas/opp/opp-v2.yaml#
    arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb:
    opp-table: opp-150000000:opp-hz:0: [150000000, 0, 0, 150000000, 0, 0, 0, 0] is too long
        from schema $id: http://devicetree.org/schemas/opp/opp-v2.yaml#
    arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb:
    opp-table: opp-300000000:opp-hz:0: [300000000, 0, 0, 300000000, 0, 0, 0, 0] is too long
        from schema $id: http://devicetree.org/schemas/opp/opp-v2.yaml#
    arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb:
    opp-table: Unevaluated properties are not allowed ('opp-150000000', 'opp-300000000', 'opp-75000000' were unexpected)
        from schema $id: http://devicetree.org/schemas/opp/opp-v2.yaml#
v3 -> v4:
  - use qcm8550.dtsi instead of qcs8550.dtsi, qcs8550 is a QCS version
    of qcm8550, another board with qcm8550 will be added later
  - add AIM300 AIoT board string in qcom.yaml file
  - add sm8550 and qcm8550 fallback compatible
  - add qcm8550 SoC id
  - add reserved memory map codes in qcm8550.dtsi
  - pm8010 and pmr73d are splited into carrier board DTS file. Because
    the regulators which in pm8550, pm8550ve and pm8550vs are present
    on the SoM. The regulators which in pm8010 and pmr73d are present
    on the carrier board.
  - stay VPH_PWR at qcs8550-aim300.dtsi file
      VPH_PWR is obtained by vonverting 12v voltage into 3.7 voltage
      with a 3.7v buck. VPH_PWR is power supply for regulators in AIM300
      SOM. VPH_PWR regulator is defined in AIM300 SOM dtsi file.
v2 -> v3:
  - introduce qcs8550.dtsi
  - separate fix dtc W=1 warning patch to another patch series
v1 -> v2:
  - merge the splited dts patches into one patch
  - update dts file name from qcom8550-aim300.dts to qcs8550-aim300 dts
  - drop PCIe1 dts node due to it is not enabled
  - update display node name for drop sde characters

previous discussion here:
[1] v9: https://lore.kernel.org/linux-arm-msm/20240529100926.3166325-1-quic_tengfan@quicinc.com
[2] v8: https://lore.kernel.org/linux-arm-msm/20240513090735.1666142-1-quic_tengfan@quicinc.com
[3] v7: https://lore.kernel.org/linux-arm-msm/20240424024508.3857602-1-quic_tengfan@quicinc.com
[4] v6 RESEND: https://lore.kernel.org/linux-arm-msm/20240401093843.2591147-1-quic_tengfan@quicinc.com
[5] v6: https://lore.kernel.org/linux-arm-msm/20240308070432.28195-1-quic_tengfan@quicinc.com
[6] v5: https://lore.kernel.org/linux-arm-msm/20240301134113.14423-1-quic_tengfan@quicinc.com
[7] v4: https://lore.kernel.org/linux-arm-msm/20240119100621.11788-1-quic_tengfan@quicinc.com
[8] v3: https://lore.kernel.org/linux-arm-msm/20231219005007.11644-1-quic_tengfan@quicinc.com
[9] v2: https://lore.kernel.org/linux-arm-msm/20231207092801.7506-1-quic_tengfan@quicinc.com
[10] v1: https://lore.kernel.org/linux-arm-msm/20231117101817.4401-1-quic_tengfan@quicinc.com

Tengfei Fan (4):
  dt-bindings: arm: qcom: Document QCS8550 SoC and the AIM300 AIoT board
  arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi
  arm64: dts: qcom: add base AIM300 dtsi
  arm64: dts: qcom: aim300: add AIM300 AIoT

 .../devicetree/bindings/arm/qcom.yaml         |   8 +
 arch/arm64/boot/dts/qcom/Makefile             |   1 +
 .../boot/dts/qcom/qcs8550-aim300-aiot.dts     | 315 ++++++++++++++
 arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi  | 405 ++++++++++++++++++
 arch/arm64/boot/dts/qcom/qcs8550.dtsi         | 162 +++++++
 5 files changed, 891 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
 create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/qcs8550.dtsi


base-commit: 76db4c64526c5e8ba0f56ad3d890dce8f9b00bbc
-- 
2.25.1


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH v10 1/4] dt-bindings: arm: qcom: Document QCS8550 SoC and the AIM300 AIoT board
  2024-06-18  7:21 [PATCH v10 0/4] arm64: dts: qcom: aim300: add AIM300 AIoT Tengfei Fan
@ 2024-06-18  7:21 ` Tengfei Fan
  2024-06-18  7:22 ` [PATCH v10 2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi Tengfei Fan
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 16+ messages in thread
From: Tengfei Fan @ 2024-06-18  7:21 UTC (permalink / raw)
  To: andersson, konrad.dybcio, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Tengfei Fan,
	Krzysztof Kozlowski

Document QCS8550 SoC and the AIM300 AIoT board bindings.
QCS8550 is derived from SM8550. The difference between SM8550 and
QCS8550 is QCS8550 doesn't have modem RF system. QCS8550 is mainly used
in IoT scenarios.
AIM300 Series is a highly optimized family of modules designed to
support AIoT applications. It integrates QCS8550 SoC, UFS and PMIC chip
etc.
AIM stands for Artificial Intelligence Module. AIoT stands for AI IoT.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 1be21a16ba36..d839691a900c 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -42,6 +42,7 @@ description: |
         msm8996
         msm8998
         qcs404
+        qcs8550
         qcm2290
         qcm6490
         qdu1000
@@ -1018,6 +1019,13 @@ properties:
               - sony,pdx234
           - const: qcom,sm8550
 
+      - items:
+          - enum:
+              - qcom,qcs8550-aim300-aiot
+          - const: qcom,qcs8550-aim300
+          - const: qcom,qcs8550
+          - const: qcom,sm8550
+
       - items:
           - enum:
               - qcom,sm8650-hdk
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v10 2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi
  2024-06-18  7:21 [PATCH v10 0/4] arm64: dts: qcom: aim300: add AIM300 AIoT Tengfei Fan
  2024-06-18  7:21 ` [PATCH v10 1/4] dt-bindings: arm: qcom: Document QCS8550 SoC and the AIM300 AIoT board Tengfei Fan
@ 2024-06-18  7:22 ` Tengfei Fan
  2024-06-18 10:06   ` Caleb Connolly
  2024-06-18  7:22 ` [PATCH v10 3/4] arm64: dts: qcom: add base AIM300 dtsi Tengfei Fan
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 16+ messages in thread
From: Tengfei Fan @ 2024-06-18  7:22 UTC (permalink / raw)
  To: andersson, konrad.dybcio, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Tengfei Fan

QCS8550 is derived from SM8550. The difference between SM8550 and
QCS8550 is QCS8550 doesn't have modem RF system. QCS8550 is mainly used
in IoT products.
QCS8550 firmware has different memory map compared to SM8550.
The memory map will be runtime added through bootloader.
There are 3 types of reserved memory regions here:
1. Firmware related regions which aren't shared with kernel.
    The device tree source in kernel doesn't need to have node to indicate
the firmware related reserved information. Bootloader converys the
information by updating devicetree at runtime.
    This will be described as: UEFI saves the physical address of the
UEFI System Table to dts file's chosen node. Kernel read this table and
add reserved memory regions to efi config table. Current reserved memory
region may have reserved region which was not yet used, release note of
the firmware have such kind of information.
2. Firmware related memory regions which are shared with Kernel
    The device tree source in the kernel needs to include nodes that
indicate fimware-related shared information. A label name is suggested
because this type of shared information needs to be referenced by
specific drivers for handling purposes.
    Unlike previous platforms, QCS8550 boots using EFI and describes
most reserved regions in the ESRT memory map. As a result, reserved
memory regions which aren't relevant to the kernel(like the hypervisor
region) don't need to be described in DT.
3. Remoteproc regions.
    Remoteproc regions will be reserved and then assigned to subsystem
firmware later.
Here is a reserved memory map for this platform:
 0x80000000 +-------------------+
            |                   |
            | Firmware Related  |
            |                   |
 0x8a800000 +-------------------+
            |                   |
            | Remoteproc Region |
            |                   |
 0xa7000000 +-------------------+
            |                   |
            | Kernel Available  |
            |                   |
 0xd4d00000 +-------------------+
            |                   |
            | Firmware Related  |
            |                   |
0x100000000 +-------------------+

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
---
 arch/arm64/boot/dts/qcom/qcs8550.dtsi | 162 ++++++++++++++++++++++++++
 1 file changed, 162 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/qcs8550.dtsi

diff --git a/arch/arm64/boot/dts/qcom/qcs8550.dtsi b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
new file mode 100644
index 000000000000..07b314834d88
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
@@ -0,0 +1,162 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include "sm8550.dtsi"
+
+/delete-node/ &reserved_memory;
+
+/ {
+	reserved_memory: reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+
+		/* These are 3 types of reserved memory regions here:
+		 * 1. Firmware related regions which aren't shared with kernel.
+		 *     The device tree source in kernel doesn't need to have node to
+		 * indicate the firmware related reserved information. Bootloader
+		 * conveys the information by updating devicetree at runtime.
+		 *     This will be described as: UEFI saves the physical address of
+		 * the UEFI System Table to dts file's chosen node. Kernel read this
+		 * table and add reserved memory regions to efi config table. Current
+		 * reserved memory region may have reserved region which was not yet
+		 * used, release note of the firmware have such kind of information.
+		 * 2. Firmware related memory regions which are shared with Kernel
+		 *     The device tree source in the kernel needs to include nodes
+		 * that indicate fimware-related shared information. A label name
+		 * is suggested because this type of shared information needs to
+		 * be referenced by specific drivers for handling purposes.
+		 *     Unlike previous platforms, QCS8550 boots using EFI and describes
+		 * most reserved regions in the ESRT memory map. As a result, reserved
+		 * memory regions which aren't relevant to the kernel(like the hypervisor
+		 ( region) don't need to be described in DT.
+		 * 3. Remoteproc regions.
+		 *     Remoteproc regions will be reserved and then assigned to
+		 * subsystem firmware later.
+		 * Here is a reserved memory map for this platform:
+		 *  0x80000000 +-------------------+
+		 *             |                   |
+		 *             | Firmware Related  |
+		 *             |                   |
+		 *  0x8a800000 +-------------------+
+		 *             |                   |
+		 *             | Remoteproc Region |
+		 *             |                   |
+		 *  0xa7000000 +-------------------+
+		 *             |                   |
+		 *             | Kernel Available  |
+		 *             |                   |
+		 *  0xd4d00000 +-------------------+
+		 *             |                   |
+		 *             | Firmware Related  |
+		 *             |                   |
+		 * 0x100000000 +-------------------+
+		 */
+
+		aop_image_mem: aop-image-region@81c00000 {
+			reg = <0x0 0x81c00000 0x0 0x60000>;
+			no-map;
+		};
+
+		aop_cmd_db_mem: aop-cmd-db-region@81c60000 {
+			compatible = "qcom,cmd-db";
+			reg = <0x0 0x81c60000 0x0 0x20000>;
+			no-map;
+		};
+
+		aop_config_mem: aop-config-region@81c80000 {
+			no-map;
+			reg = <0x0 0x81c80000 0x0 0x20000>;
+		};
+
+		smem_mem: smem-region@81d00000 {
+			compatible = "qcom,smem";
+			reg = <0x0 0x81d00000 0x0 0x200000>;
+			hwlocks = <&tcsr_mutex 3>;
+			no-map;
+		};
+
+		adsp_mhi_mem: adsp-mhi-region@81f00000 {
+			reg = <0x0 0x81f00000 0x0 0x20000>;
+			no-map;
+		};
+
+		mpss_mem: mpss-region@8a800000 {
+			reg = <0x0 0x8a800000 0x0 0x10800000>;
+			no-map;
+		};
+
+		q6_mpss_dtb_mem: q6-mpss-dtb-region@9b000000 {
+			reg = <0x0 0x9b000000 0x0 0x80000>;
+			no-map;
+		};
+
+		ipa_fw_mem: ipa-fw-region@9b080000 {
+			reg = <0x0 0x9b080000 0x0 0x10000>;
+			no-map;
+		};
+
+		ipa_gsi_mem: ipa-gsi-region@9b090000 {
+			reg = <0x0 0x9b090000 0x0 0xa000>;
+			no-map;
+		};
+
+		gpu_micro_code_mem: gpu-micro-code-region@9b09a000 {
+			reg = <0x0 0x9b09a000 0x0 0x2000>;
+			no-map;
+		};
+
+		spss_region_mem: spss-region@9b100000 {
+			reg = <0x0 0x9b100000 0x0 0x180000>;
+			no-map;
+		};
+
+		spu_secure_shared_memory_mem: spu-secure-shared-memory-region@9b280000 {
+			reg = <0x0 0x9b280000 0x0 0x80000>;
+			no-map;
+		};
+
+		camera_mem: camera-region@9b300000 {
+			reg = <0x0 0x9b300000 0x0 0x800000>;
+			no-map;
+		};
+
+		video_mem: video-region@9bb00000 {
+			reg = <0x0 0x9bb00000 0x0 0x700000>;
+			no-map;
+		};
+
+		cvp_mem: cvp-region@9c200000 {
+			reg = <0x0 0x9c200000 0x0 0x700000>;
+			no-map;
+		};
+
+		cdsp_mem: cdsp-region@9c900000 {
+			reg = <0x0 0x9c900000 0x0 0x2000000>;
+			no-map;
+		};
+
+		q6_cdsp_dtb_mem: q6-cdsp-dtb-region@9e900000 {
+			reg = <0x0 0x9e900000 0x0 0x80000>;
+			no-map;
+		};
+
+		q6_adsp_dtb_mem: q6-adsp-dtb-region@9e980000 {
+			reg = <0x0 0x9e980000 0x0 0x80000>;
+			no-map;
+		};
+
+		adspslpi_mem: adspslpi-region@9ea00000 {
+			reg = <0x0 0x9ea00000 0x0 0x4080000>;
+			no-map;
+		};
+
+		mpss_dsm_mem: mpss_dsm_region@d4d00000 {
+			reg = <0x0 0xd4d00000 0x0 0x3300000>;
+			no-map;
+		};
+	};
+};
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v10 3/4] arm64: dts: qcom: add base AIM300 dtsi
  2024-06-18  7:21 [PATCH v10 0/4] arm64: dts: qcom: aim300: add AIM300 AIoT Tengfei Fan
  2024-06-18  7:21 ` [PATCH v10 1/4] dt-bindings: arm: qcom: Document QCS8550 SoC and the AIM300 AIoT board Tengfei Fan
  2024-06-18  7:22 ` [PATCH v10 2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi Tengfei Fan
@ 2024-06-18  7:22 ` Tengfei Fan
  2024-06-18 19:06   ` Konrad Dybcio
  2024-06-18  7:22 ` [PATCH v10 4/4] arm64: dts: qcom: aim300: add AIM300 AIoT Tengfei Fan
  2024-06-21  6:11 ` [PATCH v10 0/4] " Bjorn Andersson
  4 siblings, 1 reply; 16+ messages in thread
From: Tengfei Fan @ 2024-06-18  7:22 UTC (permalink / raw)
  To: andersson, konrad.dybcio, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Tengfei Fan,
	Fenglin Wu

AIM300 Series is a highly optimized family of modules designed to
support AIoT applications. It integrates QCS8550 SoC, UFS and PMIC
chip etc.
Here is a diagram of AIM300 SoM:
          +----------------------------------------+
          |AIM300 SoM                              |
          |                                        |
          |                           +-----+      |
          |                      |--->| UFS |      |
          |                      |    +-----+      |
          |                      |                 |
          |                      |                 |
     3.7v |  +-----------------+ |    +---------+  |
  ---------->|       PMIC      |----->| QCS8550 |  |
          |  +-----------------+      +---------+  |
          |                      |                 |
          |                      |                 |
          |                      |    +-----+      |
          |                      |--->| ... |      |
          |                           +-----+      |
          |                                        |
          +----------------------------------------+

Co-developed-by: Fenglin Wu <quic_fenglinw@quicinc.com>
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
---
 arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi | 405 +++++++++++++++++++
 1 file changed, 405 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi

diff --git a/arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi b/arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi
new file mode 100644
index 000000000000..f6960e2d466a
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi
@@ -0,0 +1,405 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "qcs8550.dtsi"
+#include "pm8550.dtsi"
+#include "pm8550b.dtsi"
+#define PMK8550VE_SID 5
+#include "pm8550ve.dtsi"
+#include "pm8550vs.dtsi"
+#include "pmk8550.dtsi"
+
+&apps_rsc {
+	regulators-0 {
+		compatible = "qcom,pm8550-rpmh-regulators";
+		qcom,pmic-id = "b";
+
+		vdd-l1-l4-l10-supply = <&vreg_s6g_1p86>;
+		vdd-l2-l13-l14-supply = <&vreg_bob1>;
+		vdd-l3-supply = <&vreg_s4g_1p25>;
+		vdd-l5-l16-supply = <&vreg_bob1>;
+		vdd-l6-l7-supply = <&vreg_bob1>;
+		vdd-l8-l9-supply = <&vreg_bob1>;
+		vdd-l11-supply = <&vreg_s4g_1p25>;
+		vdd-l12-supply = <&vreg_s6g_1p86>;
+		vdd-l15-supply = <&vreg_s6g_1p86>;
+		vdd-l17-supply = <&vreg_bob2>;
+
+		vreg_bob1: bob1 {
+			regulator-name = "vreg_bob1";
+			regulator-min-microvolt = <3296000>;
+			regulator-max-microvolt = <3960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_bob2: bob2 {
+			regulator-name = "vreg_bob2";
+			regulator-min-microvolt = <2720000>;
+			regulator-max-microvolt = <3960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1b_1p8: ldo1 {
+			regulator-name = "vreg_l1b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2b_3p0: ldo2 {
+			regulator-name = "vreg_l2b_3p0";
+			regulator-min-microvolt = <3008000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5b_3p1: ldo5 {
+			regulator-name = "vreg_l5b_3p1";
+			regulator-min-microvolt = <3104000>;
+			regulator-max-microvolt = <3104000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6b_1p8: ldo6 {
+			regulator-name = "vreg_l6b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7b_1p8: ldo7 {
+			regulator-name = "vreg_l7b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8b_1p8: ldo8 {
+			regulator-name = "vreg_l8b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9b_2p9: ldo9 {
+			regulator-name = "vreg_l9b_2p9";
+			regulator-min-microvolt = <2960000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l11b_1p2: ldo11 {
+			regulator-name = "vreg_l11b_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1504000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l12b_1p8: ldo12 {
+			regulator-name = "vreg_l12b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l13b_3p0: ldo13 {
+			regulator-name = "vreg_l13b_3p0";
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l14b_3p2: ldo14 {
+			regulator-name = "vreg_l14b_3p2";
+			regulator-min-microvolt = <3200000>;
+			regulator-max-microvolt = <3200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l15b_1p8: ldo15 {
+			regulator-name = "vreg_l15b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l16b_2p8: ldo16 {
+			regulator-name = "vreg_l16b_2p8";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l17b_2p5: ldo17 {
+			regulator-name = "vreg_l17b_2p5";
+			regulator-min-microvolt = <2504000>;
+			regulator-max-microvolt = <2504000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-1 {
+		compatible = "qcom,pm8550vs-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		vdd-l1-supply = <&vreg_s4g_1p25>;
+		vdd-l2-supply = <&vreg_s4e_0p95>;
+		vdd-l3-supply = <&vreg_s4e_0p95>;
+
+		vreg_l3c_0p9: ldo3 {
+			regulator-name = "vreg_l3c_0p9";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-2 {
+		compatible = "qcom,pm8550vs-rpmh-regulators";
+		qcom,pmic-id = "d";
+
+		vdd-l1-supply = <&vreg_s4e_0p95>;
+		vdd-l2-supply = <&vreg_s4e_0p95>;
+		vdd-l3-supply = <&vreg_s4e_0p95>;
+
+		vreg_l1d_0p88: ldo1 {
+			regulator-name = "vreg_l1d_0p88";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-3 {
+		compatible = "qcom,pm8550vs-rpmh-regulators";
+		qcom,pmic-id = "e";
+
+		vdd-l1-supply = <&vreg_s4e_0p95>;
+		vdd-l2-supply = <&vreg_s4e_0p95>;
+		vdd-l3-supply = <&vreg_s4g_1p25>;
+
+		vreg_s4e_0p95: smps4 {
+			regulator-name = "vreg_s4e_0p95";
+			regulator-min-microvolt = <904000>;
+			regulator-max-microvolt = <984000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s5e_1p08: smps5 {
+			regulator-name = "vreg_s5e_1p08";
+			regulator-min-microvolt = <1010000>;
+			regulator-max-microvolt = <1120000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1e_0p88: ldo1 {
+			regulator-name = "vreg_l1e_0p88";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2e_0p9: ldo2 {
+			regulator-name = "vreg_l2e_0p9";
+			regulator-min-microvolt = <870000>;
+			regulator-max-microvolt = <970000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3e_1p2: ldo3 {
+			regulator-name = "vreg_l3e_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-4 {
+		compatible = "qcom,pm8550ve-rpmh-regulators";
+		qcom,pmic-id = "f";
+
+		vdd-l1-supply = <&vreg_s4e_0p95>;
+		vdd-l2-supply = <&vreg_s4e_0p95>;
+		vdd-l3-supply = <&vreg_s4e_0p95>;
+
+		vreg_s4f_0p5: smps4 {
+			regulator-name = "vreg_s4f_0p5";
+			regulator-min-microvolt = <300000>;
+			regulator-max-microvolt = <700000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1f_0p9: ldo1 {
+			regulator-name = "vreg_l1f_0p9";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2f_0p88: ldo2 {
+			regulator-name = "vreg_l2f_0p88";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3f_0p88: ldo3 {
+			regulator-name = "vreg_l3f_0p88";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-5 {
+		compatible = "qcom,pm8550vs-rpmh-regulators";
+		qcom,pmic-id = "g";
+		vdd-l1-supply = <&vreg_s4g_1p25>;
+		vdd-l2-supply = <&vreg_s4g_1p25>;
+		vdd-l3-supply = <&vreg_s4g_1p25>;
+
+		vreg_s1g_1p25: smps1 {
+			regulator-name = "vreg_s1g_1p25";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s2g_0p85: smps2 {
+			regulator-name = "vreg_s2g_0p85";
+			regulator-min-microvolt = <500000>;
+			regulator-max-microvolt = <1036000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s3g_0p8: smps3 {
+			regulator-name = "vreg_s3g_0p8";
+			regulator-min-microvolt = <300000>;
+			regulator-max-microvolt = <1004000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s4g_1p25: smps4 {
+			regulator-name = "vreg_s4g_1p25";
+			regulator-min-microvolt = <1256000>;
+			regulator-max-microvolt = <1408000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s5g_0p85: smps5 {
+			regulator-name = "vreg_s5g_0p85";
+			regulator-min-microvolt = <500000>;
+			regulator-max-microvolt = <1004000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s6g_1p86: smps6 {
+			regulator-name = "vreg_s6g_1p86";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1g_1p2: ldo1 {
+			regulator-name = "vreg_l1g_1p2";
+			regulator-min-microvolt = <1128000>;
+			regulator-max-microvolt = <1272000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2g_1p2: ldo2 {
+			regulator-name = "vreg_l2g_1p2";
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3g_1p2: ldo3 {
+			regulator-name = "vreg_l3g_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+};
+
+&mdss_dsi0 {
+	vdda-supply = <&vreg_l3e_1p2>;
+};
+
+&mdss_dsi0_phy {
+	vdds-supply = <&vreg_l1e_0p88>;
+};
+
+&pcie0 {
+	perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+
+	pinctrl-0 = <&pcie0_default_state>;
+	pinctrl-names = "default";
+};
+
+&pcie0_phy {
+	vdda-phy-supply = <&vreg_l1e_0p88>;
+	vdda-pll-supply = <&vreg_l3e_1p2>;
+};
+
+&pcie1 {
+	perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+
+	pinctrl-0 = <&pcie1_default_state>;
+	pinctrl-names = "default";
+};
+
+&pcie1_phy {
+	vdda-phy-supply = <&vreg_l3c_0p9>;
+	vdda-pll-supply = <&vreg_l3e_1p2>;
+	vdda-qref-supply = <&vreg_l1e_0p88>;
+};
+
+&pm8550b_eusb2_repeater {
+	vdd18-supply = <&vreg_l15b_1p8>;
+	vdd3-supply = <&vreg_l5b_3p1>;
+};
+
+&sleep_clk {
+	clock-frequency = <32000>;
+};
+
+&ufs_mem_hc {
+	reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
+	vcc-supply = <&vreg_l17b_2p5>;
+	vcc-max-microamp = <1300000>;
+	vccq-supply = <&vreg_l1g_1p2>;
+	vccq-max-microamp = <1200000>;
+	vdd-hba-supply = <&vreg_l3g_1p2>;
+
+	status = "okay";
+};
+
+&ufs_mem_phy {
+	vdda-phy-supply = <&vreg_l1d_0p88>;
+	vdda-pll-supply = <&vreg_l3e_1p2>;
+
+	status = "okay";
+};
+
+&usb_1_hsphy {
+	phys = <&pm8550b_eusb2_repeater>;
+
+	vdd-supply = <&vreg_l1e_0p88>;
+	vdda12-supply = <&vreg_l3e_1p2>;
+};
+
+&usb_dp_qmpphy {
+	vdda-phy-supply = <&vreg_l3e_1p2>;
+	vdda-pll-supply = <&vreg_l3f_0p88>;
+};
+
+&xo_board {
+	clock-frequency = <76800000>;
+};
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v10 4/4] arm64: dts: qcom: aim300: add AIM300 AIoT
  2024-06-18  7:21 [PATCH v10 0/4] arm64: dts: qcom: aim300: add AIM300 AIoT Tengfei Fan
                   ` (2 preceding siblings ...)
  2024-06-18  7:22 ` [PATCH v10 3/4] arm64: dts: qcom: add base AIM300 dtsi Tengfei Fan
@ 2024-06-18  7:22 ` Tengfei Fan
  2024-06-18  8:48   ` Dmitry Baryshkov
  2024-06-21  6:11 ` [PATCH v10 0/4] " Bjorn Andersson
  4 siblings, 1 reply; 16+ messages in thread
From: Tengfei Fan @ 2024-06-18  7:22 UTC (permalink / raw)
  To: andersson, konrad.dybcio, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Tengfei Fan,
	Qiang Yu, Ziyue Zhang

Add AIM300 AIoT Carrier board DTS support, including usb, UART, PCIe,
I2C functions support.
Here is a diagram of AIM300 AIoT Carrie Board and SoM
 +--------------------------------------------------+
 |             AIM300 AIOT Carrier Board            |
 |                                                  |
 |           +-----------------+                    |
 |power----->| Fixed regulator |---------+          |
 |           +-----------------+         |          |
 |                                       |          |
 |                                       v VPH_PWR  |
 | +----------------------------------------------+ |
 | |                          AIM300 SOM |        | |
 | |                                     |VPH_PWR | |
 | |                                     v        | |
 | |   +-------+       +--------+     +------+    | |
 | |   | UFS   |       | QCS8550|     |PMIC  |    | |
 | |   +-------+       +--------+     +------+    | |
 | |                                              | |
 | +----------------------------------------------+ |
 |                                                  |
 |                    +----+          +------+      |
 |                    |USB |          | UART |      |
 |                    +----+          +------+      |
 +--------------------------------------------------+

Co-developed-by: Qiang Yu <quic_qianyu@quicinc.com>
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Co-developed-by: Ziyue Zhang <quic_ziyuzhan@quicinc.com>
Signed-off-by: Ziyue Zhang <quic_ziyuzhan@quicinc.com>
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
---
 arch/arm64/boot/dts/qcom/Makefile             |   1 +
 .../boot/dts/qcom/qcs8550-aim300-aiot.dts     | 315 ++++++++++++++++++
 2 files changed, 316 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 0c1cebd16649..5576c7d6ea06 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -102,6 +102,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-shift-otter.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qrb2210-rb1.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qrb4210-rb2.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts b/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
new file mode 100644
index 000000000000..d4fb10149e66
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include "qcs8550-aim300.dtsi"
+#include "pm8010.dtsi"
+#include "pmr735d_a.dtsi"
+#include "pmr735d_b.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. QCS8550 AIM300 AIOT";
+	compatible = "qcom,qcs8550-aim300-aiot", "qcom,qcs8550-aim300", "qcom,qcs8550",
+		     "qcom,sm8550";
+
+	aliases {
+		serial0 = &uart7;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		pinctrl-0 = <&volume_up_n>;
+		pinctrl-names = "default";
+
+		key-volume-up {
+			label = "Volume Up";
+			debounce-interval = <15>;
+			gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_VOLUMEUP>;
+			linux,can-disable;
+			wakeup-source;
+		};
+	};
+
+	pmic-glink {
+		compatible = "qcom,sm8550-pmic-glink", "qcom,pmic-glink";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		orientation-gpios = <&tlmm 11 GPIO_ACTIVE_HIGH>;
+
+		connector@0 {
+			compatible = "usb-c-connector";
+			reg = <0>;
+			power-role = "dual";
+			data-role = "dual";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+
+					pmic_glink_hs_in: endpoint {
+						remote-endpoint = <&usb_1_dwc3_hs>;
+					};
+				};
+
+				port@1 {
+					reg = <1>;
+
+					pmic_glink_ss_in: endpoint {
+						remote-endpoint = <&redriver_ss_out>;
+					};
+				};
+
+				port@2 {
+					reg = <2>;
+
+					pmic_glink_sbu: endpoint {
+						remote-endpoint = <&fsa4480_sbu_mux>;
+					};
+				};
+			};
+		};
+	};
+
+	vph_pwr: regulator-vph-pwr {
+		compatible = "regulator-fixed";
+		regulator-name = "vph_pwr";
+		regulator-min-microvolt = <3700000>;
+		regulator-max-microvolt = <3700000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+	};
+};
+
+&apps_rsc {
+	regulators-0 {
+		vdd-bob1-supply = <&vph_pwr>;
+		vdd-bob2-supply = <&vph_pwr>;
+	};
+
+	regulators-3 {
+		vdd-s4-supply = <&vph_pwr>;
+		vdd-s5-supply = <&vph_pwr>;
+	};
+
+	regulators-4 {
+		vdd-s4-supply = <&vph_pwr>;
+	};
+
+	regulators-5 {
+		vdd-s1-supply = <&vph_pwr>;
+		vdd-s2-supply = <&vph_pwr>;
+		vdd-s3-supply = <&vph_pwr>;
+		vdd-s4-supply = <&vph_pwr>;
+		vdd-s5-supply = <&vph_pwr>;
+		vdd-s6-supply = <&vph_pwr>;
+	};
+};
+
+&i2c_hub_2 {
+	status = "okay";
+
+	typec-mux@42 {
+		compatible = "fcs,fsa4480";
+		reg = <0x42>;
+
+		vcc-supply = <&vreg_bob1>;
+
+		mode-switch;
+		orientation-switch;
+
+		port {
+			fsa4480_sbu_mux: endpoint {
+				remote-endpoint = <&pmic_glink_sbu>;
+			};
+		};
+	};
+
+	typec-retimer@1c {
+		compatible = "onnn,nb7vpq904m";
+		reg = <0x1c>;
+
+		vcc-supply = <&vreg_l15b_1p8>;
+
+		orientation-switch;
+		retimer-switch;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				redriver_ss_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss_in>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+
+				redriver_ss_in: endpoint {
+					data-lanes = <3 2 1 0>;
+					remote-endpoint = <&usb_dp_qmpphy_out>;
+				};
+			};
+		};
+	};
+};
+
+&mdss_dsi0 {
+	status = "okay";
+
+	panel@0 {
+		compatible = "visionox,vtdr6130";
+		reg = <0>;
+
+		pinctrl-0 = <&dsi_active>, <&te_default>;
+		pinctrl-1 = <&dsi_suspend>, <&te_default>;
+		pinctrl-names = "default", "sleep";
+
+		reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
+
+		vci-supply = <&vreg_l13b_3p0>;
+		vdd-supply = <&vreg_l11b_1p2>;
+		vddio-supply = <&vreg_l12b_1p8>;
+
+		port {
+			panel0_in: endpoint {
+				remote-endpoint = <&mdss_dsi0_out>;
+			};
+		};
+	};
+};
+
+&mdss_dsi0_out {
+	remote-endpoint = <&panel0_in>;
+	data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi0_phy {
+	status = "okay";
+};
+
+&pcie0 {
+	status = "okay";
+};
+
+&pcie0_phy {
+	status = "okay";
+};
+
+&pcie1 {
+	status = "okay";
+};
+
+&pcie1_phy {
+	status = "okay";
+};
+
+&pm8550_gpios {
+	volume_up_n: volume-up-n-state {
+		pins = "gpio6";
+		function = "normal";
+		power-source = <1>;
+		bias-pull-up;
+		input-enable;
+	};
+};
+
+&pon_pwrkey {
+	status = "okay";
+};
+
+&pon_resin {
+	linux,code = <KEY_VOLUMEDOWN>;
+
+	status = "okay";
+};
+
+&qupv3_id_0 {
+	status = "okay";
+};
+
+&remoteproc_adsp {
+	firmware-name = "qcom/qcs8550/adsp.mbn",
+			"qcom/qcs8550/adsp_dtbs.mbn";
+	status = "okay";
+};
+
+&remoteproc_cdsp {
+	firmware-name = "qcom/qcs8550/cdsp.mbn",
+			"qcom/qcs8550/cdsp_dtbs.mbn";
+	status = "okay";
+};
+
+&swr1 {
+	status = "okay";
+};
+
+&swr2 {
+	status = "okay";
+};
+
+&tlmm {
+	gpio-reserved-ranges = <32 8>;
+
+	dsi_active: dsi-active-state {
+		pins = "gpio133";
+		function = "gpio";
+		drive-strength = <8>;
+		bias-disable;
+	};
+
+	dsi_suspend: dsi-suspend-state {
+		pins = "gpio133";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-pull-down;
+	};
+
+	te_default: te-default-state {
+		pins = "gpio86";
+		function = "mdp_vsync";
+		drive-strength = <2>;
+		bias-pull-down;
+	};
+};
+
+&uart7 {
+	status = "okay";
+};
+
+&usb_1 {
+	status = "okay";
+};
+
+&usb_1_dwc3_hs {
+	remote-endpoint = <&pmic_glink_hs_in>;
+};
+
+&usb_1_hsphy {
+	status = "okay";
+};
+
+&usb_dp_qmpphy {
+	status = "okay";
+};
+
+&usb_dp_qmpphy_out {
+	remote-endpoint = <&redriver_ss_in>;
+};
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 4/4] arm64: dts: qcom: aim300: add AIM300 AIoT
  2024-06-18  7:22 ` [PATCH v10 4/4] arm64: dts: qcom: aim300: add AIM300 AIoT Tengfei Fan
@ 2024-06-18  8:48   ` Dmitry Baryshkov
  2024-06-18  8:57     ` Tengfei Fan
  0 siblings, 1 reply; 16+ messages in thread
From: Dmitry Baryshkov @ 2024-06-18  8:48 UTC (permalink / raw)
  To: Tengfei Fan
  Cc: andersson, konrad.dybcio, robh, krzk+dt, conor+dt, linux-arm-msm,
	devicetree, linux-kernel, kernel, Qiang Yu, Ziyue Zhang

On Tue, Jun 18, 2024 at 03:22:02PM GMT, Tengfei Fan wrote:
> Add AIM300 AIoT Carrier board DTS support, including usb, UART, PCIe,
> I2C functions support.
> Here is a diagram of AIM300 AIoT Carrie Board and SoM
>  +--------------------------------------------------+
>  |             AIM300 AIOT Carrier Board            |
>  |                                                  |
>  |           +-----------------+                    |
>  |power----->| Fixed regulator |---------+          |
>  |           +-----------------+         |          |
>  |                                       |          |
>  |                                       v VPH_PWR  |
>  | +----------------------------------------------+ |
>  | |                          AIM300 SOM |        | |
>  | |                                     |VPH_PWR | |
>  | |                                     v        | |
>  | |   +-------+       +--------+     +------+    | |
>  | |   | UFS   |       | QCS8550|     |PMIC  |    | |
>  | |   +-------+       +--------+     +------+    | |
>  | |                                              | |
>  | +----------------------------------------------+ |
>  |                                                  |
>  |                    +----+          +------+      |
>  |                    |USB |          | UART |      |
>  |                    +----+          +------+      |
>  +--------------------------------------------------+
> 
> Co-developed-by: Qiang Yu <quic_qianyu@quicinc.com>
> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
> Co-developed-by: Ziyue Zhang <quic_ziyuzhan@quicinc.com>
> Signed-off-by: Ziyue Zhang <quic_ziyuzhan@quicinc.com>
> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile             |   1 +
>  .../boot/dts/qcom/qcs8550-aim300-aiot.dts     | 315 ++++++++++++++++++
>  2 files changed, 316 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 0c1cebd16649..5576c7d6ea06 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -102,6 +102,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-shift-otter.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qrb2210-rb1.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qrb4210-rb2.dtb
> diff --git a/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts b/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
> new file mode 100644
> index 000000000000..d4fb10149e66
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
> @@ -0,0 +1,315 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/leds/common.h>
> +#include "qcs8550-aim300.dtsi"
> +#include "pm8010.dtsi"
> +#include "pmr735d_a.dtsi"
> +#include "pmr735d_b.dtsi"
> +
> +/ {
> +	model = "Qualcomm Technologies, Inc. QCS8550 AIM300 AIOT";
> +	compatible = "qcom,qcs8550-aim300-aiot", "qcom,qcs8550-aim300", "qcom,qcs8550",
> +		     "qcom,sm8550";
> +
> +	aliases {
> +		serial0 = &uart7;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		pinctrl-0 = <&volume_up_n>;
> +		pinctrl-names = "default";
> +
> +		key-volume-up {
> +			label = "Volume Up";
> +			debounce-interval = <15>;
> +			gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_VOLUMEUP>;
> +			linux,can-disable;
> +			wakeup-source;
> +		};
> +	};
> +
> +	pmic-glink {
> +		compatible = "qcom,sm8550-pmic-glink", "qcom,pmic-glink";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		orientation-gpios = <&tlmm 11 GPIO_ACTIVE_HIGH>;
> +
> +		connector@0 {
> +			compatible = "usb-c-connector";
> +			reg = <0>;
> +			power-role = "dual";
> +			data-role = "dual";
> +
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				port@0 {
> +					reg = <0>;
> +
> +					pmic_glink_hs_in: endpoint {
> +						remote-endpoint = <&usb_1_dwc3_hs>;
> +					};
> +				};
> +
> +				port@1 {
> +					reg = <1>;
> +
> +					pmic_glink_ss_in: endpoint {
> +						remote-endpoint = <&redriver_ss_out>;
> +					};
> +				};
> +
> +				port@2 {
> +					reg = <2>;
> +
> +					pmic_glink_sbu: endpoint {
> +						remote-endpoint = <&fsa4480_sbu_mux>;
> +					};
> +				};
> +			};
> +		};
> +	};
> +
> +	vph_pwr: regulator-vph-pwr {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vph_pwr";
> +		regulator-min-microvolt = <3700000>;
> +		regulator-max-microvolt = <3700000>;
> +
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};
> +};
> +
> +&apps_rsc {
> +	regulators-0 {
> +		vdd-bob1-supply = <&vph_pwr>;
> +		vdd-bob2-supply = <&vph_pwr>;
> +	};
> +
> +	regulators-3 {
> +		vdd-s4-supply = <&vph_pwr>;
> +		vdd-s5-supply = <&vph_pwr>;
> +	};
> +
> +	regulators-4 {
> +		vdd-s4-supply = <&vph_pwr>;
> +	};
> +
> +	regulators-5 {
> +		vdd-s1-supply = <&vph_pwr>;
> +		vdd-s2-supply = <&vph_pwr>;
> +		vdd-s3-supply = <&vph_pwr>;
> +		vdd-s4-supply = <&vph_pwr>;
> +		vdd-s5-supply = <&vph_pwr>;
> +		vdd-s6-supply = <&vph_pwr>;
> +	};
> +};
> +
> +&i2c_hub_2 {
> +	status = "okay";
> +
> +	typec-mux@42 {
> +		compatible = "fcs,fsa4480";
> +		reg = <0x42>;
> +
> +		vcc-supply = <&vreg_bob1>;
> +
> +		mode-switch;
> +		orientation-switch;
> +
> +		port {
> +			fsa4480_sbu_mux: endpoint {
> +				remote-endpoint = <&pmic_glink_sbu>;
> +			};
> +		};
> +	};
> +
> +	typec-retimer@1c {
> +		compatible = "onnn,nb7vpq904m";
> +		reg = <0x1c>;
> +
> +		vcc-supply = <&vreg_l15b_1p8>;
> +
> +		orientation-switch;
> +		retimer-switch;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port@0 {
> +				reg = <0>;
> +
> +				redriver_ss_out: endpoint {
> +					remote-endpoint = <&pmic_glink_ss_in>;
> +				};
> +			};
> +
> +			port@1 {
> +				reg = <1>;
> +
> +				redriver_ss_in: endpoint {
> +					data-lanes = <3 2 1 0>;
> +					remote-endpoint = <&usb_dp_qmpphy_out>;
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&mdss_dsi0 {
> +	status = "okay";
> +
> +	panel@0 {
> +		compatible = "visionox,vtdr6130";
> +		reg = <0>;
> +
> +		pinctrl-0 = <&dsi_active>, <&te_default>;
> +		pinctrl-1 = <&dsi_suspend>, <&te_default>;
> +		pinctrl-names = "default", "sleep";
> +
> +		reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
> +
> +		vci-supply = <&vreg_l13b_3p0>;
> +		vdd-supply = <&vreg_l11b_1p2>;
> +		vddio-supply = <&vreg_l12b_1p8>;
> +
> +		port {
> +			panel0_in: endpoint {
> +				remote-endpoint = <&mdss_dsi0_out>;
> +			};
> +		};
> +	};
> +};
> +
> +&mdss_dsi0_out {
> +	remote-endpoint = <&panel0_in>;
> +	data-lanes = <0 1 2 3>;
> +};
> +
> +&mdss_dsi0_phy {
> +	status = "okay";
> +};
> +
> +&pcie0 {
> +	status = "okay";
> +};
> +
> +&pcie0_phy {
> +	status = "okay";
> +};
> +
> +&pcie1 {
> +	status = "okay";
> +};
> +
> +&pcie1_phy {
> +	status = "okay";
> +};
> +
> +&pm8550_gpios {
> +	volume_up_n: volume-up-n-state {
> +		pins = "gpio6";
> +		function = "normal";
> +		power-source = <1>;
> +		bias-pull-up;
> +		input-enable;
> +	};
> +};
> +
> +&pon_pwrkey {
> +	status = "okay";
> +};
> +
> +&pon_resin {
> +	linux,code = <KEY_VOLUMEDOWN>;
> +
> +	status = "okay";
> +};
> +
> +&qupv3_id_0 {
> +	status = "okay";
> +};
> +
> +&remoteproc_adsp {
> +	firmware-name = "qcom/qcs8550/adsp.mbn",
> +			"qcom/qcs8550/adsp_dtbs.mbn";

adsp_dtb.mbn, not _dtbs.mbn.

https://lore.kernel.org/linux-arm-msm/s5gt3p6zsd5ebrkop4dhd33tykln33f6ahu3pibymecxsmakyd@lg5wfgec6dat/

> +	status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> +	firmware-name = "qcom/qcs8550/cdsp.mbn",
> +			"qcom/qcs8550/cdsp_dtbs.mbn";
> +	status = "okay";
> +};
> +
> +&swr1 {
> +	status = "okay";
> +};
> +
> +&swr2 {
> +	status = "okay";
> +};
> +
> +&tlmm {
> +	gpio-reserved-ranges = <32 8>;
> +
> +	dsi_active: dsi-active-state {
> +		pins = "gpio133";
> +		function = "gpio";
> +		drive-strength = <8>;
> +		bias-disable;
> +	};
> +
> +	dsi_suspend: dsi-suspend-state {
> +		pins = "gpio133";
> +		function = "gpio";
> +		drive-strength = <2>;
> +		bias-pull-down;
> +	};
> +
> +	te_default: te-default-state {
> +		pins = "gpio86";
> +		function = "mdp_vsync";
> +		drive-strength = <2>;
> +		bias-pull-down;
> +	};
> +};
> +
> +&uart7 {
> +	status = "okay";
> +};
> +
> +&usb_1 {
> +	status = "okay";
> +};
> +
> +&usb_1_dwc3_hs {
> +	remote-endpoint = <&pmic_glink_hs_in>;
> +};
> +
> +&usb_1_hsphy {
> +	status = "okay";
> +};
> +
> +&usb_dp_qmpphy {
> +	status = "okay";
> +};
> +
> +&usb_dp_qmpphy_out {
> +	remote-endpoint = <&redriver_ss_in>;
> +};
> -- 
> 2.25.1
> 

-- 
With best wishes
Dmitry

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 4/4] arm64: dts: qcom: aim300: add AIM300 AIoT
  2024-06-18  8:48   ` Dmitry Baryshkov
@ 2024-06-18  8:57     ` Tengfei Fan
  0 siblings, 0 replies; 16+ messages in thread
From: Tengfei Fan @ 2024-06-18  8:57 UTC (permalink / raw)
  To: Dmitry Baryshkov
  Cc: andersson, konrad.dybcio, robh, krzk+dt, conor+dt, linux-arm-msm,
	devicetree, linux-kernel, kernel, Qiang Yu, Ziyue Zhang



On 6/18/2024 4:48 PM, Dmitry Baryshkov wrote:
> On Tue, Jun 18, 2024 at 03:22:02PM GMT, Tengfei Fan wrote:
>> Add AIM300 AIoT Carrier board DTS support, including usb, UART, PCIe,
>> I2C functions support.
>> Here is a diagram of AIM300 AIoT Carrie Board and SoM
>>   +--------------------------------------------------+
>>   |             AIM300 AIOT Carrier Board            |
>>   |                                                  |
>>   |           +-----------------+                    |
>>   |power----->| Fixed regulator |---------+          |
>>   |           +-----------------+         |          |
>>   |                                       |          |
>>   |                                       v VPH_PWR  |
>>   | +----------------------------------------------+ |
>>   | |                          AIM300 SOM |        | |
>>   | |                                     |VPH_PWR | |
>>   | |                                     v        | |
>>   | |   +-------+       +--------+     +------+    | |
>>   | |   | UFS   |       | QCS8550|     |PMIC  |    | |
>>   | |   +-------+       +--------+     +------+    | |
>>   | |                                              | |
>>   | +----------------------------------------------+ |
>>   |                                                  |
>>   |                    +----+          +------+      |
>>   |                    |USB |          | UART |      |
>>   |                    +----+          +------+      |
>>   +--------------------------------------------------+
>>
>> Co-developed-by: Qiang Yu <quic_qianyu@quicinc.com>
>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
>> Co-developed-by: Ziyue Zhang <quic_ziyuzhan@quicinc.com>
>> Signed-off-by: Ziyue Zhang <quic_ziyuzhan@quicinc.com>
>> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
>> ---
>>   arch/arm64/boot/dts/qcom/Makefile             |   1 +
>>   .../boot/dts/qcom/qcs8550-aim300-aiot.dts     | 315 ++++++++++++++++++
>>   2 files changed, 316 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
>>
>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>> index 0c1cebd16649..5576c7d6ea06 100644
>> --- a/arch/arm64/boot/dts/qcom/Makefile
>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>> @@ -102,6 +102,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-shift-otter.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
>> +dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qrb2210-rb1.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qrb4210-rb2.dtb
>> diff --git a/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts b/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
>> new file mode 100644
>> index 000000000000..d4fb10149e66
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
>> @@ -0,0 +1,315 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include <dt-bindings/leds/common.h>
>> +#include "qcs8550-aim300.dtsi"
>> +#include "pm8010.dtsi"
>> +#include "pmr735d_a.dtsi"
>> +#include "pmr735d_b.dtsi"
>> +
>> +/ {
>> +	model = "Qualcomm Technologies, Inc. QCS8550 AIM300 AIOT";
>> +	compatible = "qcom,qcs8550-aim300-aiot", "qcom,qcs8550-aim300", "qcom,qcs8550",
>> +		     "qcom,sm8550";
>> +
>> +	aliases {
>> +		serial0 = &uart7;
>> +	};
>> +
>> +	chosen {
>> +		stdout-path = "serial0:115200n8";
>> +	};
>> +
>> +	gpio-keys {
>> +		compatible = "gpio-keys";
>> +
>> +		pinctrl-0 = <&volume_up_n>;
>> +		pinctrl-names = "default";
>> +
>> +		key-volume-up {
>> +			label = "Volume Up";
>> +			debounce-interval = <15>;
>> +			gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
>> +			linux,code = <KEY_VOLUMEUP>;
>> +			linux,can-disable;
>> +			wakeup-source;
>> +		};
>> +	};
>> +
>> +	pmic-glink {
>> +		compatible = "qcom,sm8550-pmic-glink", "qcom,pmic-glink";
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		orientation-gpios = <&tlmm 11 GPIO_ACTIVE_HIGH>;
>> +
>> +		connector@0 {
>> +			compatible = "usb-c-connector";
>> +			reg = <0>;
>> +			power-role = "dual";
>> +			data-role = "dual";
>> +
>> +			ports {
>> +				#address-cells = <1>;
>> +				#size-cells = <0>;
>> +
>> +				port@0 {
>> +					reg = <0>;
>> +
>> +					pmic_glink_hs_in: endpoint {
>> +						remote-endpoint = <&usb_1_dwc3_hs>;
>> +					};
>> +				};
>> +
>> +				port@1 {
>> +					reg = <1>;
>> +
>> +					pmic_glink_ss_in: endpoint {
>> +						remote-endpoint = <&redriver_ss_out>;
>> +					};
>> +				};
>> +
>> +				port@2 {
>> +					reg = <2>;
>> +
>> +					pmic_glink_sbu: endpoint {
>> +						remote-endpoint = <&fsa4480_sbu_mux>;
>> +					};
>> +				};
>> +			};
>> +		};
>> +	};
>> +
>> +	vph_pwr: regulator-vph-pwr {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vph_pwr";
>> +		regulator-min-microvolt = <3700000>;
>> +		regulator-max-microvolt = <3700000>;
>> +
>> +		regulator-always-on;
>> +		regulator-boot-on;
>> +	};
>> +};
>> +
>> +&apps_rsc {
>> +	regulators-0 {
>> +		vdd-bob1-supply = <&vph_pwr>;
>> +		vdd-bob2-supply = <&vph_pwr>;
>> +	};
>> +
>> +	regulators-3 {
>> +		vdd-s4-supply = <&vph_pwr>;
>> +		vdd-s5-supply = <&vph_pwr>;
>> +	};
>> +
>> +	regulators-4 {
>> +		vdd-s4-supply = <&vph_pwr>;
>> +	};
>> +
>> +	regulators-5 {
>> +		vdd-s1-supply = <&vph_pwr>;
>> +		vdd-s2-supply = <&vph_pwr>;
>> +		vdd-s3-supply = <&vph_pwr>;
>> +		vdd-s4-supply = <&vph_pwr>;
>> +		vdd-s5-supply = <&vph_pwr>;
>> +		vdd-s6-supply = <&vph_pwr>;
>> +	};
>> +};
>> +
>> +&i2c_hub_2 {
>> +	status = "okay";
>> +
>> +	typec-mux@42 {
>> +		compatible = "fcs,fsa4480";
>> +		reg = <0x42>;
>> +
>> +		vcc-supply = <&vreg_bob1>;
>> +
>> +		mode-switch;
>> +		orientation-switch;
>> +
>> +		port {
>> +			fsa4480_sbu_mux: endpoint {
>> +				remote-endpoint = <&pmic_glink_sbu>;
>> +			};
>> +		};
>> +	};
>> +
>> +	typec-retimer@1c {
>> +		compatible = "onnn,nb7vpq904m";
>> +		reg = <0x1c>;
>> +
>> +		vcc-supply = <&vreg_l15b_1p8>;
>> +
>> +		orientation-switch;
>> +		retimer-switch;
>> +
>> +		ports {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			port@0 {
>> +				reg = <0>;
>> +
>> +				redriver_ss_out: endpoint {
>> +					remote-endpoint = <&pmic_glink_ss_in>;
>> +				};
>> +			};
>> +
>> +			port@1 {
>> +				reg = <1>;
>> +
>> +				redriver_ss_in: endpoint {
>> +					data-lanes = <3 2 1 0>;
>> +					remote-endpoint = <&usb_dp_qmpphy_out>;
>> +				};
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&mdss_dsi0 {
>> +	status = "okay";
>> +
>> +	panel@0 {
>> +		compatible = "visionox,vtdr6130";
>> +		reg = <0>;
>> +
>> +		pinctrl-0 = <&dsi_active>, <&te_default>;
>> +		pinctrl-1 = <&dsi_suspend>, <&te_default>;
>> +		pinctrl-names = "default", "sleep";
>> +
>> +		reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
>> +
>> +		vci-supply = <&vreg_l13b_3p0>;
>> +		vdd-supply = <&vreg_l11b_1p2>;
>> +		vddio-supply = <&vreg_l12b_1p8>;
>> +
>> +		port {
>> +			panel0_in: endpoint {
>> +				remote-endpoint = <&mdss_dsi0_out>;
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&mdss_dsi0_out {
>> +	remote-endpoint = <&panel0_in>;
>> +	data-lanes = <0 1 2 3>;
>> +};
>> +
>> +&mdss_dsi0_phy {
>> +	status = "okay";
>> +};
>> +
>> +&pcie0 {
>> +	status = "okay";
>> +};
>> +
>> +&pcie0_phy {
>> +	status = "okay";
>> +};
>> +
>> +&pcie1 {
>> +	status = "okay";
>> +};
>> +
>> +&pcie1_phy {
>> +	status = "okay";
>> +};
>> +
>> +&pm8550_gpios {
>> +	volume_up_n: volume-up-n-state {
>> +		pins = "gpio6";
>> +		function = "normal";
>> +		power-source = <1>;
>> +		bias-pull-up;
>> +		input-enable;
>> +	};
>> +};
>> +
>> +&pon_pwrkey {
>> +	status = "okay";
>> +};
>> +
>> +&pon_resin {
>> +	linux,code = <KEY_VOLUMEDOWN>;
>> +
>> +	status = "okay";
>> +};
>> +
>> +&qupv3_id_0 {
>> +	status = "okay";
>> +};
>> +
>> +&remoteproc_adsp {
>> +	firmware-name = "qcom/qcs8550/adsp.mbn",
>> +			"qcom/qcs8550/adsp_dtbs.mbn";
> 
> adsp_dtb.mbn, not _dtbs.mbn.
> 
> https://lore.kernel.org/linux-arm-msm/s5gt3p6zsd5ebrkop4dhd33tykln33f6ahu3pibymecxsmakyd@lg5wfgec6dat/

Previously, I observed different names in the comments and the patch, 
and I initially think that "_dtb" is a clerical error. However, I now 
realize that this is my mistake, and I will update "_dtbs" with "_dtb" 
in the next verion patch series.

> 
>> +	status = "okay";
>> +};
>> +
>> +&remoteproc_cdsp {
>> +	firmware-name = "qcom/qcs8550/cdsp.mbn",
>> +			"qcom/qcs8550/cdsp_dtbs.mbn";
>> +	status = "okay";
>> +};
>> +
>> +&swr1 {
>> +	status = "okay";
>> +};
>> +
>> +&swr2 {
>> +	status = "okay";
>> +};
>> +
>> +&tlmm {
>> +	gpio-reserved-ranges = <32 8>;
>> +
>> +	dsi_active: dsi-active-state {
>> +		pins = "gpio133";
>> +		function = "gpio";
>> +		drive-strength = <8>;
>> +		bias-disable;
>> +	};
>> +
>> +	dsi_suspend: dsi-suspend-state {
>> +		pins = "gpio133";
>> +		function = "gpio";
>> +		drive-strength = <2>;
>> +		bias-pull-down;
>> +	};
>> +
>> +	te_default: te-default-state {
>> +		pins = "gpio86";
>> +		function = "mdp_vsync";
>> +		drive-strength = <2>;
>> +		bias-pull-down;
>> +	};
>> +};
>> +
>> +&uart7 {
>> +	status = "okay";
>> +};
>> +
>> +&usb_1 {
>> +	status = "okay";
>> +};
>> +
>> +&usb_1_dwc3_hs {
>> +	remote-endpoint = <&pmic_glink_hs_in>;
>> +};
>> +
>> +&usb_1_hsphy {
>> +	status = "okay";
>> +};
>> +
>> +&usb_dp_qmpphy {
>> +	status = "okay";
>> +};
>> +
>> +&usb_dp_qmpphy_out {
>> +	remote-endpoint = <&redriver_ss_in>;
>> +};
>> -- 
>> 2.25.1
>>
> 

-- 
Thx and BRs,
Tengfei Fan

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi
  2024-06-18  7:22 ` [PATCH v10 2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi Tengfei Fan
@ 2024-06-18 10:06   ` Caleb Connolly
  2024-06-20 13:40     ` Tengfei Fan
  0 siblings, 1 reply; 16+ messages in thread
From: Caleb Connolly @ 2024-06-18 10:06 UTC (permalink / raw)
  To: Tengfei Fan, andersson, konrad.dybcio, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel

HI Tengfei,

On 18/06/2024 09:22, Tengfei Fan wrote:
> QCS8550 is derived from SM8550. The difference between SM8550 and
> QCS8550 is QCS8550 doesn't have modem RF system. QCS8550 is mainly used
> in IoT products.
> QCS8550 firmware has different memory map compared to SM8550.
> The memory map will be runtime added through bootloader.
> There are 3 types of reserved memory regions here:
> 1. Firmware related regions which aren't shared with kernel.
>      The device tree source in kernel doesn't need to have node to indicate
> the firmware related reserved information. Bootloader converys the
> information by updating devicetree at runtime.
>      This will be described as: UEFI saves the physical address of the
> UEFI System Table to dts file's chosen node. Kernel read this table and
> add reserved memory regions to efi config table. Current reserved memory
> region may have reserved region which was not yet used, release note of
> the firmware have such kind of information.
> 2. Firmware related memory regions which are shared with Kernel
>      The device tree source in the kernel needs to include nodes that
> indicate fimware-related shared information. A label name is suggested
> because this type of shared information needs to be referenced by
> specific drivers for handling purposes.
>      Unlike previous platforms, QCS8550 boots using EFI and describes
> most reserved regions in the ESRT memory map. As a result, reserved
> memory regions which aren't relevant to the kernel(like the hypervisor
> region) don't need to be described in DT.
> 3. Remoteproc regions.
>      Remoteproc regions will be reserved and then assigned to subsystem
> firmware later.
> Here is a reserved memory map for this platform:
>   0x80000000 +-------------------+
>              |                   |
>              | Firmware Related  |
>              |                   |
>   0x8a800000 +-------------------+
>              |                   |
>              | Remoteproc Region |
>              |                   |
>   0xa7000000 +-------------------+
>              |                   |
>              | Kernel Available  |
>              |                   |
>   0xd4d00000 +-------------------+
>              |                   |
>              | Firmware Related  |
>              |                   |
> 0x100000000 +-------------------+
> 
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
> ---
>   arch/arm64/boot/dts/qcom/qcs8550.dtsi | 162 ++++++++++++++++++++++++++
>   1 file changed, 162 insertions(+)
>   create mode 100644 arch/arm64/boot/dts/qcom/qcs8550.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs8550.dtsi b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
> new file mode 100644
> index 000000000000..07b314834d88
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
> @@ -0,0 +1,162 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include "sm8550.dtsi"
> +
> +/delete-node/ &reserved_memory;
> +
> +/ {
> +	reserved_memory: reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +
> +		/* These are 3 types of reserved memory regions here:
> +		 * 1. Firmware related regions which aren't shared with kernel.
> +		 *     The device tree source in kernel doesn't need to have node to
> +		 * indicate the firmware related reserved information. Bootloader
> +		 * conveys the information by updating devicetree at runtime.
> +		 *     This will be described as: UEFI saves the physical address of
> +		 * the UEFI System Table to dts file's chosen node. Kernel read this
> +		 * table and add reserved memory regions to efi config table. Current
> +		 * reserved memory region may have reserved region which was not yet
> +		 * used, release note of the firmware have such kind of information.

This is a lot of implementation detail about UEFI, I'd imagine that 
anyone curious can go read the relevant docs instead. It's a lot of 
words just to say "Firmware regions which the kernel doesn't need to 
know about which are not included in the EFI provided memory map."
> +		 * 2. Firmware related memory regions which are shared with Kernel
> +		 *     The device tree source in the kernel needs to include nodes
> +		 * that indicate fimware-related shared information. A label name
> +		 * is suggested because this type of shared information needs to
> +		 * be referenced by specific drivers for handling purposes.

"Firmware regions the kernel DOES need to know about, which are 
described in the reserved-memory node".
> +		 *     Unlike previous platforms, QCS8550 boots using EFI and describes
> +		 * most reserved regions in the ESRT memory map. As a result, reserved
> +		 * memory regions which aren't relevant to the kernel(like the hypervisor
> +		 ( region) don't need to be described in DT.

These would fall under (1) "firmware the kernel doesn't need to know about"
> +		 * 3. Remoteproc regions.
> +		 *     Remoteproc regions will be reserved and then assigned to
> +		 * subsystem firmware later.

How do these differ from those described in (2)?

I think this comment is trying to describe too much at once. You're 
trying to describe what the different types of reserved memory are, how 
the kernel learns about them, and how this differs from previous 
platforms all at once. I think you should tackle these points separately:

First describe the types of reserved memory and how the kernel learns 
about them (my suggestions above). Then describe the differences with 
previous platforms (like the hypervisor example).

Thanks and regards,
> +		 * Here is a reserved memory map for this platform:
> +		 *  0x80000000 +-------------------+
> +		 *             |                   |
> +		 *             | Firmware Related  |
> +		 *             |                   |
> +		 *  0x8a800000 +-------------------+
> +		 *             |                   |
> +		 *             | Remoteproc Region |
> +		 *             |                   |
> +		 *  0xa7000000 +-------------------+
> +		 *             |                   |
> +		 *             | Kernel Available  |
> +		 *             |                   |
> +		 *  0xd4d00000 +-------------------+
> +		 *             |                   |
> +		 *             | Firmware Related  |
> +		 *             |                   |
> +		 * 0x100000000 +-------------------+
> +		 */
> +
> +		aop_image_mem: aop-image-region@81c00000 {
> +			reg = <0x0 0x81c00000 0x0 0x60000>;
> +			no-map;
> +		};
> +
> +		aop_cmd_db_mem: aop-cmd-db-region@81c60000 {
> +			compatible = "qcom,cmd-db";
> +			reg = <0x0 0x81c60000 0x0 0x20000>;
> +			no-map;
> +		};
> +
> +		aop_config_mem: aop-config-region@81c80000 {
> +			no-map;
> +			reg = <0x0 0x81c80000 0x0 0x20000>;
> +		};
> +
> +		smem_mem: smem-region@81d00000 {
> +			compatible = "qcom,smem";
> +			reg = <0x0 0x81d00000 0x0 0x200000>;
> +			hwlocks = <&tcsr_mutex 3>;
> +			no-map;
> +		};
> +
> +		adsp_mhi_mem: adsp-mhi-region@81f00000 {
> +			reg = <0x0 0x81f00000 0x0 0x20000>;
> +			no-map;
> +		};
> +
> +		mpss_mem: mpss-region@8a800000 {
> +			reg = <0x0 0x8a800000 0x0 0x10800000>;
> +			no-map;
> +		};
> +
> +		q6_mpss_dtb_mem: q6-mpss-dtb-region@9b000000 {
> +			reg = <0x0 0x9b000000 0x0 0x80000>;
> +			no-map;
> +		};
> +
> +		ipa_fw_mem: ipa-fw-region@9b080000 {
> +			reg = <0x0 0x9b080000 0x0 0x10000>;
> +			no-map;
> +		};
> +
> +		ipa_gsi_mem: ipa-gsi-region@9b090000 {
> +			reg = <0x0 0x9b090000 0x0 0xa000>;
> +			no-map;
> +		};
> +
> +		gpu_micro_code_mem: gpu-micro-code-region@9b09a000 {
> +			reg = <0x0 0x9b09a000 0x0 0x2000>;
> +			no-map;
> +		};
> +
> +		spss_region_mem: spss-region@9b100000 {
> +			reg = <0x0 0x9b100000 0x0 0x180000>;
> +			no-map;
> +		};
> +
> +		spu_secure_shared_memory_mem: spu-secure-shared-memory-region@9b280000 {
> +			reg = <0x0 0x9b280000 0x0 0x80000>;
> +			no-map;
> +		};
> +
> +		camera_mem: camera-region@9b300000 {
> +			reg = <0x0 0x9b300000 0x0 0x800000>;
> +			no-map;
> +		};
> +
> +		video_mem: video-region@9bb00000 {
> +			reg = <0x0 0x9bb00000 0x0 0x700000>;
> +			no-map;
> +		};
> +
> +		cvp_mem: cvp-region@9c200000 {
> +			reg = <0x0 0x9c200000 0x0 0x700000>;
> +			no-map;
> +		};
> +
> +		cdsp_mem: cdsp-region@9c900000 {
> +			reg = <0x0 0x9c900000 0x0 0x2000000>;
> +			no-map;
> +		};
> +
> +		q6_cdsp_dtb_mem: q6-cdsp-dtb-region@9e900000 {
> +			reg = <0x0 0x9e900000 0x0 0x80000>;
> +			no-map;
> +		};
> +
> +		q6_adsp_dtb_mem: q6-adsp-dtb-region@9e980000 {
> +			reg = <0x0 0x9e980000 0x0 0x80000>;
> +			no-map;
> +		};
> +
> +		adspslpi_mem: adspslpi-region@9ea00000 {
> +			reg = <0x0 0x9ea00000 0x0 0x4080000>;
> +			no-map;
> +		};
> +
> +		mpss_dsm_mem: mpss_dsm_region@d4d00000 {
> +			reg = <0x0 0xd4d00000 0x0 0x3300000>;
> +			no-map;
> +		};
> +	};
> +};

-- 
// Caleb (they/them)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 3/4] arm64: dts: qcom: add base AIM300 dtsi
  2024-06-18  7:22 ` [PATCH v10 3/4] arm64: dts: qcom: add base AIM300 dtsi Tengfei Fan
@ 2024-06-18 19:06   ` Konrad Dybcio
  2024-06-20  0:46     ` Tengfei Fan
  0 siblings, 1 reply; 16+ messages in thread
From: Konrad Dybcio @ 2024-06-18 19:06 UTC (permalink / raw)
  To: Tengfei Fan, andersson, robh, krzk+dt, conor+dt, dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Fenglin Wu



On 6/18/24 09:22, Tengfei Fan wrote:
> AIM300 Series is a highly optimized family of modules designed to
> support AIoT applications. It integrates QCS8550 SoC, UFS and PMIC
> chip etc.
> Here is a diagram of AIM300 SoM:
>            +----------------------------------------+
>            |AIM300 SoM                              |
>            |                                        |
>            |                           +-----+      |
>            |                      |--->| UFS |      |
>            |                      |    +-----+      |
>            |                      |                 |
>            |                      |                 |
>       3.7v |  +-----------------+ |    +---------+  |
>    ---------->|       PMIC      |----->| QCS8550 |  |
>            |  +-----------------+      +---------+  |
>            |                      |                 |
>            |                      |                 |
>            |                      |    +-----+      |
>            |                      |--->| ... |      |
>            |                           +-----+      |
>            |                                        |
>            +----------------------------------------+
> 
> Co-developed-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
> ---

[...]

> +&ufs_mem_hc {
> +	reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
> +	vcc-supply = <&vreg_l17b_2p5>;
> +	vcc-max-microamp = <1300000>;
> +	vccq-supply = <&vreg_l1g_1p2>;
> +	vccq-max-microamp = <1200000>;
> +	vdd-hba-supply = <&vreg_l3g_1p2>;

These regulators should generally have:

regulator-allow-set-load;
regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
                            RPMH_REGULATOR_MODE_HPM>;

although the current setup you have never lets them exit HPM

Konrad

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 3/4] arm64: dts: qcom: add base AIM300 dtsi
  2024-06-18 19:06   ` Konrad Dybcio
@ 2024-06-20  0:46     ` Tengfei Fan
  2024-06-22 11:09       ` Konrad Dybcio
  0 siblings, 1 reply; 16+ messages in thread
From: Tengfei Fan @ 2024-06-20  0:46 UTC (permalink / raw)
  To: Konrad Dybcio, andersson, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Fenglin Wu



On 6/19/2024 3:06 AM, Konrad Dybcio wrote:
> 
> 
> On 6/18/24 09:22, Tengfei Fan wrote:
>> AIM300 Series is a highly optimized family of modules designed to
>> support AIoT applications. It integrates QCS8550 SoC, UFS and PMIC
>> chip etc.
>> Here is a diagram of AIM300 SoM:
>>            +----------------------------------------+
>>            |AIM300 SoM                              |
>>            |                                        |
>>            |                           +-----+      |
>>            |                      |--->| UFS |      |
>>            |                      |    +-----+      |
>>            |                      |                 |
>>            |                      |                 |
>>       3.7v |  +-----------------+ |    +---------+  |
>>    ---------->|       PMIC      |----->| QCS8550 |  |
>>            |  +-----------------+      +---------+  |
>>            |                      |                 |
>>            |                      |                 |
>>            |                      |    +-----+      |
>>            |                      |--->| ... |      |
>>            |                           +-----+      |
>>            |                                        |
>>            +----------------------------------------+
>>
>> Co-developed-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
>> ---
> 
> [...]
> 
>> +&ufs_mem_hc {
>> +    reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
>> +    vcc-supply = <&vreg_l17b_2p5>;
>> +    vcc-max-microamp = <1300000>;
>> +    vccq-supply = <&vreg_l1g_1p2>;
>> +    vccq-max-microamp = <1200000>;
>> +    vdd-hba-supply = <&vreg_l3g_1p2>;
> 
> These regulators should generally have:
> 
> regulator-allow-set-load;
> regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
>                             RPMH_REGULATOR_MODE_HPM>;
> 
> although the current setup you have never lets them exit HPM
> 
> Konrad

I understand your point is that these settings need to be added to 
allthe child regulator nodes of regulators-0, regulators-1, 
regulators-2, regulators-3, regulators-4 and regulators-5. Is that correct?



-- 
Thx and BRs,
Tengfei Fan

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi
  2024-06-18 10:06   ` Caleb Connolly
@ 2024-06-20 13:40     ` Tengfei Fan
  2024-06-20 13:49       ` Caleb Connolly
  0 siblings, 1 reply; 16+ messages in thread
From: Tengfei Fan @ 2024-06-20 13:40 UTC (permalink / raw)
  To: Caleb Connolly, andersson, konrad.dybcio, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel



On 6/18/2024 6:06 PM, Caleb Connolly wrote:
> HI Tengfei,
> 
> On 18/06/2024 09:22, Tengfei Fan wrote:
>> QCS8550 is derived from SM8550. The difference between SM8550 and
>> QCS8550 is QCS8550 doesn't have modem RF system. QCS8550 is mainly used
>> in IoT products.
>> QCS8550 firmware has different memory map compared to SM8550.
>> The memory map will be runtime added through bootloader.
>> There are 3 types of reserved memory regions here:
>> 1. Firmware related regions which aren't shared with kernel.
>>      The device tree source in kernel doesn't need to have node to 
>> indicate
>> the firmware related reserved information. Bootloader converys the
>> information by updating devicetree at runtime.
>>      This will be described as: UEFI saves the physical address of the
>> UEFI System Table to dts file's chosen node. Kernel read this table and
>> add reserved memory regions to efi config table. Current reserved memory
>> region may have reserved region which was not yet used, release note of
>> the firmware have such kind of information.
>> 2. Firmware related memory regions which are shared with Kernel
>>      The device tree source in the kernel needs to include nodes that
>> indicate fimware-related shared information. A label name is suggested
>> because this type of shared information needs to be referenced by
>> specific drivers for handling purposes.
>>      Unlike previous platforms, QCS8550 boots using EFI and describes
>> most reserved regions in the ESRT memory map. As a result, reserved
>> memory regions which aren't relevant to the kernel(like the hypervisor
>> region) don't need to be described in DT.
>> 3. Remoteproc regions.
>>      Remoteproc regions will be reserved and then assigned to subsystem
>> firmware later.
>> Here is a reserved memory map for this platform:
>>   0x80000000 +-------------------+
>>              |                   |
>>              | Firmware Related  |
>>              |                   |
>>   0x8a800000 +-------------------+
>>              |                   |
>>              | Remoteproc Region |
>>              |                   |
>>   0xa7000000 +-------------------+
>>              |                   |
>>              | Kernel Available  |
>>              |                   |
>>   0xd4d00000 +-------------------+
>>              |                   |
>>              | Firmware Related  |
>>              |                   |
>> 0x100000000 +-------------------+
>>
>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
>> ---
>>   arch/arm64/boot/dts/qcom/qcs8550.dtsi | 162 ++++++++++++++++++++++++++
>>   1 file changed, 162 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs8550.dtsi 
>> b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>> new file mode 100644
>> index 000000000000..07b314834d88
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>> @@ -0,0 +1,162 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All 
>> rights reserved.
>> + */
>> +
>> +#include "sm8550.dtsi"
>> +
>> +/delete-node/ &reserved_memory;
>> +
>> +/ {
>> +    reserved_memory: reserved-memory {
>> +        #address-cells = <2>;
>> +        #size-cells = <2>;
>> +        ranges;
>> +
>> +
>> +        /* These are 3 types of reserved memory regions here:
>> +         * 1. Firmware related regions which aren't shared with kernel.
>> +         *     The device tree source in kernel doesn't need to have 
>> node to
>> +         * indicate the firmware related reserved information. 
>> Bootloader
>> +         * conveys the information by updating devicetree at runtime.
>> +         *     This will be described as: UEFI saves the physical 
>> address of
>> +         * the UEFI System Table to dts file's chosen node. Kernel 
>> read this
>> +         * table and add reserved memory regions to efi config table. 
>> Current
>> +         * reserved memory region may have reserved region which was 
>> not yet
>> +         * used, release note of the firmware have such kind of 
>> information.
> 
> This is a lot of implementation detail about UEFI, I'd imagine that 
> anyone curious can go read the relevant docs instead. It's a lot of 
> words just to say "Firmware regions which the kernel doesn't need to 
> know about which are not included in the EFI provided memory map."


The following update will be applied to this point:

1. Firmware related regions which aren't shared with kernel.
      Firmware regions which the kernel doesn't need to know about which 
are not included in the EFI provided memory map.


>> +         * 2. Firmware related memory regions which are shared with 
>> Kernel
>> +         *     The device tree source in the kernel needs to include 
>> nodes
>> +         * that indicate fimware-related shared information. A label 
>> name
>> +         * is suggested because this type of shared information needs to
>> +         * be referenced by specific drivers for handling purposes.
> 
> "Firmware regions the kernel DOES need to know about, which are 
> described in the reserved-memory node".

The following update will be applied to this point:

2. Firmware related memory regions which are shared with Kernel

Firmware regions the kernel does need to know about, which are described 
in the reserved-memory node.

>> +         *     Unlike previous platforms, QCS8550 boots using EFI and 
>> describes
>> +         * most reserved regions in the ESRT memory map. As a result, 
>> reserved
>> +         * memory regions which aren't relevant to the kernel(like 
>> the hypervisor
>> +         ( region) don't need to be described in DT.
> 
> These would fall under (1) "firmware the kernel doesn't need to know about"

This will be removed from its current position.

>> +         * 3. Remoteproc regions.
>> +         *     Remoteproc regions will be reserved and then assigned to
>> +         * subsystem firmware later.
> 
> How do these differ from those described in (2)?

This point will do the following update:

3. Remoteproc regions

    Remoteproc regions will be reserved and then assigned to subsystem 
firmware later.

    Remoteproc regions can be loaded either in a fixed form or in a 
relocatable form, depending on the platform.

> 
> I think this comment is trying to describe too much at once. You're 
> trying to describe what the different types of reserved memory are, how 
> the kernel learns about them, and how this differs from previous 
> platforms all at once. I think you should tackle these points separately:
> 
> First describe the types of reserved memory and how the kernel learns 
> about them (my suggestions above). Then describe the differences with 
> previous platforms (like the hypervisor example)
> 
> Thanks and regards,

Your previous suggestion will be incorporated here as follows:

Unlike previous platforms, QCS8550 boots using EFI and describes most 
reserved regions in the ESRT memory map. As a result, reserved memory 
regions which aren't relevant to the kernel(like the hypervisor region) 
don't need to be described in DT.

Is it reasonable to place it here?

Thanks!

>> +         * Here is a reserved memory map for this platform:
>> +         *  0x80000000 +-------------------+
>> +         *             |                   |
>> +         *             | Firmware Related  |
>> +         *             |                   |
>> +         *  0x8a800000 +-------------------+
>> +         *             |                   |
>> +         *             | Remoteproc Region |
>> +         *             |                   |
>> +         *  0xa7000000 +-------------------+
>> +         *             |                   |
>> +         *             | Kernel Available  |
>> +         *             |                   |
>> +         *  0xd4d00000 +-------------------+
>> +         *             |                   |
>> +         *             | Firmware Related  |
>> +         *             |                   |
>> +         * 0x100000000 +-------------------+
>> +         */
>> +
>> +        aop_image_mem: aop-image-region@81c00000 {
>> +            reg = <0x0 0x81c00000 0x0 0x60000>;
>> +            no-map;
>> +        };
>> +
>> +        aop_cmd_db_mem: aop-cmd-db-region@81c60000 {
>> +            compatible = "qcom,cmd-db";
>> +            reg = <0x0 0x81c60000 0x0 0x20000>;
>> +            no-map;
>> +        };
>> +
>> +        aop_config_mem: aop-config-region@81c80000 {
>> +            no-map;
>> +            reg = <0x0 0x81c80000 0x0 0x20000>;
>> +        };
>> +
>> +        smem_mem: smem-region@81d00000 {
>> +            compatible = "qcom,smem";
>> +            reg = <0x0 0x81d00000 0x0 0x200000>;
>> +            hwlocks = <&tcsr_mutex 3>;
>> +            no-map;
>> +        };
>> +
>> +        adsp_mhi_mem: adsp-mhi-region@81f00000 {
>> +            reg = <0x0 0x81f00000 0x0 0x20000>;
>> +            no-map;
>> +        };
>> +
>> +        mpss_mem: mpss-region@8a800000 {
>> +            reg = <0x0 0x8a800000 0x0 0x10800000>;
>> +            no-map;
>> +        };
>> +
>> +        q6_mpss_dtb_mem: q6-mpss-dtb-region@9b000000 {
>> +            reg = <0x0 0x9b000000 0x0 0x80000>;
>> +            no-map;
>> +        };
>> +
>> +        ipa_fw_mem: ipa-fw-region@9b080000 {
>> +            reg = <0x0 0x9b080000 0x0 0x10000>;
>> +            no-map;
>> +        };
>> +
>> +        ipa_gsi_mem: ipa-gsi-region@9b090000 {
>> +            reg = <0x0 0x9b090000 0x0 0xa000>;
>> +            no-map;
>> +        };
>> +
>> +        gpu_micro_code_mem: gpu-micro-code-region@9b09a000 {
>> +            reg = <0x0 0x9b09a000 0x0 0x2000>;
>> +            no-map;
>> +        };
>> +
>> +        spss_region_mem: spss-region@9b100000 {
>> +            reg = <0x0 0x9b100000 0x0 0x180000>;
>> +            no-map;
>> +        };
>> +
>> +        spu_secure_shared_memory_mem: 
>> spu-secure-shared-memory-region@9b280000 {
>> +            reg = <0x0 0x9b280000 0x0 0x80000>;
>> +            no-map;
>> +        };
>> +
>> +        camera_mem: camera-region@9b300000 {
>> +            reg = <0x0 0x9b300000 0x0 0x800000>;
>> +            no-map;
>> +        };
>> +
>> +        video_mem: video-region@9bb00000 {
>> +            reg = <0x0 0x9bb00000 0x0 0x700000>;
>> +            no-map;
>> +        };
>> +
>> +        cvp_mem: cvp-region@9c200000 {
>> +            reg = <0x0 0x9c200000 0x0 0x700000>;
>> +            no-map;
>> +        };
>> +
>> +        cdsp_mem: cdsp-region@9c900000 {
>> +            reg = <0x0 0x9c900000 0x0 0x2000000>;
>> +            no-map;
>> +        };
>> +
>> +        q6_cdsp_dtb_mem: q6-cdsp-dtb-region@9e900000 {
>> +            reg = <0x0 0x9e900000 0x0 0x80000>;
>> +            no-map;
>> +        };
>> +
>> +        q6_adsp_dtb_mem: q6-adsp-dtb-region@9e980000 {
>> +            reg = <0x0 0x9e980000 0x0 0x80000>;
>> +            no-map;
>> +        };
>> +
>> +        adspslpi_mem: adspslpi-region@9ea00000 {
>> +            reg = <0x0 0x9ea00000 0x0 0x4080000>;
>> +            no-map;
>> +        };
>> +
>> +        mpss_dsm_mem: mpss_dsm_region@d4d00000 {
>> +            reg = <0x0 0xd4d00000 0x0 0x3300000>;
>> +            no-map;
>> +        };
>> +    };
>> +};
> 

-- 
Thx and BRs,
Tengfei Fan

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi
  2024-06-20 13:40     ` Tengfei Fan
@ 2024-06-20 13:49       ` Caleb Connolly
  2024-06-21  1:12         ` Tengfei Fan
  0 siblings, 1 reply; 16+ messages in thread
From: Caleb Connolly @ 2024-06-20 13:49 UTC (permalink / raw)
  To: Tengfei Fan, andersson, konrad.dybcio, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel



On 20/06/2024 15:40, Tengfei Fan wrote:
> 
> 
> On 6/18/2024 6:06 PM, Caleb Connolly wrote:
>> HI Tengfei,
>>
>> On 18/06/2024 09:22, Tengfei Fan wrote:
>>> QCS8550 is derived from SM8550. The difference between SM8550 and
>>> QCS8550 is QCS8550 doesn't have modem RF system. QCS8550 is mainly used
>>> in IoT products.
>>> QCS8550 firmware has different memory map compared to SM8550.
>>> The memory map will be runtime added through bootloader.
>>> There are 3 types of reserved memory regions here:
>>> 1. Firmware related regions which aren't shared with kernel.
>>>      The device tree source in kernel doesn't need to have node to 
>>> indicate
>>> the firmware related reserved information. Bootloader converys the
>>> information by updating devicetree at runtime.
>>>      This will be described as: UEFI saves the physical address of the
>>> UEFI System Table to dts file's chosen node. Kernel read this table and
>>> add reserved memory regions to efi config table. Current reserved memory
>>> region may have reserved region which was not yet used, release note of
>>> the firmware have such kind of information.
>>> 2. Firmware related memory regions which are shared with Kernel
>>>      The device tree source in the kernel needs to include nodes that
>>> indicate fimware-related shared information. A label name is suggested
>>> because this type of shared information needs to be referenced by
>>> specific drivers for handling purposes.
>>>      Unlike previous platforms, QCS8550 boots using EFI and describes
>>> most reserved regions in the ESRT memory map. As a result, reserved
>>> memory regions which aren't relevant to the kernel(like the hypervisor
>>> region) don't need to be described in DT.
>>> 3. Remoteproc regions.
>>>      Remoteproc regions will be reserved and then assigned to subsystem
>>> firmware later.
>>> Here is a reserved memory map for this platform:
>>>   0x80000000 +-------------------+
>>>              |                   |
>>>              | Firmware Related  |
>>>              |                   |
>>>   0x8a800000 +-------------------+
>>>              |                   |
>>>              | Remoteproc Region |
>>>              |                   |
>>>   0xa7000000 +-------------------+
>>>              |                   |
>>>              | Kernel Available  |
>>>              |                   |
>>>   0xd4d00000 +-------------------+
>>>              |                   |
>>>              | Firmware Related  |
>>>              |                   |
>>> 0x100000000 +-------------------+
>>>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
>>> ---
>>>   arch/arm64/boot/dts/qcom/qcs8550.dtsi | 162 ++++++++++++++++++++++++++
>>>   1 file changed, 162 insertions(+)
>>>   create mode 100644 arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/qcs8550.dtsi 
>>> b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>> new file mode 100644
>>> index 000000000000..07b314834d88
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>> @@ -0,0 +1,162 @@
>>> +// SPDX-License-Identifier: BSD-3-Clause
>>> +/*
>>> + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All 
>>> rights reserved.
>>> + */
>>> +
>>> +#include "sm8550.dtsi"
>>> +
>>> +/delete-node/ &reserved_memory;
>>> +
>>> +/ {
>>> +    reserved_memory: reserved-memory {
>>> +        #address-cells = <2>;
>>> +        #size-cells = <2>;
>>> +        ranges;
>>> +
>>> +
>>> +        /* These are 3 types of reserved memory regions here:
>>> +         * 1. Firmware related regions which aren't shared with kernel.
>>> +         *     The device tree source in kernel doesn't need to have 
>>> node to
>>> +         * indicate the firmware related reserved information. 
>>> Bootloader
>>> +         * conveys the information by updating devicetree at runtime.
>>> +         *     This will be described as: UEFI saves the physical 
>>> address of
>>> +         * the UEFI System Table to dts file's chosen node. Kernel 
>>> read this
>>> +         * table and add reserved memory regions to efi config 
>>> table. Current
>>> +         * reserved memory region may have reserved region which was 
>>> not yet
>>> +         * used, release note of the firmware have such kind of 
>>> information.
>>
>> This is a lot of implementation detail about UEFI, I'd imagine that 
>> anyone curious can go read the relevant docs instead. It's a lot of 
>> words just to say "Firmware regions which the kernel doesn't need to 
>> know about which are not included in the EFI provided memory map."
> 
> 
> The following update will be applied to this point:
> 
> 1. Firmware related regions which aren't shared with kernel.
>       Firmware regions which the kernel doesn't need to know about which 
> are not included in the EFI provided memory map.
> 
> 
>>> +         * 2. Firmware related memory regions which are shared with 
>>> Kernel
>>> +         *     The device tree source in the kernel needs to include 
>>> nodes
>>> +         * that indicate fimware-related shared information. A label 
>>> name
>>> +         * is suggested because this type of shared information 
>>> needs to
>>> +         * be referenced by specific drivers for handling purposes.
>>
>> "Firmware regions the kernel DOES need to know about, which are 
>> described in the reserved-memory node".
> 
> The following update will be applied to this point:
> 
> 2. Firmware related memory regions which are shared with Kernel
> 
> Firmware regions the kernel does need to know about, which are described 
> in the reserved-memory node.
> 
>>> +         *     Unlike previous platforms, QCS8550 boots using EFI 
>>> and describes
>>> +         * most reserved regions in the ESRT memory map. As a 
>>> result, reserved
>>> +         * memory regions which aren't relevant to the kernel(like 
>>> the hypervisor
>>> +         ( region) don't need to be described in DT.
>>
>> These would fall under (1) "firmware the kernel doesn't need to know 
>> about"
> 
> This will be removed from its current position.
> 
>>> +         * 3. Remoteproc regions.
>>> +         *     Remoteproc regions will be reserved and then assigned to
>>> +         * subsystem firmware later.
>>
>> How do these differ from those described in (2)?
> 
> This point will do the following update:
> 
> 3. Remoteproc regions
> 
>     Remoteproc regions will be reserved and then assigned to subsystem 
> firmware later.
> 
>     Remoteproc regions can be loaded either in a fixed form or in a 
> relocatable form, depending on the platform.
> 
>>
>> I think this comment is trying to describe too much at once. You're 
>> trying to describe what the different types of reserved memory are, 
>> how the kernel learns about them, and how this differs from previous 
>> platforms all at once. I think you should tackle these points separately:
>>
>> First describe the types of reserved memory and how the kernel learns 
>> about them (my suggestions above). Then describe the differences with 
>> previous platforms (like the hypervisor example)
>>
>> Thanks and regards,
> 
> Your previous suggestion will be incorporated here as follows:
> 
> Unlike previous platforms, QCS8550 boots using EFI and describes most 
> reserved regions in the ESRT memory map. As a result, reserved memory 
> regions which aren't relevant to the kernel(like the hypervisor region) 
> don't need to be described in DT.
> 
> Is it reasonable to place it here?

Thanks great, thanks a lot :)
> 
> Thanks!
> 
>>> +         * Here is a reserved memory map for this platform:
>>> +         *  0x80000000 +-------------------+
>>> +         *             |                   |
>>> +         *             | Firmware Related  |
>>> +         *             |                   |
>>> +         *  0x8a800000 +-------------------+
>>> +         *             |                   |
>>> +         *             | Remoteproc Region |
>>> +         *             |                   |
>>> +         *  0xa7000000 +-------------------+
>>> +         *             |                   |
>>> +         *             | Kernel Available  |
>>> +         *             |                   |
>>> +         *  0xd4d00000 +-------------------+
>>> +         *             |                   |
>>> +         *             | Firmware Related  |
>>> +         *             |                   |
>>> +         * 0x100000000 +-------------------+
>>> +         */
>>> +
>>> +        aop_image_mem: aop-image-region@81c00000 {
>>> +            reg = <0x0 0x81c00000 0x0 0x60000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        aop_cmd_db_mem: aop-cmd-db-region@81c60000 {
>>> +            compatible = "qcom,cmd-db";
>>> +            reg = <0x0 0x81c60000 0x0 0x20000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        aop_config_mem: aop-config-region@81c80000 {
>>> +            no-map;
>>> +            reg = <0x0 0x81c80000 0x0 0x20000>;
>>> +        };
>>> +
>>> +        smem_mem: smem-region@81d00000 {
>>> +            compatible = "qcom,smem";
>>> +            reg = <0x0 0x81d00000 0x0 0x200000>;
>>> +            hwlocks = <&tcsr_mutex 3>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        adsp_mhi_mem: adsp-mhi-region@81f00000 {
>>> +            reg = <0x0 0x81f00000 0x0 0x20000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        mpss_mem: mpss-region@8a800000 {
>>> +            reg = <0x0 0x8a800000 0x0 0x10800000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        q6_mpss_dtb_mem: q6-mpss-dtb-region@9b000000 {
>>> +            reg = <0x0 0x9b000000 0x0 0x80000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        ipa_fw_mem: ipa-fw-region@9b080000 {
>>> +            reg = <0x0 0x9b080000 0x0 0x10000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        ipa_gsi_mem: ipa-gsi-region@9b090000 {
>>> +            reg = <0x0 0x9b090000 0x0 0xa000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        gpu_micro_code_mem: gpu-micro-code-region@9b09a000 {
>>> +            reg = <0x0 0x9b09a000 0x0 0x2000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        spss_region_mem: spss-region@9b100000 {
>>> +            reg = <0x0 0x9b100000 0x0 0x180000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        spu_secure_shared_memory_mem: 
>>> spu-secure-shared-memory-region@9b280000 {
>>> +            reg = <0x0 0x9b280000 0x0 0x80000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        camera_mem: camera-region@9b300000 {
>>> +            reg = <0x0 0x9b300000 0x0 0x800000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        video_mem: video-region@9bb00000 {
>>> +            reg = <0x0 0x9bb00000 0x0 0x700000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        cvp_mem: cvp-region@9c200000 {
>>> +            reg = <0x0 0x9c200000 0x0 0x700000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        cdsp_mem: cdsp-region@9c900000 {
>>> +            reg = <0x0 0x9c900000 0x0 0x2000000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        q6_cdsp_dtb_mem: q6-cdsp-dtb-region@9e900000 {
>>> +            reg = <0x0 0x9e900000 0x0 0x80000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        q6_adsp_dtb_mem: q6-adsp-dtb-region@9e980000 {
>>> +            reg = <0x0 0x9e980000 0x0 0x80000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        adspslpi_mem: adspslpi-region@9ea00000 {
>>> +            reg = <0x0 0x9ea00000 0x0 0x4080000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        mpss_dsm_mem: mpss_dsm_region@d4d00000 {
>>> +            reg = <0x0 0xd4d00000 0x0 0x3300000>;
>>> +            no-map;
>>> +        };
>>> +    };
>>> +};
>>
> 

-- 
// Caleb (they/them)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi
  2024-06-20 13:49       ` Caleb Connolly
@ 2024-06-21  1:12         ` Tengfei Fan
  0 siblings, 0 replies; 16+ messages in thread
From: Tengfei Fan @ 2024-06-21  1:12 UTC (permalink / raw)
  To: Caleb Connolly, andersson, konrad.dybcio, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel



On 6/20/2024 9:49 PM, Caleb Connolly wrote:
> 
> 
> On 20/06/2024 15:40, Tengfei Fan wrote:
>>
>>
>> On 6/18/2024 6:06 PM, Caleb Connolly wrote:
>>> HI Tengfei,
>>>
>>> On 18/06/2024 09:22, Tengfei Fan wrote:
>>>> QCS8550 is derived from SM8550. The difference between SM8550 and
>>>> QCS8550 is QCS8550 doesn't have modem RF system. QCS8550 is mainly used
>>>> in IoT products.
>>>> QCS8550 firmware has different memory map compared to SM8550.
>>>> The memory map will be runtime added through bootloader.
>>>> There are 3 types of reserved memory regions here:
>>>> 1. Firmware related regions which aren't shared with kernel.
>>>>      The device tree source in kernel doesn't need to have node to 
>>>> indicate
>>>> the firmware related reserved information. Bootloader converys the
>>>> information by updating devicetree at runtime.
>>>>      This will be described as: UEFI saves the physical address of the
>>>> UEFI System Table to dts file's chosen node. Kernel read this table and
>>>> add reserved memory regions to efi config table. Current reserved 
>>>> memory
>>>> region may have reserved region which was not yet used, release note of
>>>> the firmware have such kind of information.
>>>> 2. Firmware related memory regions which are shared with Kernel
>>>>      The device tree source in the kernel needs to include nodes that
>>>> indicate fimware-related shared information. A label name is suggested
>>>> because this type of shared information needs to be referenced by
>>>> specific drivers for handling purposes.
>>>>      Unlike previous platforms, QCS8550 boots using EFI and describes
>>>> most reserved regions in the ESRT memory map. As a result, reserved
>>>> memory regions which aren't relevant to the kernel(like the hypervisor
>>>> region) don't need to be described in DT.
>>>> 3. Remoteproc regions.
>>>>      Remoteproc regions will be reserved and then assigned to subsystem
>>>> firmware later.
>>>> Here is a reserved memory map for this platform:
>>>>   0x80000000 +-------------------+
>>>>              |                   |
>>>>              | Firmware Related  |
>>>>              |                   |
>>>>   0x8a800000 +-------------------+
>>>>              |                   |
>>>>              | Remoteproc Region |
>>>>              |                   |
>>>>   0xa7000000 +-------------------+
>>>>              |                   |
>>>>              | Kernel Available  |
>>>>              |                   |
>>>>   0xd4d00000 +-------------------+
>>>>              |                   |
>>>>              | Firmware Related  |
>>>>              |                   |
>>>> 0x100000000 +-------------------+
>>>>
>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
>>>> ---
>>>>   arch/arm64/boot/dts/qcom/qcs8550.dtsi | 162 
>>>> ++++++++++++++++++++++++++
>>>>   1 file changed, 162 insertions(+)
>>>>   create mode 100644 arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/qcs8550.dtsi 
>>>> b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>>> new file mode 100644
>>>> index 000000000000..07b314834d88
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>>> @@ -0,0 +1,162 @@
>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>> +/*
>>>> + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All 
>>>> rights reserved.
>>>> + */
>>>> +
>>>> +#include "sm8550.dtsi"
>>>> +
>>>> +/delete-node/ &reserved_memory;
>>>> +
>>>> +/ {
>>>> +    reserved_memory: reserved-memory {
>>>> +        #address-cells = <2>;
>>>> +        #size-cells = <2>;
>>>> +        ranges;
>>>> +
>>>> +
>>>> +        /* These are 3 types of reserved memory regions here:
>>>> +         * 1. Firmware related regions which aren't shared with 
>>>> kernel.
>>>> +         *     The device tree source in kernel doesn't need to 
>>>> have node to
>>>> +         * indicate the firmware related reserved information. 
>>>> Bootloader
>>>> +         * conveys the information by updating devicetree at runtime.
>>>> +         *     This will be described as: UEFI saves the physical 
>>>> address of
>>>> +         * the UEFI System Table to dts file's chosen node. Kernel 
>>>> read this
>>>> +         * table and add reserved memory regions to efi config 
>>>> table. Current
>>>> +         * reserved memory region may have reserved region which 
>>>> was not yet
>>>> +         * used, release note of the firmware have such kind of 
>>>> information.
>>>
>>> This is a lot of implementation detail about UEFI, I'd imagine that 
>>> anyone curious can go read the relevant docs instead. It's a lot of 
>>> words just to say "Firmware regions which the kernel doesn't need to 
>>> know about which are not included in the EFI provided memory map."
>>
>>
>> The following update will be applied to this point:
>>
>> 1. Firmware related regions which aren't shared with kernel.
>>       Firmware regions which the kernel doesn't need to know about 
>> which are not included in the EFI provided memory map.
>>
>>
>>>> +         * 2. Firmware related memory regions which are shared with 
>>>> Kernel
>>>> +         *     The device tree source in the kernel needs to 
>>>> include nodes
>>>> +         * that indicate fimware-related shared information. A 
>>>> label name
>>>> +         * is suggested because this type of shared information 
>>>> needs to
>>>> +         * be referenced by specific drivers for handling purposes.
>>>
>>> "Firmware regions the kernel DOES need to know about, which are 
>>> described in the reserved-memory node".
>>
>> The following update will be applied to this point:
>>
>> 2. Firmware related memory regions which are shared with Kernel
>>
>> Firmware regions the kernel does need to know about, which are 
>> described in the reserved-memory node.
>>
>>>> +         *     Unlike previous platforms, QCS8550 boots using EFI 
>>>> and describes
>>>> +         * most reserved regions in the ESRT memory map. As a 
>>>> result, reserved
>>>> +         * memory regions which aren't relevant to the kernel(like 
>>>> the hypervisor
>>>> +         ( region) don't need to be described in DT.
>>>
>>> These would fall under (1) "firmware the kernel doesn't need to know 
>>> about"
>>
>> This will be removed from its current position.
>>
>>>> +         * 3. Remoteproc regions.
>>>> +         *     Remoteproc regions will be reserved and then 
>>>> assigned to
>>>> +         * subsystem firmware later.
>>>
>>> How do these differ from those described in (2)?
>>
>> This point will do the following update:
>>
>> 3. Remoteproc regions
>>
>>     Remoteproc regions will be reserved and then assigned to subsystem 
>> firmware later.
>>
>>     Remoteproc regions can be loaded either in a fixed form or in a 
>> relocatable form, depending on the platform.
>>
>>>
>>> I think this comment is trying to describe too much at once. You're 
>>> trying to describe what the different types of reserved memory are, 
>>> how the kernel learns about them, and how this differs from previous 
>>> platforms all at once. I think you should tackle these points 
>>> separately:
>>>
>>> First describe the types of reserved memory and how the kernel learns 
>>> about them (my suggestions above). Then describe the differences with 
>>> previous platforms (like the hypervisor example)
>>>
>>> Thanks and regards,
>>
>> Your previous suggestion will be incorporated here as follows:
>>
>> Unlike previous platforms, QCS8550 boots using EFI and describes most 
>> reserved regions in the ESRT memory map. As a result, reserved memory 
>> regions which aren't relevant to the kernel(like the hypervisor 
>> region) don't need to be described in DT.
>>
>> Is it reasonable to place it here?
> 
> Thanks great, thanks a lot :)

Thank you for reviewing this patch series in detail!

>>
>> Thanks!
>>
>>>> +         * Here is a reserved memory map for this platform:
>>>> +         *  0x80000000 +-------------------+
>>>> +         *             |                   |
>>>> +         *             | Firmware Related  |
>>>> +         *             |                   |
>>>> +         *  0x8a800000 +-------------------+
>>>> +         *             |                   |
>>>> +         *             | Remoteproc Region |
>>>> +         *             |                   |
>>>> +         *  0xa7000000 +-------------------+
>>>> +         *             |                   |
>>>> +         *             | Kernel Available  |
>>>> +         *             |                   |
>>>> +         *  0xd4d00000 +-------------------+
>>>> +         *             |                   |
>>>> +         *             | Firmware Related  |
>>>> +         *             |                   |
>>>> +         * 0x100000000 +-------------------+
>>>> +         */
>>>> +
>>>> +        aop_image_mem: aop-image-region@81c00000 {
>>>> +            reg = <0x0 0x81c00000 0x0 0x60000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        aop_cmd_db_mem: aop-cmd-db-region@81c60000 {
>>>> +            compatible = "qcom,cmd-db";
>>>> +            reg = <0x0 0x81c60000 0x0 0x20000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        aop_config_mem: aop-config-region@81c80000 {
>>>> +            no-map;
>>>> +            reg = <0x0 0x81c80000 0x0 0x20000>;
>>>> +        };
>>>> +
>>>> +        smem_mem: smem-region@81d00000 {
>>>> +            compatible = "qcom,smem";
>>>> +            reg = <0x0 0x81d00000 0x0 0x200000>;
>>>> +            hwlocks = <&tcsr_mutex 3>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        adsp_mhi_mem: adsp-mhi-region@81f00000 {
>>>> +            reg = <0x0 0x81f00000 0x0 0x20000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        mpss_mem: mpss-region@8a800000 {
>>>> +            reg = <0x0 0x8a800000 0x0 0x10800000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        q6_mpss_dtb_mem: q6-mpss-dtb-region@9b000000 {
>>>> +            reg = <0x0 0x9b000000 0x0 0x80000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        ipa_fw_mem: ipa-fw-region@9b080000 {
>>>> +            reg = <0x0 0x9b080000 0x0 0x10000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        ipa_gsi_mem: ipa-gsi-region@9b090000 {
>>>> +            reg = <0x0 0x9b090000 0x0 0xa000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        gpu_micro_code_mem: gpu-micro-code-region@9b09a000 {
>>>> +            reg = <0x0 0x9b09a000 0x0 0x2000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        spss_region_mem: spss-region@9b100000 {
>>>> +            reg = <0x0 0x9b100000 0x0 0x180000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        spu_secure_shared_memory_mem: 
>>>> spu-secure-shared-memory-region@9b280000 {
>>>> +            reg = <0x0 0x9b280000 0x0 0x80000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        camera_mem: camera-region@9b300000 {
>>>> +            reg = <0x0 0x9b300000 0x0 0x800000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        video_mem: video-region@9bb00000 {
>>>> +            reg = <0x0 0x9bb00000 0x0 0x700000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        cvp_mem: cvp-region@9c200000 {
>>>> +            reg = <0x0 0x9c200000 0x0 0x700000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        cdsp_mem: cdsp-region@9c900000 {
>>>> +            reg = <0x0 0x9c900000 0x0 0x2000000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        q6_cdsp_dtb_mem: q6-cdsp-dtb-region@9e900000 {
>>>> +            reg = <0x0 0x9e900000 0x0 0x80000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        q6_adsp_dtb_mem: q6-adsp-dtb-region@9e980000 {
>>>> +            reg = <0x0 0x9e980000 0x0 0x80000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        adspslpi_mem: adspslpi-region@9ea00000 {
>>>> +            reg = <0x0 0x9ea00000 0x0 0x4080000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        mpss_dsm_mem: mpss_dsm_region@d4d00000 {
>>>> +            reg = <0x0 0xd4d00000 0x0 0x3300000>;
>>>> +            no-map;
>>>> +        };
>>>> +    };
>>>> +};
>>>
>>
> 

-- 
Thx and BRs,
Tengfei Fan

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 0/4] arm64: dts: qcom: aim300: add AIM300 AIoT
  2024-06-18  7:21 [PATCH v10 0/4] arm64: dts: qcom: aim300: add AIM300 AIoT Tengfei Fan
                   ` (3 preceding siblings ...)
  2024-06-18  7:22 ` [PATCH v10 4/4] arm64: dts: qcom: aim300: add AIM300 AIoT Tengfei Fan
@ 2024-06-21  6:11 ` Bjorn Andersson
  4 siblings, 0 replies; 16+ messages in thread
From: Bjorn Andersson @ 2024-06-21  6:11 UTC (permalink / raw)
  To: konrad.dybcio, robh, krzk+dt, conor+dt, dmitry.baryshkov,
	Tengfei Fan
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel


On Tue, 18 Jun 2024 15:21:58 +0800, Tengfei Fan wrote:
> Add AIM300 AIoT support along with usb, ufs, regulators, serial, PCIe,
> and PMIC functions.
> AIM300 Series is a highly optimized family of modules designed to
> support AIoT applications. It integrates QCS8550 SoC, UFS and PMIC
> chip etc.
> Here is a diagram of AIM300 AIoT Carrie Board and SoM
>  +--------------------------------------------------+
>  |             AIM300 AIOT Carrier Board            |
>  |                                                  |
>  |           +-----------------+                    |
>  |power----->| Fixed regulator |---------+          |
>  |           +-----------------+         |          |
>  |                                       |          |
>  |                                       v VPH_PWR  |
>  | +----------------------------------------------+ |
>  | |                          AIM300 SOM |        | |
>  | |                                     |VPH_PWR | |
>  | |                                     v        | |
>  | |   +-------+       +--------+     +------+    | |
>  | |   | UFS   |       | QCS8550|     |PMIC  |    | |
>  | |   +-------+       +--------+     +------+    | |
>  | |                                              | |
>  | +----------------------------------------------+ |
>  |                                                  |
>  |                    +----+          +------+      |
>  |                    |USB |          | UART |      |
>  |                    +----+          +------+      |
>  +--------------------------------------------------+
> The following functions have been verified:
>   - uart
>   - usb
>   - ufs
>   - PCIe
>   - PMIC
>   - display
>   - adsp
>   - cdsp
>   - tlmm
> 
> [...]

Applied, thanks!

[1/4] dt-bindings: arm: qcom: Document QCS8550 SoC and the AIM300 AIoT board
      commit: 6d97b93acf9d0b29d3eddf38186d9556e5360368
[2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi
      commit: bb8a2dc3bd89628a7f4aac577894d47dd0f4db3c
[3/4] arm64: dts: qcom: add base AIM300 dtsi
      commit: 0b12da4e28d8f6ecb492c98313e325eff11b5bb8
[4/4] arm64: dts: qcom: aim300: add AIM300 AIoT
      commit: e7931a52c7b68fb5143e118778092a23cfc5b0fc

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 3/4] arm64: dts: qcom: add base AIM300 dtsi
  2024-06-20  0:46     ` Tengfei Fan
@ 2024-06-22 11:09       ` Konrad Dybcio
  2024-06-24  2:22         ` Tengfei Fan
  0 siblings, 1 reply; 16+ messages in thread
From: Konrad Dybcio @ 2024-06-22 11:09 UTC (permalink / raw)
  To: Tengfei Fan, andersson, robh, krzk+dt, conor+dt, dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Fenglin Wu

On 20.06.2024 2:46 AM, Tengfei Fan wrote:
> 
> 
> On 6/19/2024 3:06 AM, Konrad Dybcio wrote:
>>
>>
>> On 6/18/24 09:22, Tengfei Fan wrote:
>>> AIM300 Series is a highly optimized family of modules designed to
>>> support AIoT applications. It integrates QCS8550 SoC, UFS and PMIC
>>> chip etc.
>>> Here is a diagram of AIM300 SoM:
>>>            +----------------------------------------+
>>>            |AIM300 SoM                              |
>>>            |                                        |
>>>            |                           +-----+      |
>>>            |                      |--->| UFS |      |
>>>            |                      |    +-----+      |
>>>            |                      |                 |
>>>            |                      |                 |
>>>       3.7v |  +-----------------+ |    +---------+  |
>>>    ---------->|       PMIC      |----->| QCS8550 |  |
>>>            |  +-----------------+      +---------+  |
>>>            |                      |                 |
>>>            |                      |                 |
>>>            |                      |    +-----+      |
>>>            |                      |--->| ... |      |
>>>            |                           +-----+      |
>>>            |                                        |
>>>            +----------------------------------------+
>>>
>>> Co-developed-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
>>> ---
>>
>> [...]
>>
>>> +&ufs_mem_hc {
>>> +    reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
>>> +    vcc-supply = <&vreg_l17b_2p5>;
>>> +    vcc-max-microamp = <1300000>;
>>> +    vccq-supply = <&vreg_l1g_1p2>;
>>> +    vccq-max-microamp = <1200000>;
>>> +    vdd-hba-supply = <&vreg_l3g_1p2>;
>>
>> These regulators should generally have:
>>
>> regulator-allow-set-load;
>> regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
>>                             RPMH_REGULATOR_MODE_HPM>;
>>
>> although the current setup you have never lets them exit HPM
>>
>> Konrad
> 
> I understand your point is that these settings need to be added to allthe child regulator nodes of regulators-0, regulators-1, regulators-2, regulators-3, regulators-4 and regulators-5. Is that correct?

No, I only meant the three references in the UFS node (l17b, l1g, l3g),
although I suppose such properties should be there by default on all
regulators in order to save power.. but most boards don't do that (yet),
as nobody wants to waste their time with potentially one more thing to
debug

Konrad

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v10 3/4] arm64: dts: qcom: add base AIM300 dtsi
  2024-06-22 11:09       ` Konrad Dybcio
@ 2024-06-24  2:22         ` Tengfei Fan
  0 siblings, 0 replies; 16+ messages in thread
From: Tengfei Fan @ 2024-06-24  2:22 UTC (permalink / raw)
  To: Konrad Dybcio, andersson, robh, krzk+dt, conor+dt,
	dmitry.baryshkov
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel, Fenglin Wu



On 6/22/2024 7:09 PM, Konrad Dybcio wrote:
> On 20.06.2024 2:46 AM, Tengfei Fan wrote:
>>
>>
>> On 6/19/2024 3:06 AM, Konrad Dybcio wrote:
>>>
>>>
>>> On 6/18/24 09:22, Tengfei Fan wrote:
>>>> AIM300 Series is a highly optimized family of modules designed to
>>>> support AIoT applications. It integrates QCS8550 SoC, UFS and PMIC
>>>> chip etc.
>>>> Here is a diagram of AIM300 SoM:
>>>>             +----------------------------------------+
>>>>             |AIM300 SoM                              |
>>>>             |                                        |
>>>>             |                           +-----+      |
>>>>             |                      |--->| UFS |      |
>>>>             |                      |    +-----+      |
>>>>             |                      |                 |
>>>>             |                      |                 |
>>>>        3.7v |  +-----------------+ |    +---------+  |
>>>>     ---------->|       PMIC      |----->| QCS8550 |  |
>>>>             |  +-----------------+      +---------+  |
>>>>             |                      |                 |
>>>>             |                      |                 |
>>>>             |                      |    +-----+      |
>>>>             |                      |--->| ... |      |
>>>>             |                           +-----+      |
>>>>             |                                        |
>>>>             +----------------------------------------+
>>>>
>>>> Co-developed-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> +&ufs_mem_hc {
>>>> +    reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
>>>> +    vcc-supply = <&vreg_l17b_2p5>;
>>>> +    vcc-max-microamp = <1300000>;
>>>> +    vccq-supply = <&vreg_l1g_1p2>;
>>>> +    vccq-max-microamp = <1200000>;
>>>> +    vdd-hba-supply = <&vreg_l3g_1p2>;
>>>
>>> These regulators should generally have:
>>>
>>> regulator-allow-set-load;
>>> regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
>>>                              RPMH_REGULATOR_MODE_HPM>;
>>>
>>> although the current setup you have never lets them exit HPM
>>>
>>> Konrad
>>
>> I understand your point is that these settings need to be added to allthe child regulator nodes of regulators-0, regulators-1, regulators-2, regulators-3, regulators-4 and regulators-5. Is that correct?
> 
> No, I only meant the three references in the UFS node (l17b, l1g, l3g),
> although I suppose such properties should be there by default on all
> regulators in order to save power.. but most boards don't do that (yet),
> as nobody wants to waste their time with potentially one more thing to
> debug

Thank you for clarifying this. I will create a new patch to support 
these since this patch series have already been applied.

> 
> Konrad

-- 
Thx and BRs,
Tengfei Fan

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2024-06-24  2:22 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-18  7:21 [PATCH v10 0/4] arm64: dts: qcom: aim300: add AIM300 AIoT Tengfei Fan
2024-06-18  7:21 ` [PATCH v10 1/4] dt-bindings: arm: qcom: Document QCS8550 SoC and the AIM300 AIoT board Tengfei Fan
2024-06-18  7:22 ` [PATCH v10 2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi Tengfei Fan
2024-06-18 10:06   ` Caleb Connolly
2024-06-20 13:40     ` Tengfei Fan
2024-06-20 13:49       ` Caleb Connolly
2024-06-21  1:12         ` Tengfei Fan
2024-06-18  7:22 ` [PATCH v10 3/4] arm64: dts: qcom: add base AIM300 dtsi Tengfei Fan
2024-06-18 19:06   ` Konrad Dybcio
2024-06-20  0:46     ` Tengfei Fan
2024-06-22 11:09       ` Konrad Dybcio
2024-06-24  2:22         ` Tengfei Fan
2024-06-18  7:22 ` [PATCH v10 4/4] arm64: dts: qcom: aim300: add AIM300 AIoT Tengfei Fan
2024-06-18  8:48   ` Dmitry Baryshkov
2024-06-18  8:57     ` Tengfei Fan
2024-06-21  6:11 ` [PATCH v10 0/4] " Bjorn Andersson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).