Re: [PATCH v2 14/15] arm64: dts: qcom: Add initial Milos dtsi

["Luca Weiss" <luca.weiss@fairphone.com>]

On Mon Jul 14, 2025 at 1:06 PM CEST, Konrad Dybcio wrote:
> On 7/13/25 10:05 AM, Luca Weiss wrote:
>> Add a devicetree description for the Milos SoC, which is for example
>> Snapdragon 7s Gen 3 (SM7635).
>> 
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>
> [...]
>
>> +		cpu-map {
>> +			cluster0 {
>> +				core0 {
>> +					cpu = <&cpu0>;
>> +				};
>> +
>> +				core1 {
>> +					cpu = <&cpu1>;
>> +				};
>> +
>> +				core2 {
>> +					cpu = <&cpu2>;
>> +				};
>> +
>> +				core3 {
>> +					cpu = <&cpu3>;
>> +				};
>> +			};
>> +
>> +			cluster1 {
>> +				core0 {
>> +					cpu = <&cpu4>;
>> +				};
>> +
>> +				core1 {
>> +					cpu = <&cpu5>;
>> +				};
>> +
>> +				core2 {
>> +					cpu = <&cpu6>;
>> +				};
>> +			};
>> +
>> +			cluster2 {
>> +				core0 {
>> +					cpu = <&cpu7>;
>> +				};
>> +			};
>> +		};
>
> I'm getting mixed information about the core topology.. 
>
> What does dmesg say wrt this line?
>
> CPU%u: Booted secondary processor 0x%010lx [0x%08x]\n

[    0.003570] CPU1: Booted secondary processor 0x0000000100 [0x410fd801]
[    0.004738] CPU2: Booted secondary processor 0x0000000200 [0x410fd801]
[    0.005783] CPU3: Booted secondary processor 0x0000000300 [0x410fd801]
[    0.007206] CPU4: Booted secondary processor 0x0000000400 [0x410fd811]
[    0.008206] CPU5: Booted secondary processor 0x0000000500 [0x410fd811]
[    0.009073] CPU6: Booted secondary processor 0x0000000600 [0x410fd811]
[    0.010406] CPU7: Booted secondary processor 0x0000000700 [0x410fd811]

>
>> +	pmu-a520 {
>> +		compatible = "arm,cortex-a520-pmu";
>> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
>> +	};
>> +
>> +	pmu-a720 {
>> +		compatible = "arm,cortex-a720-pmu";
>> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
>> +	};
>
> See:
>
> 9ce52e908bd5 ("arm64: dts: qcom: sm8650: switch to interrupt-cells 4 to add PPI partitions")
> 2c06e0797c32 ("arm64: dts: qcom: sm8650: add PPI interrupt partitions for the ARM PMUs")

Sure, will take a look.

