Re: [PATCH v7 0/6] soc: qcom: add in-kernel pd-mapper implementation
On 24.04.2024 12:27, Dmitry Baryshkov wrote: Protection domain mapper is a QMI service providing mapping between 'protection domains' and services supported / allowed in these domains. For example such mapping is required for loading of the WiFi firmware or for properly starting up the UCSI / altmode / battery manager support. The existing userspace implementation has several issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't reread the JSON files if the firmware location is changed (or if the firmware was not available at the time pd-mapper was started but the corresponding directory is mounted later), etc. However this configuration is largely static and common between different platforms. Provide in-kernel service implementing static per-platform data. Unlike previous revisions of the patchset, this iteration uses static configuration per platform, rather than building it dynamically from the list of DSPs being started. To: Bjorn Andersson To: Konrad Dybcio To: Sibi Sankar To: Mathieu Poirier Cc: linux-arm-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-remotep...@vger.kernel.org Cc: Johan Hovold Cc: Xilin Wu Cc: "Bryan O'Donoghue" -- Changes in v7: - Fixed modular build (Steev) - Link to v6: https://lore.kernel.org/r/20240422-qcom-pd-mapper-v6-0-f96957d01...@linaro.org Changes in v6: - Reworked mutex to fix lockdep issue on deregistration - Fixed dependencies between PD-mapper and remoteproc to fix modular builds (Krzysztof) - Added EXPORT_SYMBOL_GPL to fix modular builds (Krzysztof) - Fixed kerneldocs (Krzysztof) - Removed extra pr_debug messages (Krzysztof) - Fixed wcss build (Krzysztof) - Added platforms which do not require protection domain mapping to silence the notice on those platforms - Link to v5: https://lore.kernel.org/r/20240419-qcom-pd-mapper-v5-0-e35b6f847...@linaro.org Changes in v5: - pdr: drop lock in pdr_register_listener, list_lock is already held (Chris Lew) - pd_mapper: reworked to provide static configuration per platform (Bjorn) - Link to v4: https://lore.kernel.org/r/20240311-qcom-pd-mapper-v4-0-24679cca5...@linaro.org Changes in v4: - Fixed missing chunk, reenabled kfree in qmi_del_server (Konrad) - Added configuration for sm6350 (Thanks to Luca) - Removed RFC tag (Konrad) - Link to v3: https://lore.kernel.org/r/20240304-qcom-pd-mapper-v3-0-6858fa1ac...@linaro.org Changes in RFC v3: - Send start / stop notifications when PD-mapper domain list is changed - Reworked the way PD-mapper treats protection domains, register all of them in a single batch - Added SC7180 domains configuration based on TCL Book 14 GO - Link to v2: https://lore.kernel.org/r/20240301-qcom-pd-mapper-v2-0-5d12a081d...@linaro.org Changes in RFC v2: - Swapped num_domains / domains (Konrad) - Fixed an issue with battery not working on sc8280xp - Added missing configuration for QCS404 I've tested this series on sdm660 device, with userspace pd-mapper service disabled, and don't see any regressions - e.g Wi-Fi/BT still come online and work as before. Debug logs: https://paste.sr.ht/~minlexx/bd03db4c582a3275078ce4fd05ea76ce46a52b8e Missing cdsp_root and adsp_sensors PDs are not currently an issue, because those are not enabled yet on SDM660 or hard to test, so Tested-by: Alexey Minnekhanov -- Regards, Alexey Minnekhanov postmarketOS developer
Re: [PATCH v7 5/6] soc: qcom: add pd-mapper implementation
On 24.04.2024 12:28, Dmitry Baryshkov wrote:
Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if firmware location is changed (or if firmware was
not available at the time pd-mapper was started but the corresponding
directory is mounted later), etc.
Provide in-kernel service implementing protection domain mapping
required to work with several services, which are provided by the DSP
firmware.
This module is loaded automatically by the remoteproc drivers when
necessary via the symbol dependency. It uses a root node to match a
protection domains map for a particular board. It is not possible to
implement it as a 'driver' as there is no corresponding device.
Signed-off-by: Dmitry Baryshkov
diff --git a/drivers/soc/qcom/qcom_pd_mapper.c
b/drivers/soc/qcom/qcom_pd_mapper.c
...
+
+static const struct qcom_pdm_domain_data *sdm660_domains[] = {
+ _audio_pd,
+ _root_pd,
+ _wlan_pd,
+ NULL,
+};
+
On my SDM660 device (xiaomi-lavender) I see also the following files on
modem partition:
- adsps.jsn with sensor_pd (instance id 74)
- cdspr.jsn with cdsp root_pd (instance id 76)
- modemr.jsn with root_pd (instance id 180)
I see these numbers match those you already have defined above, so
perhaps sdm660_domains should also have adsp_sensor_pd, cdsp_root_pd,
and mpss_root_pd?
I'm not sure how useful they are currently, as AFAIK cdsp is not added
to sdm660 DT at all; and ADSP sensors are very hard to use/test, needs
very special userspace...
--
Regards,
Alexey Minnekhanov
postmarketOS developer
[PATCH 1/2] ARM: dts: qcom: msm8974: add blsp2_uart8
Add blsp2_uart8 node in order to support bluetooth on the
Samsung Galaxy S5 phone.
Signed-off-by: Alexey Minnekhanov
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index d725f37d6b311..29bda8bacc235 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -742,6 +742,15 @@ blsp2_uart1: serial@f995d000 {
status = "disabled";
};
+ blsp2_uart8: serial@f995e000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0xf995e000 0x1000>;
+ interrupts = ;
+ clocks = < GCC_BLSP2_UART2_APPS_CLK>, <
GCC_BLSP2_AHB_CLK>;
+ clock-names = "core", "iface";
+ status = "disabled";
+ };
+
blsp2_uart10: serial@f996 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf996 0x1000>;
--
2.26.3
[PATCH 2/2] ARM: dts: qcom: msm8974-klte: Add bluetooth support
Broadcom BCM4354 is used on Samsung Galaxy S5 phone
on BLSP2 UART8 bus.
Signed-off-by: Alexey Minnekhanov
---
.../boot/dts/qcom-msm8974-samsung-klte.dts| 50 +++
1 file changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
b/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
index a0f7f461f48c8..138353cb4e1d6 100644
--- a/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
@@ -322,6 +322,27 @@ serial@f991e000 {
status = "okay";
};
+ /* blsp2_uart8 */
+ serial@f995e000 {
+ status = "okay";
+
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_uart8_pins_active>;
+ pinctrl-1 = <_uart8_pins_sleep>;
+
+ bluetooth {
+ compatible = "brcm,bcm43540-bt";
+ max-speed = <300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ device-wakeup-gpios = < 91 GPIO_ACTIVE_HIGH>;
+ shutdown-gpios = <_expander 9 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <>;
+ interrupts = <75 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "host-wakeup";
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
input-name = "gpio-keys";
@@ -356,6 +377,35 @@ volume-up {
};
pinctrl@fd51 {
+ blsp2_uart8_pins_active: blsp2-uart8-pins-active {
+ pins = "gpio45", "gpio46", "gpio47", "gpio48";
+ function = "blsp_uart8";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ blsp2_uart8_pins_sleep: blsp2-uart8-pins-sleep {
+ pins = "gpio45", "gpio46", "gpio47", "gpio48";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ bt_pins: bt-pins {
+ hostwake {
+ pins = "gpio75";
+ function = "gpio";
+ drive-strength = <16>;
+ input-enable;
+ };
+
+ devwake {
+ pins = "gpio91";
+ function = "gpio";
+ drive-strength = <2>;
+ };
+ };
+
sdhc1_pin_a: sdhc1-pin-active {
clk {
pins = "sdc1_clk";
--
2.26.3
Re: [PATCH] arm64: dts: qcom: sdm660: Fix CPU capacities
Hi!
I always had a feeling something is not right in those cpu
definitions, so cpus with reg 100-103 are little cores, and 0-3 big
ones?
But downstream sdm660.dtsi has a property "efficiency" [1] with values
which are larger for cores 100-103 than for 0-3 cores (1638 > 1024),
I'm confused...
Property "efficiency" is described in the same tree in [2].
[1]
https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/arch/arm/boot/dts/qcom/sdm660.dtsi?h=LA.UM.7.2.c25#n155
[2]
https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/Documentation/devicetree/bindings/arm/cpus.txt?h=LA.UM.7.2.c25#n216
вт, 12 янв. 2021 г. в 13:51, Danny Lin :
>
> sdm660 has a big.LITTLE 4+4 CPU setup with CPUs 0-3 being little cores
> and CPUs 4-7 being big cores. The big cores have higher IPC, so they
> should have the higher capacity-dmips-mhz, not the other way around as
> the device tree currently describes it. Fix the incorrect CPU map to
> improve EAS scheduling behavior.
>
> While we're at it, let's replace the old DMIPS/MHz values with new
> measurements that reflect the exact IPC of the CPUs as reported by
> CoreMark.
>
> Performance measurements were made using my freqbench [1]
> benchmark coordinator, which isolates, offlines, and disables the timer
> tick on test CPUs to maximize accuracy. It uses EEMBC CoreMark [2] as
> the workload and measures power usage using the PM660 PMIC's fuel
> gauge.
>
> Normalized DMIPS/MHz capacity scale values for each CPU were calculated
> from CoreMarks/MHz (CoreMark iterations per second per MHz), which
> serves the same purpose. For each CPU, the final capacity-dmips-mhz
> value is the C/MHz value of its maximum frequency normalized to
> SCHED_CAPACITY_SCALE (1024) for the fastest CPU in the system.
>
> A Xiaomi Redmi Note 7 device running a downstream Qualcomm 4.4 kernel
> was used for benchmarking to ensure proper frequency scaling and other
> low-level controls.
>
> Raw benchmark results can be found in the freqbench repository [3].
> Below is a human-readable summary:
>
> Frequency domains: cpu1 cpu4
> Offline CPUs: cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7
> Baseline power usage: 1130 mW
>
> = CPU 1 =
> Frequencies: 633 902 1113 1401 1536 1747 1843
>
> 633: 2058 3.2 C/MHz 48 mW5.9 J 42.6 I/mJ 121.5 s
> 902: 2930 3.2 C/MHz 72 mW6.2 J 40.6 I/mJ85.3 s
> 1113: 3616 3.2 C/MHz 79 mW5.4 J 46.0 I/mJ69.1 s
> 1401: 4551 3.2 C/MHz125 mW6.9 J 36.3 I/mJ54.9 s
> 1536: 4988 3.2 C/MHz134 mW6.7 J 37.1 I/mJ50.1 s
> 1747: 5674 3.2 C/MHz179 mW7.9 J 31.7 I/mJ44.1 s
> 1843: 5986 3.2 C/MHz228 mW9.5 J 26.3 I/mJ41.8 s
>
> = CPU 4 =
> Frequencies: 1113 1401 1747 1958 2150 2208
>
> 1113: 5825 5.2 C/MHz220 mW9.4 J 26.5 I/mJ42.9 s
> 1401: 7324 5.2 C/MHz317 mW 10.8 J 23.1 I/mJ34.1 s
> 1747: 9135 5.2 C/MHz474 mW 13.0 J 19.2 I/mJ27.4 s
> 1958: 10247 5.2 C/MHz578 mW 14.1 J 17.7 I/mJ24.4 s
> 2150: 11246 5.2 C/MHz694 mW 15.4 J 16.2 I/mJ22.2 s
> 2208: 11551 5.2 C/MHz736 mW 15.9 J 15.7 I/mJ21.7 s
>
> [1] https://github.com/kdrag0n/freqbench
> [2] https://www.eembc.org/coremark/
> [3] https://github.com/kdrag0n/freqbench/tree/master/results/sdm660/main
>
> Signed-off-by: Danny Lin
> ---
> arch/arm64/boot/dts/qcom/sdm660.dtsi | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi
> b/arch/arm64/boot/dts/qcom/sdm660.dtsi
> index 4abbdd03d1e7..ca985c5429db 100644
> --- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
> @@ -40,7 +40,7 @@ CPU0: cpu@100 {
> compatible = "qcom,kryo260";
> reg = <0x0 0x100>;
> enable-method = "psci";
> - capacity-dmips-mhz = <1024>;
> + capacity-dmips-mhz = <636>;
> next-level-cache = <_1>;
> L2_1: l2-cache {
> compatible = "cache";
> @@ -59,7 +59,7 @@ CPU1: cpu@101 {
> compatible = "qcom,kryo260";
> reg = <0x0 0x101>;
> enable-method = "psci";
> - capacity-dmips-mhz = <1024>;
> + capacity-dmips-mhz = <636>;
> next-level-cache = <_1>;
> L1_I_101: l1-icache {
> compatible = "cache";
> @@ -74,7 +74,7 @@ CPU2: cpu@102 {
> compatible = "qcom,kryo260";
> reg = <0x0 0x102>;
> enable-method = "psci";
> - capacity-dmips-mhz = <1024>;
> + capacity-dmips-mhz = <636>;
> next-level-cache = <_1>;
> L1_I_102:
[PATCH] ARM: dts: qcom: msm8974-klte: Fix shdc numbering
Since commit fa2d0aa96941 ("mmc: core: Allow setting slot index
via device tree alias") proper aliases should be named "mmcN".
Signed-off-by: Alexey Minnekhanov
---
arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
b/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
index 97352de9131422..f23d1002b8f8b9 100644
--- a/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
@@ -12,8 +12,8 @@ / {
aliases {
serial0 = _uart1;
- sdhc1 = _1; /* SDC1 eMMC slot */
- sdhc2 = _2; /* SDC2 SD card slot */
+ mmc0 = _1; /* SDC1 eMMC slot */
+ mmc1 = _2; /* SDC2 SD card slot */
};
chosen {
--
2.26.2
Re: [PATCH] drm/msm: Fix MSM_INFO_GET_IOVA with carveout
I've tested all recent GPU bring-up patches on msm8974pro samsung-klte
(a330v2) and with this patch everything is OK. But without this we're
getting the following in dmesg while running kmscube (which is rendering
nothing except black screen):
[ 94.969272] msm fd90.mdss: [drm:hangcheck_handler [msm]] *ERROR*
A330: hangcheck detected gpu lockup rb 0!
[ 94.970184] msm fd90.mdss: [drm:hangcheck_handler [msm]] *ERROR*
A330: completed fence: 0
[ 94.970873] msm fd90.mdss: [drm:hangcheck_handler [msm]] *ERROR*
A330: submitted fence: 1
[ 94.971600] msm fd90.mdss: [drm:recover_worker [msm]] *ERROR*
A330: hangcheck recover!
[ 94.972329] msm fd90.mdss: [drm:recover_worker [msm]] *ERROR*
A330: offending task: kmscube (kmscube)
[ 94.974101] revision: 330 (3.3.0.2)
[ 94.974117] rb 0: fence:0/1
[ 94.974129] rptr: 36
[ 94.974139] rb wptr: 36
[ 94.974148] CP_SCRATCH_REG0: 0
[ 94.974159] CP_SCRATCH_REG1: 0
[ 94.974169] CP_SCRATCH_REG2: 0
[ 94.974178] CP_SCRATCH_REG3: 0
[ 94.974188] CP_SCRATCH_REG4: 0
[ 94.974198] CP_SCRATCH_REG5: 0
[ 94.974208] CP_SCRATCH_REG6: 10
[ 94.974218] CP_SCRATCH_REG7: 12
So indeed partial revert of "if" condition fixes gpu at least on msm8974.
Tested-by: Alexey Minnekhanov
On 1/2/21 11:24 PM, Iskren Chernev wrote:
The msm_gem_get_iova should be guarded with gpu != NULL and not aspace
!= NULL, because aspace is NULL when using vram carveout.
Fixes: 933415e24bd0d ("drm/msm: Add support for private address space
instances")
Signed-off-by: Iskren Chernev
---
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index c5e61cb3356df..c1953fb079133 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -775,9 +775,10 @@ static int msm_ioctl_gem_info_iova(struct drm_device *dev,
struct drm_file *file, struct drm_gem_object *obj,
uint64_t *iova)
{
+ struct msm_drm_private *priv = dev->dev_private;
struct msm_file_private *ctx = file->driver_priv;
- if (!ctx->aspace)
+ if (!priv->gpu)
return -EINVAL;
/*
Re: [PATCH 1/4] ARM: dts: qcom: msm8974: add gpu support
Tested these patches on Samsung Galaxy S5 along with other patches that add panel driver and enable vram carve-out option on this device. Tested-by: Alexey Minnekhanov On 12/30/20 6:51 PM, Iskren Chernev wrote: From: Brian Masney Add support for the a3xx GPU Signed-off-by: Brian Masney --- arch/arm/boot/dts/qcom-msm8974.dtsi | 45 + 1 file changed, 45 insertions(+)
Re: [PATCH 1/2] drm/msm: Call msm_init_vram before binding the gpu
Tested these patches on Samsung Galaxy S5 along with other patches that add panel driver and enable GPU support on this device. Tested-by: Alexey Minnekhanov On 12/30/20 6:29 PM, Iskren Chernev wrote: From: Craig Tatlor vram.size is needed when binding a gpu without an iommu and is defined in msm_init_vram(), so run that before binding it. Signed-off-by: Craig Tatlor --- drivers/gpu/drm/msm/msm_drv.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
Re: [PATCH 4/4] ARM: dts: qcom: msm8974-klte: Mark essential regulators
This indeed fixes device freeze+reboot issue when display powers off. Tested-by: Alexey Minnekhanov On 12/30/20 6:51 PM, Iskren Chernev wrote: s1 and l12 regulators are used for the memory and cache on the Samsung S5 (klte). If they are turned off the phone shuts down. So mark them as always-on to prevent that from happening. Signed-off-by: Iskren Chernev --- arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts | 2 ++ 1 file changed, 2 insertions(+)
Re: [PATCH 2/2] drm/panel: simple: add samsung,s6e3fa2 panel
Tested this on Samsung Galaxy S5 along with other patches that enable GPU support on this device. Tested-by: Alexey Minnekhanov On 12/30/20 6:17 PM, Iskren Chernev wrote: From: Samuel Pascua This panel is used on the Samsung Galaxy S5 (klte). Signed-off-by: Samuel Pascua --- drivers/gpu/drm/panel/panel-simple.c | 30 1 file changed, 30 insertions(+)
Re: [PATCH v3 7/7] mailbox: qcom: Add sdm660 hmss compatible
Tue, 23 Jun. 2020. 10:29, Bjorn Andersson : > > On Mon 22 Jun 12:25 PDT 2020, Konrad Dybcio wrote: > > > Signed-off-by: Konrad Dybcio > > Reviewed-by: Bjorn Andersson > Hi, I can see dts file in linux-next using compatible "qcom,sdm660-apcs-hmss-global", but not this patch that adds it into the driver?
Re: [PATCH 4/8] clk: qcom: smd: Add support for SDM660 rpm clocks
I have almost identical patch in my working sdm660 kernel tree, maybe this can be counted as tested by? Tested-by: Alexey Minnekhanov пн, 22 июн. 2020 г. в 00:40, Konrad Dybcio : > > Add rpm smd clocks, PMIC and bus clocks which are required on > SDM630/660 (and APQ variants) for clients to vote on. > > Signed-off-by: Konrad Dybcio > ---
Re: [PATCH 6/8] arm64: dts: qcom: sdm630: Add sdm630 dts file
Parts of this are similar or identical to sdm660.dtsi. SoCs should be very similar. Maybe this can be reorganized, so that we have some common base between sdm630/660. I'd like to avoid copying such large amounts of code to sdm660 .dtsi file.. пн, 22 июн. 2020 г. в 00:39, Konrad Dybcio : > > Add devicetree files for SDM630 SoC and its pin configuration. > This commit adds basic nodes like cpu, psci and other required > configuration for booting up from eMMC to the serial console. > > Signed-off-by: Konrad Dybcio
Re: [PATCH 3/8] soc: qcom: socinfo: Add socinfo entry for SDM630
Hi,
I also wanted to send this, but in this form:
[PATCH] soc: qcom: socinfo: Add soc information for SDM630/636/660
Add socinfo support for SDM630/636/660.
---
drivers/soc/qcom/socinfo.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 5983c6ffb078..398a3c77954e 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -202,8 +202,14 @@ static const struct soc_id soc_id[] = {
{ 310, "MSM8996AU" },
{ 311, "APQ8096AU" },
{ 312, "APQ8096SG" },
+ { 317, "SDM660" },
+ { 318, "SDM630" },
{ 321, "SDM845" },
+ { 324, "SDA660" },
+ { 327, "SDA630" },
{ 341, "SDA845" },
+ { 345, "SDM636" },
+ { 346, "SDA636" },
};
I think it would be great to have all IDs of compatible SoCs at once.
I've tested it on my sdm660 by adding some printks in probe:
[ 1.609040] socinfo: family = Snapdragon
[ 1.609043] socinfo: machine = SDM660
[ 1.619712] socinfo: soc_id = 317
[ 1.630347] socinfo: revision = 1.0
пн, 22 июн. 2020 г. в 00:40, Konrad Dybcio :
>
> This patch adds missing soc ID for SDM630.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/soc/qcom/socinfo.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
> index 5983c6ffb078..705f142ee588 100644
> --- a/drivers/soc/qcom/socinfo.c
> +++ b/drivers/soc/qcom/socinfo.c
> @@ -202,6 +202,7 @@ static const struct soc_id soc_id[] = {
> { 310, "MSM8996AU" },
> { 311, "APQ8096AU" },
> { 312, "APQ8096SG" },
> + { 318, "SDM630" },
> { 321, "SDM845" },
> { 341, "SDA845" },
> };
> --
> 2.27.0
>
