Re: [PATCH 2/3] arm64: dts: qcom: Introduce Eliza Soc base dtsi

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---

[...]

> +		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@codeaurora.org/

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