>
> [...]
>
>> +		gcc: clock-controller@100000 {
>> +			compatible = "qcom,milos-gcc";
>> +			reg = <0x0 0x00100000 0x0 0x1f4200>;
>> +
>> +			clocks = <&rpmhcc RPMH_CXO_CLK>,
>> +				 <&sleep_clk>,
>> +				 <0>, /* pcie_0_pipe_clk */
>> +				 <0>, /* pcie_1_pipe_clk */
>> +				 <0>, /* ufs_phy_rx_symbol_0_clk */
>> +				 <0>, /* ufs_phy_rx_symbol_1_clk */
>> +				 <0>, /* ufs_phy_tx_symbol_0_clk */
>> +				 <0>; /* usb3_phy_wrapper_gcc_usb30_pipe_clk */
>> +			protected-clocks = <GCC_PCIE_1_AUX_CLK>, <GCC_PCIE_1_AUX_CLK_SRC>,
>> +					<GCC_PCIE_1_CFG_AHB_CLK>, <GCC_PCIE_1_MSTR_AXI_CLK>,
>> +					<GCC_PCIE_1_PHY_RCHNG_CLK>, <GCC_PCIE_1_PHY_RCHNG_CLK_SRC>,
>> +					<GCC_PCIE_1_PIPE_CLK>, <GCC_PCIE_1_PIPE_CLK_SRC>,
>> +					<GCC_PCIE_1_PIPE_DIV2_CLK>, <GCC_PCIE_1_PIPE_DIV2_CLK_SRC>,
>> +					<GCC_PCIE_1_SLV_AXI_CLK>, <GCC_PCIE_1_SLV_Q2A_AXI_CLK>;
>
> Does access control disallow accessing these on your prod-fused
> device?

Hm, taking another look, this property should probably be moved to
device dts.

Downstream has this in volcano.dtsi but volcano6i.dtsi (QCM6690?) and
volcano6ip.dtsi (QCS6690?) have a /delete-property/ for this, because
they have PCIe available.

I don't think this has anything to do with secure boot fuses, but I
don't think I have tried enabling these clocks on my SB-off prototype.

>
> [...]
>
>> +		usb_1: usb@a600000 {
>> +			compatible = "qcom,milos-dwc3", "qcom,snps-dwc3";
>> +			reg = <0x0 0x0a600000 0x0 0x10000>;
>
> size = 0xfc_000

Ack

>
> [...]
>
>> +
>> +			clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
>> +				 <&gcc GCC_USB30_PRIM_MASTER_CLK>,
>> +				 <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
>> +				 <&gcc GCC_USB30_PRIM_SLEEP_CLK>,
>> +				 <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
>> +				 <&rpmhcc RPMH_CXO_CLK>;
>> +			clock-names = "cfg_noc",
>> +				      "core",
>> +				      "iface",
>> +				      "sleep",
>> +				      "mock_utmi",
>> +				      "xo";
>> +
>> +			assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
>> +					  <&gcc GCC_USB30_PRIM_MASTER_CLK>;
>> +			assigned-clock-rates = <19200000>, <133333333>;
>
> Set the latter to 200000000 - your device doesn't have USB3, but the
> next person may lose their hair about tracking down why it doesn't
> work on theirs

Ah, I think I only checked the downstream reference which was patched to
be qcom,core-clk-rate = <133333333>; for FP6. The original file does
have:

  qcom,core-clk-rate = <200000000>;
  qcom,core-clk-rate-disconnected = <133333333>;

>
> [...]
>
>> +		pdc: interrupt-controller@b220000 {
>> +			compatible = "qcom,milos-pdc", "qcom,pdc";
>> +			reg = <0x0 0x0b220000 0x0 0x30000>, <0x0 0x174000f0 0x0 0x64>;
>
> 1 per line, please

Ack

>
>> +			interrupt-parent = <&intc>;
>> +
>> +			qcom,pdc-ranges = <0 480 40>, <40 140 11>, <51 527 47>,
>> +					  <98 609 31>, <129 63 1>, <130 716 12>,
>> +					  <142 251 5>;
>> +
>> +			#interrupt-cells = <2>;
>> +			interrupt-controller;
>> +		};
>> +
>> +		tsens0: thermal-sensor@c228000 {
>> +			compatible = "qcom,milos-tsens", "qcom,tsens-v2";
>> +			reg = <0x0 0x0c228000 0x0 0x1ff>, /* TM */
>> +			      <0x0 0x0c222000 0x0 0x1ff>; /* SROT */
>
> drop the comments
>
> the sizes are 0x1000 for both regions for both controllers

Ack

>
>> +
>> +			interrupts = <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH>,
>
> pdc 26

You mean replace <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH> with
<&pdc 26 IRQ_TYPE_LEVEL_HIGH> (plus interrupts-extended)?

I assume you got this from internal docs, but just to mention,
volcano-thermal.dtsi contains GIC_SPI 506 (+ 507 for tsens1).

>
>> +				     <GIC_SPI 640 IRQ_TYPE_LEVEL_HIGH>;
>> +			interrupt-names = "uplow",
>> +					  "critical";
>> +
>> +			#qcom,sensors = <15>;
>> +
>> +			#thermal-sensor-cells = <1>;
>> +		};
>> +
>> +		tsens1: thermal-sensor@c229000 {
>> +			compatible = "qcom,milos-tsens", "qcom,tsens-v2";
>> +			reg = <0x0 0x0c229000 0x0 0x1ff>, /* TM */
>> +			      <0x0 0x0c223000 0x0 0x1ff>; /* SROT */
>> +
>> +			interrupts = <GIC_SPI 507 IRQ_TYPE_LEVEL_HIGH>,
>
> pdc 27

same as above

>
>> +				     <GIC_SPI 641 IRQ_TYPE_LEVEL_HIGH>;
>> +			interrupt-names = "uplow",
>> +					  "critical";
>> +
>> +			#qcom,sensors = <14>;
>> +
>> +			#thermal-sensor-cells = <1>;
>> +		};
>> +
>> +		aoss_qmp: power-management@c300000 {
>> +			compatible = "qcom,milos-aoss-qmp", "qcom,aoss-qmp";
>> +			reg = <0x0 0x0c300000 0x0 0x400>;
>> +
>> +			interrupt-parent = <&ipcc>;
>> +			interrupts-extended = <&ipcc IPCC_CLIENT_AOP IPCC_MPROC_SIGNAL_GLINK_QMP
>> +						     IRQ_TYPE_EDGE_RISING>;
>> +
>> +			mboxes = <&ipcc IPCC_CLIENT_AOP IPCC_MPROC_SIGNAL_GLINK_QMP>;
>> +
>> +			#clock-cells = <0>;
>> +		};
>> +
>> +		sram@c3f0000 {
>> +			compatible = "qcom,rpmh-stats";
>> +			reg = <0x0 0x0c3f0000 0x0 0x400>;
>> +		};
>> +
>> +		spmi_bus: spmi@c400000 {
>> +			compatible = "qcom,spmi-pmic-arb";
>
> There's two bus instances on this platform, check out the x1e binding

Will do

>
> [...]
>
>> +		intc: interrupt-controller@17100000 {
>> +			compatible = "arm,gic-v3";
>> +			reg = <0x0 0x17100000 0x0 0x10000>,	/* GICD */
>> +			      <0x0 0x17180000 0x0 0x200000>;	/* GICR * 8 */
>
> drop the comments please

Ack

>
> [...]
>
>> +			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
>> +			clock-names = "xo", "alternate";
>
> 1 a line, please

Ack

>
> [...]
>
>> +		cpuss0-thermal {
>> +			thermal-sensors = <&tsens0 1>;
>> +
>> +			trips {
>> +				cpuss0-hot {
>> +					temperature = <110000>;
>> +					hysteresis = <1000>;
>> +					type = "hot";
>> +				};
>> +
>> +				cpuss0-critical {
>> +					temperature = <115000>;
>> +					hysteresis = <0>;
>> +					type = "critical";
>> +				};
>> +			};
>> +		};
>
> See:
>
> 06eadce93697 ("arm64: dts: qcom: x1e80100: Drop unused passive thermal trip points for CPU")
>
> (tldr drop non-critical trips for CPU)

Will take a look.

Regards
Luca

>
> Konrad