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 <[email protected]>
---
This patch series depends on patch series:
"[PATCH v2 0/2] arm64: dts: qcom: sm8550: Update some"
https://lore.kernel.org/linux-arm-msm/[email protected]
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/[email protected]
- https://lore.kernel.org/linux-arm-msm/[email protected]
- 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] v8: https://lore.kernel.org/linux-arm-msm/[email protected]
[2] v7: https://lore.kernel.org/linux-arm-msm/[email protected]
[3] v6 RESEND: https://lore.kernel.org/linux-arm-msm/[email protected]
[4] v6: https://lore.kernel.org/linux-arm-msm/[email protected]
[5] v5: https://lore.kernel.org/linux-arm-msm/[email protected]
[6] v4: https://lore.kernel.org/linux-arm-msm/[email protected]
[7] v3: https://lore.kernel.org/linux-arm-msm/[email protected]
[8] v2: https://lore.kernel.org/linux-arm-msm/[email protected]
[9] v1: https://lore.kernel.org/linux-arm-msm/[email protected]
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 | 322 ++++++++++++++
arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi | 405 ++++++++++++++++++
arch/arm64/boot/dts/qcom/qcs8550.dtsi | 167 ++++++++
5 files changed, 903 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: 9d99040b1bc8dbf385a8aa535e9efcdf94466e19
--
2.25.1
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.
3. Remoteproc regions.
Remoteproc regions will be reserved and then assigned to subsystem
firmware later.
Here is a reserved memory map for this platform:
0x100000000 +-------------------+
| |
| Firmware Related |
| |
0xd4d00000 +-------------------+
| |
| Kernel Available |
| |
0xa7000000 +-------------------+
| |
| Remoteproc Region |
| |
0x8a800000 +-------------------+
| |
| Firmware Related |
| |
0x80000000 +-------------------+
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Tengfei Fan <[email protected]>
---
arch/arm64/boot/dts/qcom/qcs8550.dtsi | 167 ++++++++++++++++++++++++++
1 file changed, 167 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..685668c6ad14
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
@@ -0,0 +1,167 @@
+// 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.
+ * 3. Remoteproc regions.
+ * Remoteproc regions will be reserved and then assigned to
+ * subsystem firmware later.
+ * Here is a reserved memory map for this platform:
+ * 0x100000000 +-------------------+
+ * | |
+ * | Firmware Related |
+ * | |
+ * 0xd4d00000 +-------------------+
+ * | |
+ * | Kernel Available |
+ * | |
+ * 0xa7000000 +-------------------+
+ * | |
+ * | Remoteproc Region |
+ * | |
+ * 0x8a800000 +-------------------+
+ * | |
+ * | Firmware Related |
+ * | |
+ * 0x80000000 +-------------------+
+ */
+
+ /*
+ * Firmware related regions, bootloader will possible reserve parts of
+ * region from 0x80000000..0x8a800000.
+ */
+ 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;
+ };
+
+ /* PIL region */
+ 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;
+ };
+
+ /*
+ * Firmware related regions, bootloader will possible reserve parts of
+ * region from 0xd8000000..0x100000000.
+ */
+ mpss_dsm_mem: mpss_dsm_region@d4d00000 {
+ reg = <0x0 0xd4d00000 0x0 0x3300000>;
+ no-map;
+ };
+ };
+};
--
2.25.1
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 <[email protected]>
Signed-off-by: Fenglin Wu <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Tengfei Fan <[email protected]>
---
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
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 <[email protected]>
Signed-off-by: Qiang Yu <[email protected]>
Co-developed-by: Ziyue Zhang <[email protected]>
Signed-off-by: Ziyue Zhang <[email protected]>
Signed-off-by: Tengfei Fan <[email protected]>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++++++
2 files changed, 323 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 99d606a15449..db093c8e4c1e 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -101,6 +101,7 @@ dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp.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..49759274fb4a
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
@@ -0,0 +1,322 @@
+// 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_active>;
+ pinctrl-1 = <&dsi_suspend>, <&te_suspend>;
+ 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.elf";
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/qcs8550/cdsp.mbn",
+ "qcom/qcs8550/cdsp_dtbs.elf";
+ 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_active: te-active-state {
+ pins = "gpio86";
+ function = "mdp_vsync";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ te_suspend: te-suspend-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
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 <[email protected]>
Signed-off-by: Tengfei Fan <[email protected]>
---
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 10ac297b3c2e..3cc129f266f0 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
@@ -1015,6 +1016,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
On Wed, May 29, 2024 at 06:09:26PM +0800, 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 <[email protected]>
> Signed-off-by: Qiang Yu <[email protected]>
> Co-developed-by: Ziyue Zhang <[email protected]>
> Signed-off-by: Ziyue Zhang <[email protected]>
> Signed-off-by: Tengfei Fan <[email protected]>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++++++
> 2 files changed, 323 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
[trimmed]
> +&remoteproc_adsp {
> + firmware-name = "qcom/qcs8550/adsp.mbn",
> + "qcom/qcs8550/adsp_dtbs.elf";
Please excuse me, I think I missed those on the previous run.
adsp_dtb.mbn
> + status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> + firmware-name = "qcom/qcs8550/cdsp.mbn",
> + "qcom/qcs8550/cdsp_dtbs.elf";
cdsp_dtb.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;
> + };
s/dsi/panel[-_]reset/
> +
> + dsi_suspend: dsi-suspend-state {
> + pins = "gpio133";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> + te_active: te-active-state {
> + pins = "gpio86";
> + function = "mdp_vsync";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> + te_suspend: te-suspend-state {
> + pins = "gpio86";
> + function = "mdp_vsync";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
What is the difference between these two?
> +};
--
With best wishes
Dmitry
On 5/29/2024 11:18 PM, Dmitry Baryshkov wrote:
> On Wed, May 29, 2024 at 06:09:26PM +0800, 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 <[email protected]>
>> Signed-off-by: Qiang Yu <[email protected]>
>> Co-developed-by: Ziyue Zhang <[email protected]>
>> Signed-off-by: Ziyue Zhang <[email protected]>
>> Signed-off-by: Tengfei Fan <[email protected]>
>> ---
>> arch/arm64/boot/dts/qcom/Makefile | 1 +
>> .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++++++
>> 2 files changed, 323 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
>
> [trimmed]
>
>> +&remoteproc_adsp {
>> + firmware-name = "qcom/qcs8550/adsp.mbn",
>> + "qcom/qcs8550/adsp_dtbs.elf";
>
> Please excuse me, I think I missed those on the previous run.
>
> adsp_dtb.mbn
Currently, waht we have released is adsp_dtbs.elf. If we modify it to
adsp_dtb.mbn, it may cause the ADSP functionality can not boot normally.
>
>> + status = "okay";
>> +};
>> +
>> +&remoteproc_cdsp {
>> + firmware-name = "qcom/qcs8550/cdsp.mbn",
>> + "qcom/qcs8550/cdsp_dtbs.elf";
>
> cdsp_dtb.mbn
CDSP also as above ADSP.
>
>> + 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;
>> + };
>
> s/dsi/panel[-_]reset/
I will update this (like: "dsi_active" to "panel_resest_active") as your
recommendation.
>
>> +
>> + dsi_suspend: dsi-suspend-state {
>> + pins = "gpio133";
>> + function = "gpio";
>> + drive-strength = <2>;
>> + bias-pull-down;
>> + };
This also do update as "s/dsi/panel[-_]reset/".
>> +
>> + te_active: te-active-state {
>> + pins = "gpio86";
>> + function = "mdp_vsync";
>> + drive-strength = <2>;
>> + bias-pull-down;
>> + };
>> +
>> + te_suspend: te-suspend-state {
>> + pins = "gpio86";
>> + function = "mdp_vsync";
>> + drive-strength = <2>;
>> + bias-pull-down;
>> + };
>
> What is the difference between these two?
TE pin needs to be pulled down for both active and suspend states. There
is no difference.
>
>> +};
>
--
Thx and BRs,
Tengfei Fan
On Fri, 31 May 2024 at 11:35, Tengfei Fan <[email protected]> wrote:
>
>
>
> On 5/29/2024 11:18 PM, Dmitry Baryshkov wrote:
> > On Wed, May 29, 2024 at 06:09:26PM +0800, 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 <[email protected]>
> >> Signed-off-by: Qiang Yu <[email protected]>
> >> Co-developed-by: Ziyue Zhang <[email protected]>
> >> Signed-off-by: Ziyue Zhang <[email protected]>
> >> Signed-off-by: Tengfei Fan <[email protected]>
> >> ---
> >> arch/arm64/boot/dts/qcom/Makefile | 1 +
> >> .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++++++
> >> 2 files changed, 323 insertions(+)
> >> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
> >
> > [trimmed]
> >
> >> +&remoteproc_adsp {
> >> + firmware-name = "qcom/qcs8550/adsp.mbn",
> >> + "qcom/qcs8550/adsp_dtbs.elf";
> >
> > Please excuse me, I think I missed those on the previous run.
> >
> > adsp_dtb.mbn
>
> Currently, waht we have released is adsp_dtbs.elf. If we modify it to
> adsp_dtb.mbn, it may cause the ADSP functionality can not boot normally.
Released where? linux-firmware doesn't have such a file. And the modem
partition most likely has a different path for it anyway.
>
> >
> >> + status = "okay";
> >> +};
> >> +
> >> +&remoteproc_cdsp {
> >> + firmware-name = "qcom/qcs8550/cdsp.mbn",
> >> + "qcom/qcs8550/cdsp_dtbs.elf";
> >
> > cdsp_dtb.mbn
>
> CDSP also as above ADSP.
>
> >
> >> +
> >> + te_active: te-active-state {
> >> + pins = "gpio86";
> >> + function = "mdp_vsync";
> >> + drive-strength = <2>;
> >> + bias-pull-down;
> >> + };
> >> +
> >> + te_suspend: te-suspend-state {
> >> + pins = "gpio86";
> >> + function = "mdp_vsync";
> >> + drive-strength = <2>;
> >> + bias-pull-down;
> >> + };
> >
> > What is the difference between these two?
>
> TE pin needs to be pulled down for both active and suspend states. There
> is no difference.
So why do you need two different states for it?
--
With best wishes
Dmitry
On 5/31/2024 4:38 PM, Dmitry Baryshkov wrote:
> On Fri, 31 May 2024 at 11:35, Tengfei Fan <[email protected]> wrote:
>>
>>
>>
>> On 5/29/2024 11:18 PM, Dmitry Baryshkov wrote:
>>> On Wed, May 29, 2024 at 06:09:26PM +0800, 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 <[email protected]>
>>>> Signed-off-by: Qiang Yu <[email protected]>
>>>> Co-developed-by: Ziyue Zhang <[email protected]>
>>>> Signed-off-by: Ziyue Zhang <[email protected]>
>>>> Signed-off-by: Tengfei Fan <[email protected]>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/Makefile | 1 +
>>>> .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++++++
>>>> 2 files changed, 323 insertions(+)
>>>> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
>>>
>>> [trimmed]
>>>
>>>> +&remoteproc_adsp {
>>>> + firmware-name = "qcom/qcs8550/adsp.mbn",
>>>> + "qcom/qcs8550/adsp_dtbs.elf";
>>>
>>> Please excuse me, I think I missed those on the previous run.
>>>
>>> adsp_dtb.mbn
>>
>> Currently, waht we have released is adsp_dtbs.elf. If we modify it to
>> adsp_dtb.mbn, it may cause the ADSP functionality can not boot normally.
>
> Released where? linux-firmware doesn't have such a file. And the modem
> partition most likely has a different path for it anyway.
Firmware releases can be obtained from
https://qpm-git.qualcomm.com/home2/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git
after users sign up for free accounts on both
https://qpm-git.qualcomm.com and https://chipmaster2.qti.qualcomm.com.
>
>>
>>>
>>>> + status = "okay";
>>>> +};
>>>> +
>>>> +&remoteproc_cdsp {
>>>> + firmware-name = "qcom/qcs8550/cdsp.mbn",
>>>> + "qcom/qcs8550/cdsp_dtbs.elf";
>>>
>>> cdsp_dtb.mbn
>>
>> CDSP also as above ADSP.
>>
>>>
>
>>>> +
>>>> + te_active: te-active-state {
>>>> + pins = "gpio86";
>>>> + function = "mdp_vsync";
>>>> + drive-strength = <2>;
>>>> + bias-pull-down;
>>>> + };
>>>> +
>>>> + te_suspend: te-suspend-state {
>>>> + pins = "gpio86"
>>>> + function = "mdp_vsync";
>>>> + drive-strength = <2>;
>>>> + bias-pull-down;
>>>> + };
>>>
>>> What is the difference between these two?
>>
>> TE pin needs to be pulled down for both active and suspend states. There
>> is no difference.
>
> So why do you need two different states for it?
Dividing into two different states can provide a clearer expression of
whether the corresponging functionality is avtive or suspend.
We can also find similar settings in the other SM8550 and SM8650
platform dts files, such as sm8550-qrd.dts and sm8650-qrd.dts.
[1] sm8550-qrd.dts:
https://elixir.bootlin.com/linux/v6.9.3/source/arch/arm64/boot/dts/qcom/sm8550-qrd.dts#L1052
[2] sm8650-qrd.dts:
https://elixir.bootlin.com/linux/v6.9.3/source/arch/arm64/boot/dts/qcom/sm8650-qrd.dts#L1098
>
>
>
>
>
--
Thx and BRs,
Tengfei Fan
On Mon, 3 Jun 2024 at 10:38, Tengfei Fan <[email protected]> wrote:
>
>
>
> On 5/31/2024 4:38 PM, Dmitry Baryshkov wrote:
> > On Fri, 31 May 2024 at 11:35, Tengfei Fan <[email protected]> wrote:
> >>
> >>
> >>
> >> On 5/29/2024 11:18 PM, Dmitry Baryshkov wrote:
> >>> On Wed, May 29, 2024 at 06:09:26PM +0800, 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 <[email protected]>
> >>>> Signed-off-by: Qiang Yu <[email protected]>
> >>>> Co-developed-by: Ziyue Zhang <[email protected]>
> >>>> Signed-off-by: Ziyue Zhang <[email protected]>
> >>>> Signed-off-by: Tengfei Fan <[email protected]>
> >>>> ---
> >>>> arch/arm64/boot/dts/qcom/Makefile | 1 +
> >>>> .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++++++
> >>>> 2 files changed, 323 insertions(+)
> >>>> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
> >>>
> >>> [trimmed]
> >>>
> >>>> +&remoteproc_adsp {
> >>>> + firmware-name = "qcom/qcs8550/adsp.mbn",
> >>>> + "qcom/qcs8550/adsp_dtbs.elf";
> >>>
> >>> Please excuse me, I think I missed those on the previous run.
> >>>
> >>> adsp_dtb.mbn
> >>
> >> Currently, waht we have released is adsp_dtbs.elf. If we modify it to
> >> adsp_dtb.mbn, it may cause the ADSP functionality can not boot normally.
> >
> > Released where? linux-firmware doesn't have such a file. And the modem
> > partition most likely has a different path for it anyway.
>
> Firmware releases can be obtained from
> https://qpm-git.qualcomm.com/home2/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git
> after users sign up for free accounts on both
> https://qpm-git.qualcomm.com and https://chipmaster2.qti.qualcomm.com.
I'm getting 403 when accessing qpm-git (both with my Linaro
credentials and with gmail ones).
If I try to git-clone the URL you've provided, I'm getting "Not found"
when using a gmail account and CURL error when using Linaro
createntials.
error: RPC failed; HTTP 302 curl 22 The requested URL returned error: 302
Not to mention that the URL wasn't mentioned anywhere beforehand. So I
can hardly call that 'released'
>
> >
> >>
> >>>
> >>>> + status = "okay";
> >>>> +};
> >>>> +
> >>>> +&remoteproc_cdsp {
> >>>> + firmware-name = "qcom/qcs8550/cdsp.mbn",
> >>>> + "qcom/qcs8550/cdsp_dtbs.elf";
> >>>
> >>> cdsp_dtb.mbn
> >>
> >> CDSP also as above ADSP.
> >>
> >>>
> >
> >>>> +
> >>>> + te_active: te-active-state {
> >>>> + pins = "gpio86";
> >>>> + function = "mdp_vsync";
> >>>> + drive-strength = <2>;
> >>>> + bias-pull-down;
> >>>> + };
> >>>> +
> >>>> + te_suspend: te-suspend-state {
> >>>> + pins = "gpio86"
> >>>> + function = "mdp_vsync";
> >>>> + drive-strength = <2>;
> >>>> + bias-pull-down;
> >>>> + };
> >>>
> >>> What is the difference between these two?
> >>
> >> TE pin needs to be pulled down for both active and suspend states. There
> >> is no difference.
> >
> > So why do you need two different states for it?
>
> Dividing into two different states can provide a clearer expression of
> whether the corresponging functionality is avtive or suspend.
How?
>
> We can also find similar settings in the other SM8550 and SM8650
> platform dts files, such as sm8550-qrd.dts and sm8650-qrd.dts.
Which means more items to cleanup.
See the discussion starting from
https://lore.kernel.org/linux-arm-msm/[email protected]/
>
> [1] sm8550-qrd.dts:
> https://elixir.bootlin.com/linux/v6.9.3/source/arch/arm64/boot/dts/qcom/sm8550-qrd.dts#L1052
>
> [2] sm8650-qrd.dts:
> https://elixir.bootlin.com/linux/v6.9.3/source/arch/arm64/boot/dts/qcom/sm8650-qrd.dts#L1098
>
> >
> >
> >
> >
> >
>
> --
> Thx and BRs,
> Tengfei Fan
--
With best wishes
Dmitry
Hi Tengfei,
On 29/05/2024 12:09, 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.
Are you describing some particular quirk of the platform here, or just
standard UEFI booting?
When booting with UEFI, the memory map is passed via the ESRT, so having
memory that the kernel shouldn't use it pretty simple (and typical).
> 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.
Again, is there something non-standard here? If not I would suggest
dropping these detail comments as they might be misleading.
Thanks and regards,
> 3. Remoteproc regions.
> Remoteproc regions will be reserved and then assigned to subsystem
> firmware later.
> Here is a reserved memory map for this platform:
> 0x100000000 +-------------------+
> | |
> | Firmware Related |
> | |
> 0xd4d00000 +-------------------+
> | |
> | Kernel Available |
> | |
> 0xa7000000 +-------------------+
> | |
> | Remoteproc Region |
> | |
> 0x8a800000 +-------------------+
> | |
> | Firmware Related |
> | |
> 0x80000000 +-------------------+
>
> Reviewed-by: Dmitry Baryshkov <[email protected]>
> Signed-off-by: Tengfei Fan <[email protected]>
> ---
> arch/arm64/boot/dts/qcom/qcs8550.dtsi | 167 ++++++++++++++++++++++++++
> 1 file changed, 167 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..685668c6ad14
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
> @@ -0,0 +1,167 @@
> +// 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.
> + * 3. Remoteproc regions.
> + * Remoteproc regions will be reserved and then assigned to
> + * subsystem firmware later.
> + * Here is a reserved memory map for this platform:
> + * 0x100000000 +-------------------+
> + * | |
> + * | Firmware Related |
> + * | |
> + * 0xd4d00000 +-------------------+
> + * | |
> + * | Kernel Available |
> + * | |
> + * 0xa7000000 +-------------------+
> + * | |
> + * | Remoteproc Region |
> + * | |
> + * 0x8a800000 +-------------------+
> + * | |
> + * | Firmware Related |
> + * | |
> + * 0x80000000 +-------------------+
> + */
> +
> + /*
> + * Firmware related regions, bootloader will possible reserve parts of
> + * region from 0x80000000..0x8a800000.
> + */
> + 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;
> + };
> +
> + /* PIL region */
> + 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;
> + };
> +
> + /*
> + * Firmware related regions, bootloader will possible reserve parts of
> + * region from 0xd8000000..0x100000000.
> + */
> + mpss_dsm_mem: mpss_dsm_region@d4d00000 {
> + reg = <0x0 0xd4d00000 0x0 0x3300000>;
> + no-map;
> + };
> + };
> +};
--
// Caleb (they/them)
On 6/3/2024 3:52 PM, Dmitry Baryshkov wrote:
> On Mon, 3 Jun 2024 at 10:38, Tengfei Fan <[email protected]> wrote:
>>
>>
>>
>> On 5/31/2024 4:38 PM, Dmitry Baryshkov wrote:
>>> On Fri, 31 May 2024 at 11:35, Tengfei Fan <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>> On 5/29/2024 11:18 PM, Dmitry Baryshkov wrote:
>>>>> On Wed, May 29, 2024 at 06:09:26PM +0800, 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 <[email protected]>
>>>>>> Signed-off-by: Qiang Yu <[email protected]>
>>>>>> Co-developed-by: Ziyue Zhang <[email protected]>
>>>>>> Signed-off-by: Ziyue Zhang <[email protected]>
>>>>>> Signed-off-by: Tengfei Fan <[email protected]>
>>>>>> ---
>>>>>> arch/arm64/boot/dts/qcom/Makefile | 1 +
>>>>>> .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++++++
>>>>>> 2 files changed, 323 insertions(+)
>>>>>> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
>>>>>
>>>>> [trimmed]
>>>>>
>>>>>> +&remoteproc_adsp {
>>>>>> + firmware-name = "qcom/qcs8550/adsp.mbn",
>>>>>> + "qcom/qcs8550/adsp_dtbs.elf";
>>>>>
>>>>> Please excuse me, I think I missed those on the previous run.
>>>>>
>>>>> adsp_dtb.mbn
>>>>
>>>> Currently, waht we have released is adsp_dtbs.elf. If we modify it to
>>>> adsp_dtb.mbn, it may cause the ADSP functionality can not boot normally.
>>>
>>> Released where? linux-firmware doesn't have such a file. And the modem
>>> partition most likely has a different path for it anyway.
>>
>> Firmware releases can be obtained from
>> https://qpm-git.qualcomm.com/home2/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git
>> after users sign up for free accounts on both
>> https://qpm-git.qualcomm.com and https://chipmaster2.qti.qualcomm.com.
>
> I'm getting 403 when accessing qpm-git (both with my Linaro
> credentials and with gmail ones).
> If I try to git-clone the URL you've provided, I'm getting "Not found"
> when using a gmail account and CURL error when using Linaro
> createntials.
>
> error: RPC failed; HTTP 302 curl 22 The requested URL returned error: 302
>
> Not to mention that the URL wasn't mentioned anywhere beforehand. So I
> can hardly call that 'released'
>
>>
>>>
>>>>
>>>>>
>>>>>> + status = "okay";
>>>>>> +};
>>>>>> +
>>>>>> +&remoteproc_cdsp {
>>>>>> + firmware-name = "qcom/qcs8550/cdsp.mbn",
>>>>>> + "qcom/qcs8550/cdsp_dtbs.elf";
>>>>>
>>>>> cdsp_dtb.mbn
>>>>
>>>> CDSP also as above ADSP.
>>>>
>>>>>
>>>
>>>>>> +
>>>>>> + te_active: te-active-state {
>>>>>> + pins = "gpio86";
>>>>>> + function = "mdp_vsync";
>>>>>> + drive-strength = <2>;
>>>>>> + bias-pull-down;
>>>>>> + };
>>>>>> +
>>>>>> + te_suspend: te-suspend-state {
>>>>>> + pins = "gpio86"
>>>>>> + function = "mdp_vsync";
>>>>>> + drive-strength = <2>;
>>>>>> + bias-pull-down;
>>>>>> + };
>>>>>
>>>>> What is the difference between these two?
>>>>
>>>> TE pin needs to be pulled down for both active and suspend states. There
>>>> is no difference.
>>>
>>> So why do you need two different states for it?
>>
>> Dividing into two different states can provide a clearer expression of
>> whether the corresponging functionality is avtive or suspend.
>
> How?
I understand your consideration from the upstream patch link which you
shared. Insteading of maintaining two separate state nodes, I will
update a default state node in the next patch series.
>
>>
>> We can also find similar settings in the other SM8550 and SM8650
>> platform dts files, such as sm8550-qrd.dts and sm8650-qrd.dts.
>
> Which means more items to cleanup.
>
> See the discussion starting from
> https://lore.kernel.org/linux-arm-msm/[email protected]/
>
>>
>> [1] sm8550-qrd.dts:
>> https://elixir.bootlin.com/linux/v6.9.3/source/arch/arm64/boot/dts/qcom/sm8550-qrd.dts#L1052
>>
>> [2] sm8650-qrd.dts:
>> https://elixir.bootlin.com/linux/v6.9.3/source/arch/arm64/boot/dts/qcom/sm8650-qrd.dts#L1098
>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Thx and BRs,
>> Tengfei Fan
>
>
>
--
Thx and BRs,
Tengfei Fan
On 6/3/2024 5:20 PM, Caleb Connolly wrote:
> Hi Tengfei,
>
> On 29/05/2024 12:09, 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.
>
> Are you describing some particular quirk of the platform here, or just
> standard UEFI booting?
It's standard UEFI booting efi config table.
>
> When booting with UEFI, the memory map is passed via the ESRT, so having
> memory that the kernel shouldn't use it pretty simple (and typical).
yes. It is very simple. And the bootloader firmware config the
"reserved" region in the efi config table from the uefi firmware.
>> 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.
>
> Again, is there something non-standard here? If not I would suggest
> dropping these detail comments as they might be misleading.
Detailed comments is used to describe current device tree reserved
memory regions.
Current patch is not creating a new mechanism to have memory map
described. But it is the first time qcom device trees use this design,
and have a simplified(also more compatible) device tree reserved memory
region(memory map). Previously, bootloader(apps bootloader) only pass
the whole physical memory base and size, and use reserved memory nodes
only in device tree(which is also a standard choose).
So that's why it is detailed comments for other qcom platform reference.
>
> Thanks and regards,
>> 3. Remoteproc regions.
>> Remoteproc regions will be reserved and then assigned to subsystem
>> firmware later.
>> Here is a reserved memory map for this platform:
>> 0x100000000 +-------------------+
>> | |
>> | Firmware Related |
>> | |
>> 0xd4d00000 +-------------------+
>> | |
>> | Kernel Available |
>> | |
>> 0xa7000000 +-------------------+
>> | |
>> | Remoteproc Region |
>> | |
>> 0x8a800000 +-------------------+
>> | |
>> | Firmware Related |
>> | |
>> 0x80000000 +-------------------+
>>
>> Reviewed-by: Dmitry Baryshkov <[email protected]>
>> Signed-off-by: Tengfei Fan <[email protected]>
>> ---
>> arch/arm64/boot/dts/qcom/qcs8550.dtsi | 167 ++++++++++++++++++++++++++
>> 1 file changed, 167 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..685668c6ad14
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>> @@ -0,0 +1,167 @@
>> +// 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.
>> + * 3. Remoteproc regions.
>> + * Remoteproc regions will be reserved and then assigned to
>> + * subsystem firmware later.
>> + * Here is a reserved memory map for this platform:
>> + * 0x100000000 +-------------------+
>> + * | |
>> + * | Firmware Related |
>> + * | |
>> + * 0xd4d00000 +-------------------+
>> + * | |
>> + * | Kernel Available |
>> + * | |
>> + * 0xa7000000 +-------------------+
>> + * | |
>> + * | Remoteproc Region |
>> + * | |
>> + * 0x8a800000 +-------------------+
>> + * | |
>> + * | Firmware Related |
>> + * | |
>> + * 0x80000000 +-------------------+
>> + */
>> +
>> + /*
>> + * Firmware related regions, bootloader will possible reserve
>> parts of
>> + * region from 0x80000000..0x8a800000.
>> + */
>> + 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;
>> + };
>> +
>> + /* PIL region */
>> + 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;
>> + };
>> +
>> + /*
>> + * Firmware related regions, bootloader will possible reserve
>> parts of
>> + * region from 0xd8000000..0x100000000.
>> + */
>> + mpss_dsm_mem: mpss_dsm_region@d4d00000 {
>> + reg = <0x0 0xd4d00000 0x0 0x3300000>;
>> + no-map;
>> + };
>> + };
>> +};
>
--
Thx and BRs,
Aiqun(Maria) Yu
On 04/06/2024 12:51, Aiqun Yu (Maria) wrote:
>
>
> On 6/3/2024 5:20 PM, Caleb Connolly wrote:
>> Hi Tengfei,
>>
>> On 29/05/2024 12:09, 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.
>>
>> Are you describing some particular quirk of the platform here, or just
>> standard UEFI booting?
>
> It's standard UEFI booting efi config table.
Ok, thanks for confirming.
>>
>> When booting with UEFI, the memory map is passed via the ESRT, so having
>> memory that the kernel shouldn't use it pretty simple (and typical).
woo! \o/
>
> yes. It is very simple. And the bootloader firmware config the
> "reserved" region in the efi config table from the uefi firmware.
>>> 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.
>>
>> Again, is there something non-standard here? If not I would suggest
>> dropping these detail comments as they might be misleading.
>
> Detailed comments is used to describe current device tree reserved
> memory regions.
>
> Current patch is not creating a new mechanism to have memory map
> described. But it is the first time qcom device trees use this design,
> and have a simplified(also more compatible) device tree reserved memory
> region(memory map). Previously, bootloader(apps bootloader) only pass
> the whole physical memory base and size, and use reserved memory nodes
> only in device tree(which is also a standard choose).
>
> So that's why it is detailed comments for other qcom platform reference.
Doesn't the rb3gen2 also use this design?
>
>>
>> Thanks and regards,
>>> 3. Remoteproc regions.
>>> Remoteproc regions will be reserved and then assigned to subsystem
>>> firmware later.
>>> Here is a reserved memory map for this platform:
>>> 0x100000000 +-------------------+
>>> | |
>>> | Firmware Related |
>>> | |
>>> 0xd4d00000 +-------------------+
>>> | |
>>> | Kernel Available |
>>> | |
>>> 0xa7000000 +-------------------+
>>> | |
>>> | Remoteproc Region |
>>> | |
>>> 0x8a800000 +-------------------+
>>> | |
>>> | Firmware Related |
>>> | |
>>> 0x80000000 +-------------------+
>>>
>>> Reviewed-by: Dmitry Baryshkov <[email protected]>
>>> Signed-off-by: Tengfei Fan <[email protected]>
>>> ---
>>> arch/arm64/boot/dts/qcom/qcs8550.dtsi | 167 ++++++++++++++++++++++++++
>>> 1 file changed, 167 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..685668c6ad14
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>> @@ -0,0 +1,167 @@
>>> +// 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.
>>> + * 3. Remoteproc regions.
>>> + * Remoteproc regions will be reserved and then assigned to
>>> + * subsystem firmware later.
>>> + * Here is a reserved memory map for this platform:
>>> + * 0x100000000 +-------------------+
>>> + * | |
>>> + * | Firmware Related |
>>> + * | |
>>> + * 0xd4d00000 +-------------------+
>>> + * | |
>>> + * | Kernel Available |
>>> + * | |
>>> + * 0xa7000000 +-------------------+
>>> + * | |
>>> + * | Remoteproc Region |
>>> + * | |
>>> + * 0x8a800000 +-------------------+
>>> + * | |
>>> + * | Firmware Related |
>>> + * | |
>>> + * 0x80000000 +-------------------+
>>> + */
>>> +
>>> + /*
>>> + * Firmware related regions, bootloader will possible reserve
>>> parts of
>>> + * region from 0x80000000..0x8a800000.
>>> + */
>>> + 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;
>>> + };
>>> +
>>> + /* PIL region */
>>> + 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;
>>> + };
>>> +
>>> + /*
>>> + * Firmware related regions, bootloader will possible reserve
>>> parts of
>>> + * region from 0xd8000000..0x100000000.
>>> + */
>>> + mpss_dsm_mem: mpss_dsm_region@d4d00000 {
>>> + reg = <0x0 0xd4d00000 0x0 0x3300000>;
>>> + no-map;
>>> + };
>>> + };
>>> +};
>>
>
--
// Caleb (they/them)
On 6/4/2024 7:20 PM, Caleb Connolly wrote:
>
>
> On 04/06/2024 12:51, Aiqun Yu (Maria) wrote:
>>
>>
>> On 6/3/2024 5:20 PM, Caleb Connolly wrote:
>>> Hi Tengfei,
>>>
>>> On 29/05/2024 12:09, 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.
>>>
>>> Are you describing some particular quirk of the platform here, or just
>>> standard UEFI booting?
>>
>> It's standard UEFI booting efi config table.
>
> Ok, thanks for confirming.
>>>
>>> When booting with UEFI, the memory map is passed via the ESRT, so having
>>> memory that the kernel shouldn't use it pretty simple (and typical).
>
> woo! \o/
>>
>> yes. It is very simple. And the bootloader firmware config the
>> "reserved" region in the efi config table from the uefi firmware.
>>>> 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.
>>>
>>> Again, is there something non-standard here? If not I would suggest
>>> dropping these detail comments as they might be misleading.
>>
>> Detailed comments is used to describe current device tree reserved
>> memory regions.
>>
>> Current patch is not creating a new mechanism to have memory map
>> described. But it is the first time qcom device trees use this design,
>> and have a simplified(also more compatible) device tree reserved memory
>> region(memory map). Previously, bootloader(apps bootloader) only pass
>> the whole physical memory base and size, and use reserved memory nodes
>> only in device tree(which is also a standard choose).
>>
>> So that's why it is detailed comments for other qcom platform reference.
>
> Doesn't the rb3gen2 also use this design?
Checked current qcs6490-rb3gen2.dts still use the device tree to have
all the reserved regions, even have detailed regions like "Firmware
related regions which aren't shared with kernel."
Not sure current qcs6490 firmware efi config table looks like, if it
have all the reserved region marked carefully on efi config table, then
device tree don't need to mention the reserved regions which is not
shared to kernel.
The qcom memory map in device tree discussion was happened after qcs6490
rb3gen2 time frame. efi config table is standard. But we still need to
check what's the final config placed in the table for different
platforms. I will suggest to have current qcs8550 as an example to
config the current memory non-kernel needed to know region inside the
efi config table in bootloader, and have kernel shared reserved region
marked in the device tree.
>>
>>>
>>> Thanks and regards,
>>>> 3. Remoteproc regions.
>>>> Remoteproc regions will be reserved and then assigned to
>>>> subsystem
>>>> firmware later.
>>>> Here is a reserved memory map for this platform:
>>>> 0x100000000 +-------------------+
>>>> | |
>>>> | Firmware Related |
>>>> | |
>>>> 0xd4d00000 +-------------------+
>>>> | |
>>>> | Kernel Available |
>>>> | |
>>>> 0xa7000000 +-------------------+
>>>> | |
>>>> | Remoteproc Region |
>>>> | |
>>>> 0x8a800000 +-------------------+
>>>> | |
>>>> | Firmware Related |
>>>> | |
>>>> 0x80000000 +-------------------+
>>>>
>>>> Reviewed-by: Dmitry Baryshkov <[email protected]>
>>>> Signed-off-by: Tengfei Fan <[email protected]>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/qcs8550.dtsi | 167
>>>> ++++++++++++++++++++++++++
>>>> 1 file changed, 167 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..685668c6ad14
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>>> @@ -0,0 +1,167 @@
>>>> +// 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.
>>>> + * 3. Remoteproc regions.
>>>> + * Remoteproc regions will be reserved and then
>>>> assigned to
>>>> + * subsystem firmware later.
>>>> + * Here is a reserved memory map for this platform:
>>>> + * 0x100000000 +-------------------+
>>>> + * | |
>>>> + * | Firmware Related |
>>>> + * | |
>>>> + * 0xd4d00000 +-------------------+
>>>> + * | |
>>>> + * | Kernel Available |
>>>> + * | |
>>>> + * 0xa7000000 +-------------------+
>>>> + * | |
>>>> + * | Remoteproc Region |
>>>> + * | |
>>>> + * 0x8a800000 +-------------------+
>>>> + * | |
>>>> + * | Firmware Related |
>>>> + * | |
>>>> + * 0x80000000 +-------------------+
>>>> + */
>>>> +
>>>> + /*
>>>> + * Firmware related regions, bootloader will possible reserve
>>>> parts of
>>>> + * region from 0x80000000..0x8a800000.
>>>> + */
>>>> + 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;
>>>> + };
>>>> +
>>>> + /* PIL region */
>>>> + 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;
>>>> + };
>>>> +
>>>> + /*
>>>> + * Firmware related regions, bootloader will possible reserve
>>>> parts of
>>>> + * region from 0xd8000000..0x100000000.
>>>> + */
>>>> + mpss_dsm_mem: mpss_dsm_region@d4d00000 {
>>>> + reg = <0x0 0xd4d00000 0x0 0x3300000>;
>>>> + no-map;
>>>> + };
>>>> + };
>>>> +};
>>>
>>
>
--
Thx and BRs,
Aiqun(Maria) Yu
Hi,
On 05/06/2024 06:51, Aiqun Yu (Maria) wrote:
>
>
> On 6/4/2024 7:20 PM, Caleb Connolly wrote:
>>
>>
>> On 04/06/2024 12:51, Aiqun Yu (Maria) wrote:
>>>
>>>
>>> On 6/3/2024 5:20 PM, Caleb Connolly wrote:
>>>> Hi Tengfei,
>>>>
>>>> On 29/05/2024 12:09, 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.
>>>>
>>>> Are you describing some particular quirk of the platform here, or just
>>>> standard UEFI booting?
>>>
>>> It's standard UEFI booting efi config table.
>>
>> Ok, thanks for confirming.
>>>>
>>>> When booting with UEFI, the memory map is passed via the ESRT, so having
>>>> memory that the kernel shouldn't use it pretty simple (and typical).
>>
>> woo! \o/
>>>
>>> yes. It is very simple. And the bootloader firmware config the
>>> "reserved" region in the efi config table from the uefi firmware.
>>>>> 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.
>>>>
>>>> Again, is there something non-standard here? If not I would suggest
>>>> dropping these detail comments as they might be misleading.
>>>
>>> Detailed comments is used to describe current device tree reserved
>>> memory regions.
>>>
>>> Current patch is not creating a new mechanism to have memory map
>>> described. But it is the first time qcom device trees use this design,
>>> and have a simplified(also more compatible) device tree reserved memory
>>> region(memory map). Previously, bootloader(apps bootloader) only pass
>>> the whole physical memory base and size, and use reserved memory nodes
>>> only in device tree(which is also a standard choose).
>>>
>>> So that's why it is detailed comments for other qcom platform reference.
>>
>> Doesn't the rb3gen2 also use this design?
>
> Checked current qcs6490-rb3gen2.dts still use the device tree to have
> all the reserved regions, even have detailed regions like "Firmware
> related regions which aren't shared with kernel."
Right,
>
> Not sure current qcs6490 firmware efi config table looks like, if it
> have all the reserved region marked carefully on efi config table, then
> device tree don't need to mention the reserved regions which is not
> shared to kernel.
That makes sense.
>
> The qcom memory map in device tree discussion was happened after qcs6490
> rb3gen2 time frame. efi config table is standard. But we still need to
> check what's the final config placed in the table for different
> platforms. I will suggest to have current qcs8550 as an example to
> config the current memory non-kernel needed to know region inside the
> efi config table in bootloader, and have kernel shared reserved region
> marked in the device tree.
Ok, thanks for explaining the context here. Using the ESRT for this
certainly makes more sense to me.
So regarding the comment in the reserved-memory node below, I think this
could be simplified to just a sentence or two explaining how this
platform is different. Maybe something like:
/* 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. */
A few more comments in-line.
>
>>>
>>>>
>>>> Thanks and regards,
>>>>> 3. Remoteproc regions.
>>>>> Remoteproc regions will be reserved and then assigned to
>>>>> subsystem
>>>>> firmware later.
>>>>> Here is a reserved memory map for this platform:
>>>>> 0x100000000 +-------------------+
>>>>> | |
>>>>> | Firmware Related |
>>>>> | |
>>>>> 0xd4d00000 +-------------------+
>>>>> | |
>>>>> | Kernel Available |
>>>>> | |
>>>>> 0xa7000000 +-------------------+
>>>>> | |
>>>>> | Remoteproc Region |
>>>>> | |
>>>>> 0x8a800000 +-------------------+
>>>>> | |
>>>>> | Firmware Related |
>>>>> | |
>>>>> 0x80000000 +-------------------+
>>>>>
>>>>> Reviewed-by: Dmitry Baryshkov <[email protected]>
>>>>> Signed-off-by: Tengfei Fan <[email protected]>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/qcs8550.dtsi | 167
>>>>> ++++++++++++++++++++++++++
>>>>> 1 file changed, 167 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..685668c6ad14
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>>>> @@ -0,0 +1,167 @@
>>>>> +// 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.
>>>>> + * 3. Remoteproc regions.
>>>>> + * Remoteproc regions will be reserved and then
>>>>> assigned to
>>>>> + * subsystem firmware later.
>>>>> + * Here is a reserved memory map for this platform:
>>>>> + * 0x100000000 +-------------------+
>>>>> + * | |
>>>>> + * | Firmware Related |
>>>>> + * | |
>>>>> + * 0xd4d00000 +-------------------+
>>>>> + * | |
>>>>> + * | Kernel Available |
>>>>> + * | |
>>>>> + * 0xa7000000 +-------------------+
>>>>> + * | |
>>>>> + * | Remoteproc Region |
>>>>> + * | |
>>>>> + * 0x8a800000 +-------------------+
>>>>> + * | |
>>>>> + * | Firmware Related |
>>>>> + * | |
>>>>> + * 0x80000000 +-------------------+
I guess this is quite subjective, but this diagram looks "upside down"
to me. I think it's generally more popular to have the lower addresses
at the top.
>>>>> + */
>>>>> +
>>>>> + /*
>>>>> + * Firmware related regions, bootloader will possible reserve
>>>>> parts of
>>>>> + * region from 0x80000000..0x8a800000.
This is just duplicating info from the table, please drop this comment
(it should be obvious from the above explanation).
>>>>> + */
>>>>> + 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;
>>>>> + };
>>>>> +
>>>>> + /* PIL region */
Drop this comment
>>>>> + 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;
>>>>> + };
>>>>> +
>>>>> + /*
>>>>> + * Firmware related regions, bootloader will possible reserve
>>>>> parts of
>>>>> + * region from 0xd8000000..0x100000000.
>>>>> + */
The address specified in this comment (0xd8000000) doesn't match the
mpss_dsm_mem region OR the diagram above. I would suggest dropping this
comment too.
>>>>> + mpss_dsm_mem: mpss_dsm_region@d4d00000 {
>>>>> + reg = <0x0 0xd4d00000 0x0 0x3300000>;
>>>>> + no-map;
>>>>> + };
>>>>> + };
>>>>> +};
>>>>
>>>
>>
>
Kind regards,
--
// Caleb (they/them)
On 6/3/2024 3:52 PM, Dmitry Baryshkov wrote:
> On Mon, 3 Jun 2024 at 10:38, Tengfei Fan <[email protected]> wrote:
>>
>>
>>
>> On 5/31/2024 4:38 PM, Dmitry Baryshkov wrote:
>>> On Fri, 31 May 2024 at 11:35, Tengfei Fan <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>> On 5/29/2024 11:18 PM, Dmitry Baryshkov wrote:
>>>>> On Wed, May 29, 2024 at 06:09:26PM +0800, 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 <[email protected]>
>>>>>> Signed-off-by: Qiang Yu <[email protected]>
>>>>>> Co-developed-by: Ziyue Zhang <[email protected]>
>>>>>> Signed-off-by: Ziyue Zhang <[email protected]>
>>>>>> Signed-off-by: Tengfei Fan <[email protected]>
>>>>>> ---
>>>>>> arch/arm64/boot/dts/qcom/Makefile | 1 +
>>>>>> .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++++++
>>>>>> 2 files changed, 323 insertions(+)
>>>>>> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
>>>>>
>>>>> [trimmed]
>>>>>
>>>>>> +&remoteproc_adsp {
>>>>>> + firmware-name = "qcom/qcs8550/adsp.mbn",
>>>>>> + "qcom/qcs8550/adsp_dtbs.elf";
>>>>>
>>>>> Please excuse me, I think I missed those on the previous run.
>>>>>
>>>>> adsp_dtb.mbn
>>>>
>>>> Currently, waht we have released is adsp_dtbs.elf. If we modify it to
>>>> adsp_dtb.mbn, it may cause the ADSP functionality can not boot normally.
>>>
>>> Released where? linux-firmware doesn't have such a file. And the modem
>>> partition most likely has a different path for it anyway.
>>
>> Firmware releases can be obtained from
>> https://qpm-git.qualcomm.com/home2/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git
>> after users sign up for free accounts on both
>> https://qpm-git.qualcomm.com and https://chipmaster2.qti.qualcomm.com.
>
> I'm getting 403 when accessing qpm-git (both with my Linaro
> credentials and with gmail ones).
> If I try to git-clone the URL you've provided, I'm getting "Not found"
> when using a gmail account and CURL error when using Linaro
> createntials.
>
> error: RPC failed; HTTP 302 curl 22 The requested URL returned error: 302
>
> Not to mention that the URL wasn't mentioned anywhere beforehand. So I
> can hardly call that 'released'
>
Hi Dmitry,
Let me elabarote the way to get access to firmware of aim300.
Visit the website Qualcomm used to release software which is
chipcode.qti.qualcomm.com.
Use sign up to create a Qualcomm ID with email you have.
Login with your Qualcomm ID. Search for Qualcomm_Linux.SPF.1.0.
This is Qualcomm Linux release. Select
qualcomm-linux-spf-1-0_test_device_public. You should be able to find
the firmware release. You need to agree PKLA license during this process.
After that, you can edit ~/.netrc to add your username and password
which you just create as Qualcomm ID to chipmaster2.qti.qualcomm.com and
qpm-git.qualcomm.com.
git clone
https://qpm-git.qualcomm.com/home2/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git
Firmware package is under
qualcomm-linux-spf-1-0_test_device_public/QCM8550.LE.2.0/common/build/ufs/bin/QCS8550_fw.zip.
Unzip this file. Firmware is under QCS8550_fw/lib/firmware/qcom/qcs8550/
>>
>>>
>>>>
>>>>>
>>>>>> + status = "okay";
>>>>>> +};
>>>>>> +
>>>>>> +&remoteproc_cdsp {
>>>>>> + firmware-name = "qcom/qcs8550/cdsp.mbn",
>>>>>> + "qcom/qcs8550/cdsp_dtbs.elf";
>>>>>
>>>>> cdsp_dtb.mbn
>>>>
>>>> CDSP also as above ADSP.
>>>>
>>>>>
>>>
>>>>>> +
>>>>>> + te_active: te-active-state {
>>>>>> + pins = "gpio86";
>>>>>> + function = "mdp_vsync";
>>>>>> + drive-strength = <2>;
>>>>>> + bias-pull-down;
>>>>>> + };
>>>>>> +
>>>>>> + te_suspend: te-suspend-state {
>>>>>> + pins = "gpio86"
>>>>>> + function = "mdp_vsync";
>>>>>> + drive-strength = <2>;
>>>>>> + bias-pull-down;
>>>>>> + };
>>>>>
>>>>> What is the difference between these two?
>>>>
>>>> TE pin needs to be pulled down for both active and suspend states. There
>>>> is no difference.
>>>
>>> So why do you need two different states for it?
>>
>> Dividing into two different states can provide a clearer expression of
>> whether the corresponging functionality is avtive or suspend.
>
> How?
>
>>
>> We can also find similar settings in the other SM8550 and SM8650
>> platform dts files, such as sm8550-qrd.dts and sm8650-qrd.dts.
>
> Which means more items to cleanup.
>
> See the discussion starting from
> https://lore.kernel.org/linux-arm-msm/[email protected]/
>
>>
>> [1] sm8550-qrd.dts:
>> https://elixir.bootlin.com/linux/v6.9.3/source/arch/arm64/boot/dts/qcom/sm8550-qrd.dts#L1052
>>
>> [2] sm8650-qrd.dts:
>> https://elixir.bootlin.com/linux/v6.9.3/source/arch/arm64/boot/dts/qcom/sm8650-qrd.dts#L1098
>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Thx and BRs,
>> Tengfei Fan
>
>
>
--
Thanks,
Tingwei
On Thu, 6 Jun 2024 at 12:27, Tingwei Zhang <[email protected]> wrote:
>
> On 6/3/2024 3:52 PM, Dmitry Baryshkov wrote:
> > On Mon, 3 Jun 2024 at 10:38, Tengfei Fan <[email protected]> wrote:
> >>
> >>
> >>
> >> On 5/31/2024 4:38 PM, Dmitry Baryshkov wrote:
> >>> On Fri, 31 May 2024 at 11:35, Tengfei Fan <[email protected]> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 5/29/2024 11:18 PM, Dmitry Baryshkov wrote:
> >>>>> On Wed, May 29, 2024 at 06:09:26PM +0800, 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 <[email protected]>
> >>>>>> Signed-off-by: Qiang Yu <[email protected]>
> >>>>>> Co-developed-by: Ziyue Zhang <[email protected]>
> >>>>>> Signed-off-by: Ziyue Zhang <[email protected]>
> >>>>>> Signed-off-by: Tengfei Fan <[email protected]>
> >>>>>> ---
> >>>>>> arch/arm64/boot/dts/qcom/Makefile | 1 +
> >>>>>> .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++++++
> >>>>>> 2 files changed, 323 insertions(+)
> >>>>>> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
> >>>>>
> >>>>> [trimmed]
> >>>>>
> >>>>>> +&remoteproc_adsp {
> >>>>>> + firmware-name = "qcom/qcs8550/adsp.mbn",
> >>>>>> + "qcom/qcs8550/adsp_dtbs.elf";
> >>>>>
> >>>>> Please excuse me, I think I missed those on the previous run.
> >>>>>
> >>>>> adsp_dtb.mbn
> >>>>
> >>>> Currently, waht we have released is adsp_dtbs.elf. If we modify it to
> >>>> adsp_dtb.mbn, it may cause the ADSP functionality can not boot normally.
> >>>
> >>> Released where? linux-firmware doesn't have such a file. And the modem
> >>> partition most likely has a different path for it anyway.
> >>
> >> Firmware releases can be obtained from
> >> https://qpm-git.qualcomm.com/home2/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git
> >> after users sign up for free accounts on both
> >> https://qpm-git.qualcomm.com and https://chipmaster2.qti.qualcomm.com.
> >
> > I'm getting 403 when accessing qpm-git (both with my Linaro
> > credentials and with gmail ones).
> > If I try to git-clone the URL you've provided, I'm getting "Not found"
> > when using a gmail account and CURL error when using Linaro
> > createntials.
> >
> > error: RPC failed; HTTP 302 curl 22 The requested URL returned error: 302
> >
> > Not to mention that the URL wasn't mentioned anywhere beforehand. So I
> > can hardly call that 'released'
> >
> Hi Dmitry,
>
> Let me elabarote the way to get access to firmware of aim300.
>
> Visit the website Qualcomm used to release software which is
> chipcode.qti.qualcomm.com.
> Use sign up to create a Qualcomm ID with email you have.
> Login with your Qualcomm ID. Search for Qualcomm_Linux.SPF.1.0.
> This is Qualcomm Linux release. Select
> qualcomm-linux-spf-1-0_test_device_public. You should be able to find
> the firmware release. You need to agree PKLA license during this process.
>
> After that, you can edit ~/.netrc to add your username and password
> which you just create as Qualcomm ID to chipmaster2.qti.qualcomm.com and
> qpm-git.qualcomm.com.
> git clone
> https://qpm-git.qualcomm.com/home2/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git
Cloning into 'qualcomm-linux-spf-1-0_test_device_public'...
Username for 'https://chipmaster2.qti.qualcomm.com': [email protected]
Password for 'https://[email protected]@chipmaster2.qti.qualcomm.com':
warning: redirecting to
https://chipmaster2.qti.qualcomm.com/home/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git/
error: RPC failed; HTTP 302 curl 22 The requested URL returned error: 302
fatal: the remote end hung up unexpectedly
> Firmware package is under
> qualcomm-linux-spf-1-0_test_device_public/QCM8550.LE.2.0/common/build/ufs/bin/QCS8550_fw.zip.
The licence file is not present inside the repository. So after
clicking through it it I have no way to check the terms of the
licence.
> Unzip this file. Firmware is under QCS8550_fw/lib/firmware/qcom/qcs8550/
Is there anything specific to qcs8550 vs sm8550? If not, it should go
to firmware/qcom/sm8550/ instead.
However, back to the original question. We are looking for the
unification of the firmware names, not for the further diversions of
them. Few weeks ago we got another ping from arm-soc maintainers to
stop including firmware-names into the DT files. From my point of
view, no matter what file name was used in the binary release, please
use adsp_dtb.mbn for upstream submission.
> >>
> >>>
> >>>>
> >>>>>
> >>>>>> + status = "okay";
> >>>>>> +};
> >>>>>> +
> >>>>>> +&remoteproc_cdsp {
> >>>>>> + firmware-name = "qcom/qcs8550/cdsp.mbn",
> >>>>>> + "qcom/qcs8550/cdsp_dtbs.elf";
> >>>>>
> >>>>> cdsp_dtb.mbn
> >>>>
> >>>> CDSP also as above ADSP.
--
With best wishes
Dmitry
On 6/5/2024 8:00 PM, Caleb Connolly wrote:
> Hi,
>
> On 05/06/2024 06:51, Aiqun Yu (Maria) wrote:
>>
>>
>> On 6/4/2024 7:20 PM, Caleb Connolly wrote:
>>>
>>>
>>> On 04/06/2024 12:51, Aiqun Yu (Maria) wrote:
>>>>
>>>>
>>>> On 6/3/2024 5:20 PM, Caleb Connolly wrote:
>>>>> Hi Tengfei,
>>>>>
>>>>> On 29/05/2024 12:09, 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.
>>>>>
>>>>> Are you describing some particular quirk of the platform here, or just
>>>>> standard UEFI booting?
>>>>
>>>> It's standard UEFI booting efi config table.
>>>
>>> Ok, thanks for confirming.
>>>>>
>>>>> When booting with UEFI, the memory map is passed via the ESRT, so
>>>>> having
>>>>> memory that the kernel shouldn't use it pretty simple (and typical).
>>>
>>> woo! \o/
>>>>
>>>> yes. It is very simple. And the bootloader firmware config the
>>>> "reserved" region in the efi config table from the uefi firmware.
>>>>>> 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.
>>>>>
>>>>> Again, is there something non-standard here? If not I would suggest
>>>>> dropping these detail comments as they might be misleading.
>>>>
>>>> Detailed comments is used to describe current device tree reserved
>>>> memory regions.
>>>>
>>>> Current patch is not creating a new mechanism to have memory map
>>>> described. But it is the first time qcom device trees use this design,
>>>> and have a simplified(also more compatible) device tree reserved memory
>>>> region(memory map). Previously, bootloader(apps bootloader) only pass
>>>> the whole physical memory base and size, and use reserved memory nodes
>>>> only in device tree(which is also a standard choose).
>>>>
>>>> So that's why it is detailed comments for other qcom platform
>>>> reference.
>>>
>>> Doesn't the rb3gen2 also use this design?
>>
>> Checked current qcs6490-rb3gen2.dts still use the device tree to have
>> all the reserved regions, even have detailed regions like "Firmware
>> related regions which aren't shared with kernel."
>
> Right,
>>
>> Not sure current qcs6490 firmware efi config table looks like, if it
>> have all the reserved region marked carefully on efi config table, then
>> device tree don't need to mention the reserved regions which is not
>> shared to kernel.
>
> That makes sense.
>>
>> The qcom memory map in device tree discussion was happened after qcs6490
>> rb3gen2 time frame. efi config table is standard. But we still need to
>> check what's the final config placed in the table for different
>> platforms. I will suggest to have current qcs8550 as an example to
>> config the current memory non-kernel needed to know region inside the
>> efi config table in bootloader, and have kernel shared reserved region
>> marked in the device tree.
>
> Ok, thanks for explaining the context here. Using the ESRT for this
> certainly makes more sense to me.
>
> So regarding the comment in the reserved-memory node below, I think this
> could be simplified to just a sentence or two explaining how this
> platform is different. Maybe something like:
>
> /* 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. */
The previous message still accounts per my understanding since it can be
referenced to others who are not familiar with the memory map change or
ESRT memory map solution.
I think we can add your above message into the commit message to have
more information. Appreciate the comments if others have similar doubts
as you have.
>
> A few more comments in-line.
>>
>>>>
>>>>>
>>>>> Thanks and regards,
>>>>>> 3. Remoteproc regions.
>>>>>> Remoteproc regions will be reserved and then assigned to
>>>>>> subsystem
>>>>>> firmware later.
>>>>>> Here is a reserved memory map for this platform:
>>>>>> 0x100000000 +-------------------+
>>>>>> | |
>>>>>> | Firmware Related |
>>>>>> | |
>>>>>> 0xd4d00000 +-------------------+
>>>>>> | |
>>>>>> | Kernel Available |
>>>>>> | |
>>>>>> 0xa7000000 +-------------------+
>>>>>> | |
>>>>>> | Remoteproc Region |
>>>>>> | |
>>>>>> 0x8a800000 +-------------------+
>>>>>> | |
>>>>>> | Firmware Related |
>>>>>> | |
>>>>>> 0x80000000 +-------------------+
>>>>>>
>>>>>> Reviewed-by: Dmitry Baryshkov <[email protected]>
>>>>>> Signed-off-by: Tengfei Fan <[email protected]>
>>>>>> ---
>>>>>> arch/arm64/boot/dts/qcom/qcs8550.dtsi | 167
>>>>>> ++++++++++++++++++++++++++
>>>>>> 1 file changed, 167 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..685668c6ad14
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
>>>>>> @@ -0,0 +1,167 @@
>>>>>> +// 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.
>>>>>> + * 3. Remoteproc regions.
>>>>>> + * Remoteproc regions will be reserved and then
>>>>>> assigned to
>>>>>> + * subsystem firmware later.
>>>>>> + * Here is a reserved memory map for this platform:
>>>>>> + * 0x100000000 +-------------------+
>>>>>> + * | |
>>>>>> + * | Firmware Related |
>>>>>> + * | |
>>>>>> + * 0xd4d00000 +-------------------+
>>>>>> + * | |
>>>>>> + * | Kernel Available |
>>>>>> + * | |
>>>>>> + * 0xa7000000 +-------------------+
>>>>>> + * | |
>>>>>> + * | Remoteproc Region |
>>>>>> + * | |
>>>>>> + * 0x8a800000 +-------------------+
>>>>>> + * | |
>>>>>> + * | Firmware Related |
>>>>>> + * | |
>>>>>> + * 0x80000000 +-------------------+
>
> I guess this is quite subjective, but this diagram looks "upside down"
> to me. I think it's generally more popular to have the lower addresses
> at the top.
ack.
>
>>>>>> + */
>>>>>> +
>>>>>> + /*
>>>>>> + * Firmware related regions, bootloader will possible
>>>>>> reserve
>>>>>> parts of
>>>>>> + * region from 0x80000000..0x8a800000.
>
> This is just duplicating info from the table, please drop this comment
> (it should be obvious from the above explanation).
ack.
>>>>>> + */
>>>>>> + 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;
>>>>>> + };
>>>>>> +
>>>>>> + /* PIL region */
>
> Drop this comment
ack.
>>>>>> + 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;
>>>>>> + };
>>>>>> +
>>>>>> + /*
>>>>>> + * Firmware related regions, bootloader will possible
>>>>>> reserve
>>>>>> parts of
>>>>>> + * region from 0xd8000000..0x100000000.
>>>>>> + */
>
> The address specified in this comment (0xd8000000) doesn't match the
> mpss_dsm_mem region OR the diagram above. I would suggest dropping this
> comment too.
ack.
>>>>>> + mpss_dsm_mem: mpss_dsm_region@d4d00000 {
>>>>>> + reg = <0x0 0xd4d00000 0x0 0x3300000>;
>>>>>> + no-map;
>>>>>> + };
>>>>>> + };
>>>>>> +};
>>>>>
>>>>
>>>
>>
>
> Kind regards,
--
Thx and BRs,
Aiqun(Maria) Yu
On 6/6/2024 6:54 PM, Dmitry Baryshkov wrote:
> On Thu, 6 Jun 2024 at 12:27, Tingwei Zhang <[email protected]> wrote:
>>
>> On 6/3/2024 3:52 PM, Dmitry Baryshkov wrote:
>>> On Mon, 3 Jun 2024 at 10:38, Tengfei Fan <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>> On 5/31/2024 4:38 PM, Dmitry Baryshkov wrote:
>>>>> On Fri, 31 May 2024 at 11:35, Tengfei Fan <[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/29/2024 11:18 PM, Dmitry Baryshkov wrote:
>>>>>>> On Wed, May 29, 2024 at 06:09:26PM +0800, 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 <[email protected]>
>>>>>>>> Signed-off-by: Qiang Yu <[email protected]>
>>>>>>>> Co-developed-by: Ziyue Zhang <[email protected]>
>>>>>>>> Signed-off-by: Ziyue Zhang <[email protected]>
>>>>>>>> Signed-off-by: Tengfei Fan <[email protected]>
>>>>>>>> ---
>>>>>>>> arch/arm64/boot/dts/qcom/Makefile | 1 +
>>>>>>>> .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++++++
>>>>>>>> 2 files changed, 323 insertions(+)
>>>>>>>> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
>>>>>>>
>>>>>>> [trimmed]
>>>>>>>
>>>>>>>> +&remoteproc_adsp {
>>>>>>>> + firmware-name = "qcom/qcs8550/adsp.mbn",
>>>>>>>> + "qcom/qcs8550/adsp_dtbs.elf";
>>>>>>>
>>>>>>> Please excuse me, I think I missed those on the previous run.
>>>>>>>
>>>>>>> adsp_dtb.mbn
>>>>>>
>>>>>> Currently, waht we have released is adsp_dtbs.elf. If we modify it to
>>>>>> adsp_dtb.mbn, it may cause the ADSP functionality can not boot normally.
>>>>>
>>>>> Released where? linux-firmware doesn't have such a file. And the modem
>>>>> partition most likely has a different path for it anyway.
>>>>
>>>> Firmware releases can be obtained from
>>>> https://qpm-git.qualcomm.com/home2/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git
>>>> after users sign up for free accounts on both
>>>> https://qpm-git.qualcomm.com and https://chipmaster2.qti.qualcomm.com.
>>>
>>> I'm getting 403 when accessing qpm-git (both with my Linaro
>>> credentials and with gmail ones).
>>> If I try to git-clone the URL you've provided, I'm getting "Not found"
>>> when using a gmail account and CURL error when using Linaro
>>> createntials.
>>>
>>> error: RPC failed; HTTP 302 curl 22 The requested URL returned error: 302
>>>
>>> Not to mention that the URL wasn't mentioned anywhere beforehand. So I
>>> can hardly call that 'released'
>>>
>> Hi Dmitry,
>>
>> Let me elabarote the way to get access to firmware of aim300.
>>
>> Visit the website Qualcomm used to release software which is
>> chipcode.qti.qualcomm.com.
>> Use sign up to create a Qualcomm ID with email you have.
>> Login with your Qualcomm ID. Search for Qualcomm_Linux.SPF.1.0.
>> This is Qualcomm Linux release. Select
>> qualcomm-linux-spf-1-0_test_device_public. You should be able to find
>> the firmware release. You need to agree PKLA license during this process.
>>
>> After that, you can edit ~/.netrc to add your username and password
>> which you just create as Qualcomm ID to chipmaster2.qti.qualcomm.com and
>> qpm-git.qualcomm.com.
>> git clone
>> https://qpm-git.qualcomm.com/home2/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git
>
> Cloning into 'qualcomm-linux-spf-1-0_test_device_public'...
> Username for 'https://chipmaster2.qti.qualcomm.com': [email protected]
> Password for 'https://[email protected]@chipmaster2.qti.qualcomm.com':
> warning: redirecting to
> https://chipmaster2.qti.qualcomm.com/home/git/qualcomm/qualcomm-linux-spf-1-0_test_device_public.git/
> error: RPC failed; HTTP 302 curl 22 The requested URL returned error: 302
> fatal: the remote end hung up unexpectedly
>
>
>> Firmware package is under
>> qualcomm-linux-spf-1-0_test_device_public/QCM8550.LE.2.0/common/build/ufs/bin/QCS8550_fw.zip.
>
> The licence file is not present inside the repository. So after
> clicking through it it I have no way to check the terms of the
> licence.
>
>> Unzip this file. Firmware is under QCS8550_fw/lib/firmware/qcom/qcs8550/
>
> Is there anything specific to qcs8550 vs sm8550? If not, it should go
> to firmware/qcom/sm8550/ instead.
>
> However, back to the original question. We are looking for the
> unification of the firmware names, not for the further diversions of
> them. Few weeks ago we got another ping from arm-soc maintainers to
> stop including firmware-names into the DT files. From my point of
> view, no matter what file name was used in the binary release, please
> use adsp_dtb.mbn for upstream submission.
>
*_dtb.mbn will be used instead of *_dtb.elf in the next version patch
series.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> + status = "okay";
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&remoteproc_cdsp {
>>>>>>>> + firmware-name = "qcom/qcs8550/cdsp.mbn",
>>>>>>>> + "qcom/qcs8550/cdsp_dtbs.elf";
>>>>>>>
>>>>>>> cdsp_dtb.mbn
>>>>>>
>>>>>> CDSP also as above ADSP.
>
>
--
Thx and BRs,
Tengfei Fan