[PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths

[PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

Add the OPP tables for each CPU cluster (cpu0-1-2-3-4-5 & cpu6-7) to
permit scaling the Last Level Cache Controller (LLCC) and DDR frequency
by aggregating bandwidth requests of all CPU core with reference to the
current OPP they are configured in by the hardware.

The effect is proper caches & DDR frequency scaling when CPU cores
change frequency.

The OPP tables were built using the downstream memlat ddr & llcc tables
for each cluster types with the actual cpufreq LUT tables from running a
CQ8725S device.

Also add the interconnect entry for each cpu, with 2 different paths:
- CPU to Last Level Cache Controller (LLCC)
- Last Level Cache Controller (LLCC) to DDR

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
---
 arch/arm64/boot/dts/qcom/sm8750.dtsi | 200 +++++++++++++++++++++++++++++++++++
 1 file changed, 200 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index fafed417c66fc2..6f44c393649918 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -44,6 +44,11 @@ cpu0: cpu@0 {
 			next-level-cache = <&l2_0>;
 			power-domains = <&cpu_pd0>, <&scmi_dvfs 0>;
 			power-domain-names = "psci", "perf";
+			operating-points-v2 = <&cpu0_opp_table>;
+			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
+					<&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
 			#cooling-cells = <2>;
 
 			l2_0: l2-cache {
@@ -61,6 +66,11 @@ cpu1: cpu@100 {
 			next-level-cache = <&l2_0>;
 			power-domains = <&cpu_pd1>, <&scmi_dvfs 0>;
 			power-domain-names = "psci", "perf";
+			operating-points-v2 = <&cpu0_opp_table>;
+			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
+					<&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
 			#cooling-cells = <2>;
 		};
 
@@ -72,6 +82,11 @@ cpu2: cpu@200 {
 			next-level-cache = <&l2_0>;
 			power-domains = <&cpu_pd2>, <&scmi_dvfs 0>;
 			power-domain-names = "psci", "perf";
+			operating-points-v2 = <&cpu0_opp_table>;
+			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
+					<&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
 			#cooling-cells = <2>;
 		};
 
@@ -83,6 +98,11 @@ cpu3: cpu@300 {
 			next-level-cache = <&l2_0>;
 			power-domains = <&cpu_pd3>, <&scmi_dvfs 0>;
 			power-domain-names = "psci", "perf";
+			operating-points-v2 = <&cpu0_opp_table>;
+			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
+					<&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
 			#cooling-cells = <2>;
 		};
 
@@ -94,6 +114,11 @@ cpu4: cpu@400 {
 			next-level-cache = <&l2_0>;
 			power-domains = <&cpu_pd4>, <&scmi_dvfs 0>;
 			power-domain-names = "psci", "perf";
+			operating-points-v2 = <&cpu0_opp_table>;
+			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
+					<&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
 			#cooling-cells = <2>;
 		};
 
@@ -105,6 +130,11 @@ cpu5: cpu@500 {
 			next-level-cache = <&l2_0>;
 			power-domains = <&cpu_pd5>, <&scmi_dvfs 0>;
 			power-domain-names = "psci", "perf";
+			operating-points-v2 = <&cpu0_opp_table>;
+			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
+					<&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
 			#cooling-cells = <2>;
 		};
 
@@ -116,6 +146,11 @@ cpu6: cpu@10000 {
 			next-level-cache = <&l2_1>;
 			power-domains = <&cpu_pd6>, <&scmi_dvfs 1>;
 			power-domain-names = "psci", "perf";
+			operating-points-v2 = <&cpu6_opp_table>;
+			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
+					<&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
 			#cooling-cells = <2>;
 
 			l2_1: l2-cache {
@@ -133,6 +168,11 @@ cpu7: cpu@10100 {
 			next-level-cache = <&l2_1>;
 			power-domains = <&cpu_pd7>, <&scmi_dvfs 1>;
 			power-domain-names = "psci", "perf";
+			operating-points-v2 = <&cpu6_opp_table>;
+			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
+					<&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
 			#cooling-cells = <2>;
 		};
 
@@ -256,6 +296,166 @@ memory@a0000000 {
 		reg = <0x0 0xa0000000 0x0 0x0>;
 	};
 
+	cpu0_opp_table: opp-table-cpu0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-384000000 {
+			opp-hz = /bits/ 64 <384000000>;
+			opp-peak-kBps = <(547000 * 16) (350000 * 4)>;
+		};
+
+		opp-556800000 {
+			opp-hz = /bits/ 64 <556800000>;
+			opp-peak-kBps = <(547000 * 16) (350000 * 4)>;
+		};
+
+		opp-748800000 {
+			opp-hz = /bits/ 64 <748800000>;
+			opp-peak-kBps = <(547000 * 16) (350000 * 4)>;
+		};
+
+		opp-960000000 {
+			opp-hz = /bits/ 64 <960000000>;
+			opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
+		};
+
+		opp-1152000000 {
+			opp-hz = /bits/ 64 <1152000000>;
+			opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
+		};
+
+		opp-1363200000 {
+			opp-hz = /bits/ 64 <1363200000>;
+			opp-peak-kBps = <(1555000 * 16) (350000 * 4)>;
+		};
+
+		opp-1555200000 {
+			opp-hz = /bits/ 64 <1555200000>;
+			opp-peak-kBps = <(1555000 * 16) (350000 * 4)>;
+		};
+
+		opp-1785600000 {
+			opp-hz = /bits/ 64 <1785600000>;
+			opp-peak-kBps = <(2092000 * 16) (533000 * 4)>;
+		};
+
+		opp-1996800000 {
+			opp-hz = /bits/ 64 <1996800000>;
+			opp-peak-kBps = <(2092000 * 16) (533000 * 4)>;
+		};
+
+		opp-2227200000 {
+			opp-hz = /bits/ 64 <2227200000>;
+			opp-peak-kBps = <(2092000 * 16) (533000 * 4)>;
+		};
+
+		opp-2400000000 {
+			opp-hz = /bits/ 64 <2400000000>;
+			opp-peak-kBps = <(2092000 * 16) (533000 * 4)>;
+		};
+
+		opp-2745600000 {
+			opp-hz = /bits/ 64 <2745600000>;
+			opp-peak-kBps = <(3187000 * 16) (806000 * 4)>;
+		};
+
+		opp-2918400000 {
+			opp-hz = /bits/ 64 <2918400000>;
+			opp-peak-kBps = <(3187000 * 16) (806000 * 4)>;
+		};
+
+		opp-3072000000 {
+			opp-hz = /bits/ 64 <3072000000>;
+			opp-peak-kBps = <(3686000 * 16) (933000 * 4)>;
+		};
+
+		opp-3321600000 {
+			opp-hz = /bits/ 64 <3321600000>;
+			opp-peak-kBps = <(3686000 * 16) (933000 * 4)>;
+		};
+
+		opp-3532800000 {
+			opp-hz = /bits/ 64 <3532800000>;
+			opp-peak-kBps = <(3686000 * 16) (933000 * 4)>;
+		};
+	};
+
+	cpu6_opp_table: opp-table-cpu6 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-1017600000 {
+			opp-hz = /bits/ 64 <1017600000>;
+			opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
+		};
+
+		opp-1209600000 {
+			opp-hz = /bits/ 64 <1209600000>;
+			opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
+		};
+
+		opp-1401600000 {
+			opp-hz = /bits/ 64 <1401600000>;
+			opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
+		};
+
+		opp-1689600000 {
+			opp-hz = /bits/ 64 <1689600000>;
+			opp-peak-kBps = <(2092000 * 16) (533000 * 4)>;
+		};
+
+		opp-1958400000 {
+			opp-hz = /bits/ 64 <1958400000>;
+			opp-peak-kBps = <(2092000 * 16) (533000 * 4)>;
+		};
+
+		opp-2246400000 {
+			opp-hz = /bits/ 64 <2246400000>;
+			opp-peak-kBps = <(3187000 * 16) (806000 * 4)>;
+		};
+
+		opp-2438400000 {
+			opp-hz = /bits/ 64 <2438400000>;
+			opp-peak-kBps = <(3187000 * 16) (806000 * 4)>;
+		};
+
+		opp-2649600000 {
+			opp-hz = /bits/ 64 <2649600000>;
+			opp-peak-kBps = <(3187000 * 16) (806000 * 4)>;
+		};
+
+		opp-2841600000 {
+			opp-hz = /bits/ 64 <2841600000>;
+			opp-peak-kBps = <(3686000 * 16) (933000 * 4)>;
+		};
+
+		opp-3072000000 {
+			opp-hz = /bits/ 64 <3072000000>;
+			opp-peak-kBps = <(3686000 * 16) (933000 * 4)>;
+		};
+
+		opp-3283200000 {
+			opp-hz = /bits/ 64 <3283200000>;
+			opp-peak-kBps = <(3686000 * 16) (933000 * 4)>;
+		};
+
+		opp-3513600000 {
+			opp-hz = /bits/ 64 <3513600000>;
+			opp-peak-kBps = <(4224000 * 16) (1066000 * 4)>;
+		};
+
+		opp-3801600000 {
+			opp-hz = /bits/ 64 <3801600000>;
+			opp-peak-kBps = <(4224000 * 16) (1066000 * 4)>;
+		};
+
+		opp-4089600000 {
+			opp-hz = /bits/ 64 <4089600000>;
+			opp-peak-kBps = <(4224000 * 16) (1066000 * 4)>;
+		};
+	};
+
 	pmu {
 		compatible = "arm,armv8-pmuv3";
 		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;

---
base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
change-id: 20260605-sm8750-ddr-bw-scaling-9c32b8360ab8

Best regards,
-- 
Aaron Kling <webgeek1234@gmail.com>

Re: [PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The SCMI cpufreq driver ignores DT `operating-points-v2` and interconnect properties, leaving LLCC and DDR bandwidth unscaled despite commit message claims.
--

commit a13e6fe2fe07b0245da4da3915362899fce3df5b
Author: Aaron Kling <webgeek1234@gmail.com>

arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths

This commit adds operating-points-v2 tables and interconnect paths to the
CPU nodes for the SM8750. The stated goal is to scale LLCC and DDR
frequency based on the CPU cores' current hardware operating point.

> diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
> index fafed417c66fc..6f44c39364991 100644
> --- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
> @@ -44,6 +44,11 @@ cpu0: cpu@0 {
>  			next-level-cache = <&l2_0>;
>  			power-domains = <&cpu_pd0>, <&scmi_dvfs 0>;
>  			power-domain-names = "psci", "perf";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> +					 &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
> +					<&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
> +					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;

[Severity: Medium]
Will these device tree properties be parsed and used by the active cpufreq
driver?

Since this CPU is managed by the SCMI protocol (as indicated by the
scmi_dvfs power domain), the SCMI cpufreq driver dynamically fetches OPPs
directly from firmware.

It appears the SCMI drivers bypass parsing the device tree
operating-points-v2 tables entirely, meaning the OPP core won't trigger
bandwidth scaling during CPU frequency transitions. Does this leave the LLCC
and DDR bandwidth unscaled, contrary to the commit message?

[ ... ]

> +	cpu0_opp_table: opp-table-cpu0 {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp-384000000 {
> +			opp-hz = /bits/ 64 <384000000>;
> +			opp-peak-kBps = <(547000 * 16) (350000 * 4)>;

[Severity: Medium]
Is this bandwidth scaling data accessible if SCMI is handling the OPPs?

Because the SCMI cpufreq driver doesn't use dev_pm_opp_of_add_table(),
these static bandwidth mappings appear to be inert dead code. Is there
another mechanism being used to pass this interconnect bandwidth data
alongside the SCMI managed operating points?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605-sm8750-ddr-bw-scaling-v1-1-f39f918c95a7@gmail.com?part=1

Re: [PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths

[Konrad Dybcio]

On 6/6/26 12:36 AM, Aaron Kling via B4 Relay wrote:
> From: Aaron Kling <webgeek1234@gmail.com>
> 
> Add the OPP tables for each CPU cluster (cpu0-1-2-3-4-5 & cpu6-7) to
> permit scaling the Last Level Cache Controller (LLCC) and DDR frequency
> by aggregating bandwidth requests of all CPU core with reference to the
> current OPP they are configured in by the hardware.
> 
> The effect is proper caches & DDR frequency scaling when CPU cores
> change frequency.
> 
> The OPP tables were built using the downstream memlat ddr & llcc tables
> for each cluster types with the actual cpufreq LUT tables from running a
> CQ8725S device.
> 
> Also add the interconnect entry for each cpu, with 2 different paths:
> - CPU to Last Level Cache Controller (LLCC)
> - Last Level Cache Controller (LLCC) to DDR
> 
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
> arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
> ---

[...]

> +	cpu6_opp_table: opp-table-cpu6 {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp-1017600000 {
> +			opp-hz = /bits/ 64 <1017600000>;
> +			opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;

I think this should be * 4 in both cases since the interconnect driver
ignores the channel count for a node in peak voting. We may have a bug
in all other DTs here.

BTW, are there no lower OPPs for the fast cores?

Konrad

Re: [PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths

[Aaron Kling]

On Wed, Jun 17, 2026 at 5:41 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 6/6/26 12:36 AM, Aaron Kling via B4 Relay wrote:
> > From: Aaron Kling <webgeek1234@gmail.com>
> >
> > Add the OPP tables for each CPU cluster (cpu0-1-2-3-4-5 & cpu6-7) to
> > permit scaling the Last Level Cache Controller (LLCC) and DDR frequency
> > by aggregating bandwidth requests of all CPU core with reference to the
> > current OPP they are configured in by the hardware.
> >
> > The effect is proper caches & DDR frequency scaling when CPU cores
> > change frequency.
> >
> > The OPP tables were built using the downstream memlat ddr & llcc tables
> > for each cluster types with the actual cpufreq LUT tables from running a
> > CQ8725S device.
> >
> > Also add the interconnect entry for each cpu, with 2 different paths:
> > - CPU to Last Level Cache Controller (LLCC)
> > - Last Level Cache Controller (LLCC) to DDR
> >
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
> > arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
> > ---
>
> [...]
>
> > +     cpu6_opp_table: opp-table-cpu6 {
> > +             compatible = "operating-points-v2";
> > +             opp-shared;
> > +
> > +             opp-1017600000 {
> > +                     opp-hz = /bits/ 64 <1017600000>;
> > +                     opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
>
> I think this should be * 4 in both cases since the interconnect driver
> ignores the channel count for a node in peak voting. We may have a bug
> in all other DTs here.

If this is confirmed, I can update this patch. I based the
calculations on my sm8550 copy of this change, which in turn was based
on the sm8650 change. If this is wrong, that means one piece is
scaling 4x too quickly? Making it a power consumption issue, not a
performance issue.

> BTW, are there no lower OPPs for the fast cores?

Not on cq8725s at least. These lists came from an AYN Odin 3 with that
soc. I don't have any sm8750 proper devices to see if that's any
different.

Aaron

Re: [PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths

[Konrad Dybcio]

On 18-Jun-26 06:37, Aaron Kling wrote:
> On Wed, Jun 17, 2026 at 5:41 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 6/6/26 12:36 AM, Aaron Kling via B4 Relay wrote:
>>> From: Aaron Kling <webgeek1234@gmail.com>
>>>
>>> Add the OPP tables for each CPU cluster (cpu0-1-2-3-4-5 & cpu6-7) to
>>> permit scaling the Last Level Cache Controller (LLCC) and DDR frequency
>>> by aggregating bandwidth requests of all CPU core with reference to the
>>> current OPP they are configured in by the hardware.
>>>
>>> The effect is proper caches & DDR frequency scaling when CPU cores
>>> change frequency.
>>>
>>> The OPP tables were built using the downstream memlat ddr & llcc tables
>>> for each cluster types with the actual cpufreq LUT tables from running a
>>> CQ8725S device.
>>>
>>> Also add the interconnect entry for each cpu, with 2 different paths:
>>> - CPU to Last Level Cache Controller (LLCC)
>>> - Last Level Cache Controller (LLCC) to DDR
>>>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>> ---
>>> arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
>>> ---
>>
>> [...]
>>
>>> +     cpu6_opp_table: opp-table-cpu6 {
>>> +             compatible = "operating-points-v2";
>>> +             opp-shared;
>>> +
>>> +             opp-1017600000 {
>>> +                     opp-hz = /bits/ 64 <1017600000>;
>>> +                     opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
>>
>> I think this should be * 4 in both cases since the interconnect driver
>> ignores the channel count for a node in peak voting. We may have a bug
>> in all other DTs here.
> 
> If this is confirmed, I can update this patch. I based the
> calculations on my sm8550 copy of this change, which in turn was based
> on the sm8650 change. If this is wrong, that means one piece is
> scaling 4x too quickly? Making it a power consumption issue, not a
> performance issue.
> 
>> BTW, are there no lower OPPs for the fast cores?
> 
> Not on cq8725s at least. These lists came from an AYN Odin 3 with that
> soc. I don't have any sm8750 proper devices to see if that's any
> different.

Mobile SM8750:

root@qcom-armv8a:~# cat /sys/bus/cpu/devices/cpu6/cpufreq/scaling_available_frequencies
1017600 1209600 1401600 1689600 1958400 2246400 2438400 2649600 2841600 3072000 3283200 3513600 3840000 4089600

root@qcom-armv8a:~# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies
384000 556800 748800 960000 1152000 1363200 1555200 1785600 1996800 2227200 2400000 2745600 2918400 3072000 3321600 3532800

root@qcom-armv8a:~# grep ^ /sys/bus/soc/devices/soc0/*
/sys/bus/soc/devices/soc0/family:Snapdragon
/sys/bus/soc/devices/soc0/machine:SM8750
/sys/bus/soc/devices/soc0/revision:2.0
/sys/bus/soc/devices/soc0/serial_number:<snip>
/sys/bus/soc/devices/soc0/soc_id:618

Konrad