| Message ID | 20240513090735.1666142-1-quic_tengfan@quicinc.com |
|---|---|
| Headers | show |
| Series | arm64: qcom: add AIM300 AIoT board support | expand |
On 5/13/2024 2:07 AM, Tengfei Fan wrote: > QCS8550 is derived from SM8550. The differnece between SM8550 and spellcheck s/difference/difference > QCS8550 is QCS8550 doesn't have modem RF system. QCS8550 is mainly used > in IoT scenarios. IoT products and not scenarios. > QCS8550 firmware has different memory map with SM8550 firmware. "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. OS bootloader conveys the Just "Bootloader conveys the information by updating devicetree at runtime" ? > information by update device tree in 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. I understand what you are trying to explain below, but can we simplify further? I had to read multiple times to understand what you are trying to convey above. > 2. Firmware related memory regions which are shared with Kernel > Each region has a specific node with specific label name for later > phandle reference from other driver dt node. > 3. PIL regions. Do we use the PIL - peripheral image loader in the upstream kernel or just remoteproc? I am fine w/ PIL if it is used at other places in Qualcomm remoteproc. > PIL 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 | What is "kernel available" means? > | | > 0xa7000000 +------------------+ > | | > | PIL Region | > | | > 0x8a800000 +------------------+ > | | > | Firmware Related | > | | > 0x80000000 +------------------+ > Note that: Do we need to write "Note that:" ? > 0xa7000000..0xA8000000 is used by bootloader, when kernel boot up, > it is available for kernel usage. This region is not suggested to be > used by kernel features like ramoops, suspend resume etc. > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com> > --- > arch/arm64/boot/dts/qcom/qcs8550.dtsi | 169 ++++++++++++++++++++++++++ > 1 file changed, 169 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..a3ebf3d4e16d > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi > @@ -0,0 +1,169 @@ > +// 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. OS bootloader > + * conveys the information by update device tree in 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. > + * Each region has a specific node with specific label name for > + * later phandle reference from other driver dt node. > + * 3. PIL regions. > + * PIL regions will be reserved and then assigned to subsystem > + * firmware later. > + * Here is a reserved memory map for this platform: Just check the comment above and it will apply here. > + * 0x100000000 +------------------+ > + * | | > + * | Firmware Related | > + * | | > + * 0xd4d00000 +------------------+ > + * | | > + * | Kernel Available | > + * | | > + * 0xa7000000 +------------------+ > + * | | > + * | PIL Region | > + * | | > + * 0x8a800000 +------------------+ > + * | | > + * | Firmware Related | > + * | | > + * 0x80000000 +------------------+ > + * Note that: > + * 0xa7000000..0xA8000000 is used by bootloader, when kernel boot up, > + * it is available for kernel usage. This region is not suggested to > + * be used by kernel features like ramoops, suspend resume etc. > + */ > + > + /* > + * Firmware related regions, bootlader will possible reserve parts of spellcheck s/bootlader/bootloader > + * 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, bootlader will possible reserve parts of Ditto. > + * region from 0xd8000000..0x100000000. > + */ > + mpss_dsm_mem: mpss_dsm_region@d4d00000 { > + reg = <0x0 0xd4d00000 0x0 0x3300000>; > + no-map; > + }; > + }; > +};
On 5/14/2024 12:37 AM, Trilok Soni wrote: > On 5/13/2024 2:07 AM, Tengfei Fan wrote: >> QCS8550 is derived from SM8550. The differnece between SM8550 and > > spellcheck s/difference/difference > >> QCS8550 is QCS8550 doesn't have modem RF system. QCS8550 is mainly used >> in IoT scenarios. > > IoT products and not scenarios. > >> QCS8550 firmware has different memory map with SM8550 firmware. > > "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. OS bootloader conveys the > > Just "Bootloader conveys the information by updating devicetree at runtime" ? > >> information by update device tree in 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. > > I understand what you are trying to explain below, but can we simplify further? I > had to read multiple times to understand what you are trying to convey above. > >> 2. Firmware related memory regions which are shared with Kernel >> Each region has a specific node with specific label name for later >> phandle reference from other driver dt node. How about like this: 2. Firmware related memory regions which are shared with Kernel The device tree source in the kernel needs to include nodes that indicate firmware-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. PIL regions. > > Do we use the PIL - peripheral image loader in the upstream kernel or just remoteproc? > I am fine w/ PIL if it is used at other places in Qualcomm remoteproc. > >> PIL 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 | > > What is "kernel available" means? It means not reserved memory, normal available memory from kernel point of view. > >> | | >> 0xa7000000 +------------------+ >> | | >> | PIL Region | >> | | >> 0x8a800000 +------------------+ >> | | >> | Firmware Related | >> | | >> 0x80000000 +------------------+ > >> Note that: > > Do we need to write "Note that:" ? > >> 0xa7000000..0xA8000000 is used by bootloader, when kernel boot up, >> it is available for kernel usage. This region is not suggested to be >> used by kernel features like ramoops, suspend resume etc. >> >> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com> >> --- >> arch/arm64/boot/dts/qcom/qcs8550.dtsi | 169 ++++++++++++++++++++++++++ >> 1 file changed, 169 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..a3ebf3d4e16d >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi >> @@ -0,0 +1,169 @@ >> +// 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. OS bootloader >> + * conveys the information by update device tree in 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. >> + * Each region has a specific node with specific label name for >> + * later phandle reference from other driver dt node. >> + * 3. PIL regions. >> + * PIL regions will be reserved and then assigned to subsystem >> + * firmware later. >> + * Here is a reserved memory map for this platform: > > Just check the comment above and it will apply here. > >> + * 0x100000000 +------------------+ >> + * | | >> + * | Firmware Related | >> + * | | >> + * 0xd4d00000 +------------------+ >> + * | | >> + * | Kernel Available | >> + * | | >> + * 0xa7000000 +------------------+ >> + * | | >> + * | PIL Region | >> + * | | >> + * 0x8a800000 +------------------+ >> + * | | >> + * | Firmware Related | >> + * | | >> + * 0x80000000 +------------------+ >> + * Note that: >> + * 0xa7000000..0xA8000000 is used by bootloader, when kernel boot up, >> + * it is available for kernel usage. This region is not suggested to >> + * be used by kernel features like ramoops, suspend resume etc. >> + */ >> + >> + /* >> + * Firmware related regions, bootlader will possible reserve parts of > > spellcheck s/bootlader/bootloader > >> + * 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, bootlader will possible reserve parts of > > Ditto. > >> + * region from 0xd8000000..0x100000000. >> + */ >> + mpss_dsm_mem: mpss_dsm_region@d4d00000 { >> + reg = <0x0 0xd4d00000 0x0 0x3300000>; >> + no-map; >> + }; >> + }; >> +};
On 5/14/2024 9:21 AM, Aiqun Yu (Maria) wrote: > > > On 5/14/2024 12:37 AM, Trilok Soni wrote: >> On 5/13/2024 2:07 AM, Tengfei Fan wrote: >>> QCS8550 is derived from SM8550. The differnece between SM8550 and >> >> spellcheck s/difference/difference Typos wil be modified. >> >>> QCS8550 is QCS8550 doesn't have modem RF system. QCS8550 is mainly used >>> in IoT scenarios. >> >> IoT products and not scenarios. I will modify this description. >> >>> QCS8550 firmware has different memory map with SM8550 firmware. >> >> "QCS8550 firmware has different memory map compared to SM8550" >> >> >> The >>> memory map will be runtime added through bootloader. In the next version of the patch series, I will add "The" to make the sentence's grammar more complete. >> >> >>> 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. OS bootloader conveys the >> >> Just "Bootloader conveys the information by updating devicetree at runtime" ? I will modify this description. >> >>> information by update device tree in 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. >> >> I understand what you are trying to explain below, but can we simplify further? I >> had to read multiple times to understand what you are trying to convey above. >> >>> 2. Firmware related memory regions which are shared with Kernel >>> Each region has a specific node with specific label name for later >>> phandle reference from other driver dt node. > > How about like this: > 2. Firmware related memory regions which are shared with Kernel > The device tree source in the kernel needs to include nodes that > indicate firmware-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. PIL regions. >> >> Do we use the PIL - peripheral image loader in the upstream kernel or just remoteproc? >> I am fine w/ PIL if it is used at other places in Qualcomm remoteproc. We are only used for remoteproc in the upstream kernel, and I will remove the description related to PIL. >> >>> PIL 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 | >> >> What is "kernel available" means? > > It means not reserved memory, normal available memory from kernel point > of view. > >> >>> | | >>> 0xa7000000 +------------------+ >>> | | >>> | PIL Region | >>> | | >>> 0x8a800000 +------------------+ >>> | | >>> | Firmware Related | >>> | | >>> 0x80000000 +------------------+ >> >>> Note that: >> >> Do we need to write "Note that:" ? This "Note that:" will be removed. >> >>> 0xa7000000..0xA8000000 is used by bootloader, when kernel boot up, >>> it is available for kernel usage. This region is not suggested to be >>> used by kernel features like ramoops, suspend resume etc. >>> >>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >>> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com> >>> --- >>> arch/arm64/boot/dts/qcom/qcs8550.dtsi | 169 ++++++++++++++++++++++++++ >>> 1 file changed, 169 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..a3ebf3d4e16d >>> --- /dev/null >>> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi >>> @@ -0,0 +1,169 @@ >>> +// 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. OS bootloader >>> + * conveys the information by update device tree in 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. >>> + * Each region has a specific node with specific label name for >>> + * later phandle reference from other driver dt node. >>> + * 3. PIL regions. >>> + * PIL regions will be reserved and then assigned to subsystem >>> + * firmware later. >>> + * Here is a reserved memory map for this platform: >> >> Just check the comment above and it will apply here. Sure, I will modify these according to the comments above. >> >>> + * 0x100000000 +------------------+ >>> + * | | >>> + * | Firmware Related | >>> + * | | >>> + * 0xd4d00000 +------------------+ >>> + * | | >>> + * | Kernel Available | >>> + * | | >>> + * 0xa7000000 +------------------+ >>> + * | | >>> + * | PIL Region | >>> + * | | >>> + * 0x8a800000 +------------------+ >>> + * | | >>> + * | Firmware Related | >>> + * | | >>> + * 0x80000000 +------------------+ >>> + * Note that: >>> + * 0xa7000000..0xA8000000 is used by bootloader, when kernel boot up, >>> + * it is available for kernel usage. This region is not suggested to >>> + * be used by kernel features like ramoops, suspend resume etc. >>> + */ >>> + >>> + /* >>> + * Firmware related regions, bootlader will possible reserve parts of >> >> spellcheck s/bootlader/bootloader Typos wil be modified. >> >>> + * 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, bootlader will possible reserve parts of >> >> Ditto. Typos wil be modified. >> >>> + * region from 0xd8000000..0x100000000. >>> + */ >>> + mpss_dsm_mem: mpss_dsm_region@d4d00000 { >>> + reg = <0x0 0xd4d00000 0x0 0x3300000>; >>> + no-map; >>> + }; >>> + }; >>> +}; >
Add AIM300 AIoT support along with usb, ufs, regulators, serial, PCIe, and PMIC functions. AIM300 Series is a highly optimized family of modules designed to support AIoT applications. It integrates QCS8550 SoC, UFS and PMIC chip etc. Here is a diagram of AIM300 AIoT Carrie Board and SoM +--------------------------------------------------+ | AIM300 AIOT Carrier Board | | | | +-----------------+ | |power----->| Fixed regulator |---------+ | | +-----------------+ | | | | | | v VPH_PWR | | +----------------------------------------------+ | | | AIM300 SOM | | | | | |VPH_PWR | | | | v | | | | +-------+ +--------+ +------+ | | | | | UFS | | QCS8550| |PMIC | | | | | +-------+ +--------+ +------+ | | | | | | | +----------------------------------------------+ | | | | +----+ +------+ | | |USB | | UART | | | +----+ +------+ | +--------------------------------------------------+ The following functions have been verified: - uart - usb - ufs - PCIe - PMIC - display - adsp - cdsp - tlmm Documentation for qcs8550[1] and sm8550[2] [1] https://docs.qualcomm.com/bundle/publicresource/87-61717-1_REV_A_Qualcomm_QCS8550_QCM8550_Processors_Product_Brief.pdf [2] https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/Snapdragon-8-Gen-2-Product-Brief.pdf Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com> --- This patch series depends on patch series: "[PATCH v5 0/3] arm64: qcom-sm8[456]50: properly describe the PCIe Gen4x2 PHY AUX clock" https://lore.kernel.org/linux-arm-msm/20240502-topic-sm8x50-upstream-pcie-1-phy-aux-clk-v5-0-10c650cfeade@linaro.org/ "[PATCH] arm64: dts: qcom: sm8550: Move some common usb node settings to SoC dtsi" https://lore.kernel.org/linux-arm-msm/20240513084701.1658826-1-quic_tengfan@quicinc.com/ v7 -> v8: - rebase patch series on top of: https://lore.kernel.org/linux-arm-msm/20240502-topic-sm8x50-upstream-pcie-1-phy-aux-clk-v5-0-10c650cfeade@linaro.org/ - add pinctrl configurations for pcie0 and pcie1 in AIM300 SOM dtsi - move some common usb node settings to SoC dtsi - verified with dtb check, and result is expected, because those warnings are not introduced by current patch series. arch/arm64/boot/dts/qcom/sm8550.dtsi:3037.27-3092.6: Warning (avoid_unnecessary_addr_size): /soc@0/display-subsystem@ae00000/dsi@ae96000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property v6 -> v7: - correct typos in the commit message - move mdss_dsi0, mdss_dsi0_phy, pcie0_phy, pcie1_phy and usb_dp_qmpphy vdda supply to qcs8550-aim300.dtsi - move the perst and wake gpio settings of pcie0 and pcie1 to qcs8550-aim300.dtsi - move the clock frequency settings of pcie_1_phy_aux_clk, sleep_clk and xo_board to qcs8550-aim300.dtsi - verified with dtb check, and result is expected, because those warnings are not introduced by current patch series. arch/arm64/boot/dts/qcom/sm8550.dtsi:3037.27-3092.6: Warning (avoid_unnecessary_addr_size): /soc@0/display-subsystem@ae00000/dsi@ae96000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb: phy@1c0e000: clock-output-names: ['pcie1_pipe_clk'] is too short from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml# arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb: phy@1c0e000: #clock-cells:0:0: 1 was expected from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml# v5 -> v6: - move qcs8550 board info bebind sm8550 boards info in qcom.yaml v4 -> v5: - "2023-2024" instead of "2023~2024" for License - update patch commit message to previous comments and with an updated board diagram - use qcs8550.dtsi instead of qcm8550.dtsi - remove the reserved memory regions which will be handled by bootloader - remove pm8550_flash, pm8550_pwm nodes, Type-C USB/DP function node, remoteproc_mpss function node, audio sound DTS node, new patch will be updated after respective team's end to end full verification - address comments to vph_pwr, move vph_pwr node and related references to qcs8550-aim300-aiot.dts - use "regulator-vph-pwr" instead of "vph_pwr_regulator" - add pcie0I AND pcie1 support together - the following patches were applied, so remove these patches from new patch series: - https://lore.kernel.org/linux-arm-msm/20240119100621.11788-3-quic_tengfan@quicinc.com - https://lore.kernel.org/linux-arm-msm/20240119100621.11788-4-quic_tengfan@quicinc.com - verified with dtb check, and result is expected, because those warnings are not introduced by current patch series. DTC_CHK arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb arch/arm64/boot/dts/qcom/sm8550.dtsi:3015.27-3070.6: Warning (avoid_unnecessary_addr_size): /soc@0/display-subsystem@ae00000/dsi@ae96000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb: opp-table: opp-75000000:opp-hz:0: [75000000, 0, 0, 75000000, 0, 0, 0, 0] is too long from schema $id: http://devicetree.org/schemas/opp/opp-v2.yaml# arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb: opp-table: opp-150000000:opp-hz:0: [150000000, 0, 0, 150000000, 0, 0, 0, 0] is too long from schema $id: http://devicetree.org/schemas/opp/opp-v2.yaml# arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb: opp-table: opp-300000000:opp-hz:0: [300000000, 0, 0, 300000000, 0, 0, 0, 0] is too long from schema $id: http://devicetree.org/schemas/opp/opp-v2.yaml# arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dtb: opp-table: Unevaluated properties are not allowed ('opp-150000000', 'opp-300000000', 'opp-75000000' were unexpected) from schema $id: http://devicetree.org/schemas/opp/opp-v2.yaml# v3 -> v4: - use qcm8550.dtsi instead of qcs8550.dtsi, qcs8550 is a QCS version of qcm8550, another board with qcm8550 will be added later - add AIM300 AIoT board string in qcom.yaml file - add sm8550 and qcm8550 fallback compatible - add qcm8550 SoC id - add reserved memory map codes in qcm8550.dtsi - pm8010 and pmr73d are splited into carrier board DTS file. Because the regulators which in pm8550, pm8550ve and pm8550vs are present on the SoM. The regulators which in pm8010 and pmr73d are present on the carrier board. - stay VPH_PWR at qcs8550-aim300.dtsi file VPH_PWR is obtained by vonverting 12v voltage into 3.7 voltage with a 3.7v buck. VPH_PWR is power supply for regulators in AIM300 SOM. VPH_PWR regulator is defined in AIM300 SOM dtsi file. v2 -> v3: - introduce qcs8550.dtsi - separate fix dtc W=1 warning patch to another patch series v1 -> v2: - merge the splited dts patches into one patch - update dts file name from qcom8550-aim300.dts to qcs8550-aim300 dts - drop PCIe1 dts node due to it is not enabled - update display node name for drop sde characters previous discussion here: [1] v7: https://lore.kernel.org/linux-arm-msm/20240424024508.3857602-1-quic_tengfan@quicinc.com [2] v6 RESEND: https://lore.kernel.org/linux-arm-msm/20240401093843.2591147-1-quic_tengfan@quicinc.com [3] v6: https://lore.kernel.org/linux-arm-msm/20240308070432.28195-1-quic_tengfan@quicinc.com [4] v5: https://lore.kernel.org/linux-arm-msm/20240301134113.14423-1-quic_tengfan@quicinc.com [5] v4: https://lore.kernel.org/linux-arm-msm/20240119100621.11788-1-quic_tengfan@quicinc.com [6] v3: https://lore.kernel.org/linux-arm-msm/20231219005007.11644-1-quic_tengfan@quicinc.com [7] v2: https://lore.kernel.org/linux-arm-msm/20231207092801.7506-1-quic_tengfan@quicinc.com [8] v1: https://lore.kernel.org/linux-arm-msm/20231117101817.4401-1-quic_tengfan@quicinc.com Tengfei Fan (4): dt-bindings: arm: qcom: Document QCS8550 SoC and the AIM300 AIoT board arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi arm64: dts: qcom: add base AIM300 dtsi arm64: dts: qcom: aim300: add AIM300 AIoT .../devicetree/bindings/arm/qcom.yaml | 8 + arch/arm64/boot/dts/qcom/Makefile | 1 + .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 322 ++++++++++++++ arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi | 405 ++++++++++++++++++ arch/arm64/boot/dts/qcom/qcs8550.dtsi | 169 ++++++++ 5 files changed, 905 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: 6ba6c795dc73c22ce2c86006f17c4aa802db2a60