Re: [PATCH 2/3] arm64: dts: qcom: Introduce Eliza Soc base dtsi
From: Konrad Dybcio
Date: Tue Feb 24 2026 - 08:07:19 EST
On 2/24/26 1:13 PM, Abel Vesa wrote:
> Introduce the initial support for the Qualcomm Eliza SoC.
> It is a high-tier SoC designed for mobile platforms.
>
> The initial submission enables support for:
> - CPU nodes with cpufreq and cpuidle support
> - Global Clock Controller (GCC)
> - Resource State Coordinator (RSC) with clock controller & genpd provider
> - Interrupt controller
> - Power Domain Controller (PDC)
> - Vendor specific SMMU
> - SPMI bus arbiter
> - Top Control and Status Register (TCSR)
> - Top Level Mode Multiplexer (TLMM)
> - Debug UART
> - Reserved memory nodes
> - Interconnect providers
> - System timer
> - UFS
>
> Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxxxxx>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxxxxx>
> Signed-off-by: Abel Vesa <abel.vesa@xxxxxxxxxxxxxxxx>
> ---
[...]
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu0>;
The values of the MPIDR register (also present in 'reg' of CPU nodes)
suggest all these CPUs form a single logical cluster
[...]
> + l3: l3-cache {
> + compatible = "cache";
> + cache-level = <3>;
> + cache-unified;
> + };
So far this has been defined as a child of one of the L2 caches, any
reason for a change?
[...]
> + firmware {
> + scm: scm {
> + compatible = "qcom,scm-eliza", "qcom,scm";
> + interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> + qcom,dload-mode = <&tcsr 0x1A000>;
lowercase hex, please
[...]
> + ufs_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-75000000 {
> + opp-hz = /bits/ 64 <75000000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <75000000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>;
> + required-opps = <&rpmhpd_opp_low_svs_d1>;
> + };
This OPP is not supported
> +
> + opp-100000000 {
> + opp-hz = /bits/ 64 <100000000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <100000000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
There's another one (201.5 MHz) @ SVS
[...]
> + tcsr: clock-controller@1fbf000 {
> + compatible = "qcom,eliza-tcsr", "syscon";
> + reg = <0x0 0x01fbf000 0x0 0x21000>;
> +
> + clocks = <&rpmhcc RPMH_CXO_CLK>;
> +
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
[...]
> + pdc: interrupt-controller@b220000 {
> + compatible = "qcom,eliza-pdc", "qcom,pdc";
> + reg = <0x0 0x0b220000 0x0 0x10000>,
sz=0x40_000
> + <0x0 0x174000f0 0x0 0x64>;
I see this region is allowed by bindings, but not consumed by the
upstream driver
On msm-x.y, this is acessed (optionally via SCM r/w calls) to write
APSS_SHARED_SPI_CONFIG_n..
Seems like Lina tried to get this upstream at one point, but the
discussion stalled
https://lore.kernel.org/linux-arm-msm/1568411962-1022-8-git-send-email-ilina@xxxxxxxxxxxxxx/
If I'm reading this right, we do indeed want this register write to
tell the firmware about the actual edge/level trigger that's requested,
but maybe we should do it via a syscon instead
> +
> + qcom,pdc-ranges = <0 480 8>, <8 719 1>, <9 718 1>,
> + <10 230 1>, <11 724 1>, <12 716 1>,
> + <13 727 1>, <14 720 1>, <15 726 1>,
> + <16 721 1>, <17 262 1>, <18 70 1>,
> + <19 723 1>, <20 234 1>, <22 725 1>,
> + <23 231 1>, <24 504 5>, <30 510 8>,
> + <40 520 6>, <51 531 4>, <58 538 2>,
> + <61 541 5>, <66 92 1>, <67 547 13>,
> + <80 240 1>, <81 235 1>, <82 310 2>,
> + <84 248 1>, <85 241 1>, <86 238 2>,
> + <88 254 1>, <89 509 1>, <90 563 1>,
> + <91 259 2>, <93 201 1>, <94 246 1>,
> + <95 93 1>, <96 611 29>, <125 63 1>,
> + <126 366 2>, <128 374 1>, <129 377 1>,
> + <130 428 1>, <131 434 2>, <133 437 1>,
> + <134 452 2>, <136 458 2>, <138 464 11>,
> + <149 671 1>, <150 688 1>, <151 714 2>,
> + <153 722 1>, <154 255 1>, <155 269 2>,
> + <157 276 1>, <158 287 1>, <159 306 4>;
I'm just going to trust you this is correct..
[...]
> + spmi_bus: spmi@c400000 {
> + compatible = "qcom,spmi-pmic-arb";
> + reg = <0x0 0x0c400000 0x0 0x3000>,
> + <0x0 0x0c500000 0x0 0x400000>,
> + <0x0 0x0c440000 0x0 0x80000>,
> + <0x0 0x0c4c0000 0x0 0x10000>,
> + <0x0 0x0c42d000 0x0 0x4000>;
The bus is partitioned, just like on Hamoa, please describe the
secondary one too
[...]
> + intc: interrupt-controller@17100000 {
> + compatible = "arm,gic-v3";
> + reg = <0x0 0x17100000 0x0 0x10000>,
> + <0x0 0x17180000 0x0 0x200000>;
> +
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + #interrupt-cells = <3>;
> + interrupt-controller;
> +
> + #redistributor-regions = <1>;
> + redistributor-stride = <0x0 0x40000>;
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + gic_its: msi-controller@17140000 {
> + compatible = "arm,gic-v3-its";
> + reg = <0x0 0x17140000 0x0 0x20000>;
This is supposed to be 0x40_000 long, otherwise GITS_SGIR is cut off
I see many DTs have this issue, I'll do a mass fixup
> + nsp_noc: interconnect@320c0000 {
> + compatible = "qcom,eliza-nsp-noc";
> + reg = <0x0 0x320c0000 0x0 0xe080>;
> + qcom,bcm-voters = <&apps_bcm_voter>;
> + #interconnect-cells = <2>;
> + };
> +
> + };
stray \n above
Konrad