linux.git/include/soc/qcom, branch v6.6.132

soc: qcom: ice: introduce devm_of_qcom_ice_get

2025-05-02T05:50:37+00:00

[ Upstream commit 1c13d6060d612601a61423f2e8fbf9e48126acca ]

Callers of of_qcom_ice_get() leak the device reference taken by
of_find_device_by_node(). Introduce devm variant for of_qcom_ice_get().
Existing consumers need the ICE instance for the entire life of their
device, thus exporting qcom_ice_put() is not required.

Signed-off-by: Tudor Ambarus 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Abel Vesa 
Reviewed-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20250117-qcom-ice-fix-dev-leak-v2-1-1ffa5b6884cb@linaro.org
Signed-off-by: Bjorn Andersson 
Stable-dep-of: cbef7442fba5 ("mmc: sdhci-msm: fix dev reference leaked through of_qcom_ice_get")
Signed-off-by: Sasha Levin

soc: qcom: rpmh-rsc: Enhance check for VRM in-flight request

2024-06-16T11:47:33+00:00

commit f592cc5794747b81e53b53dd6e80219ee25f0611 upstream.

Each RPMh VRM accelerator resource has 3 or 4 contiguous 4-byte aligned
addresses associated with it. These control voltage, enable state, mode,
and in legacy targets, voltage headroom. The current in-flight request
checking logic looks for exact address matches. Requests for different
addresses of the same RPMh resource as thus not detected as in-flight.

Add new cmd-db API cmd_db_match_resource_addr() to enhance the in-flight
request check for VRM requests by ignoring the address offset.

This ensures that only one request is allowed to be in-flight for a given
VRM resource. This is needed to avoid scenarios where request commands are
carried out by RPMh hardware out-of-order leading to LDO regulator
over-current protection triggering.

Fixes: 658628e7ef78 ("drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs")
Cc: stable@vger.kernel.org
Reviewed-by: Konrad Dybcio 
Tested-by: Elliot Berman  # sm8650-qrd
Signed-off-by: Maulik Shah 
Link: https://lore.kernel.org/r/20240215-rpmh-rsc-fixes-v4-1-9cbddfcba05b@quicinc.com
Signed-off-by: Bjorn Andersson 
Signed-off-by: Greg Kroah-Hartman

soc: qcom: socinfo: rename PM2250 to PM4125

2024-03-26T22:19:23+00:00

[ Upstream commit 5155e48128826d0c5999dc9f47aa746df54da448 ]

It seems, the only actual mentions of PM2250 can be found are related to
the Qualcomm RB1 platform. However even RB1 schematics use PM4125 as a
PMIC name. Rename PM2250 to PM4125 to follow the documentation.

Fixes: 082f9bc60f33 ("soc: qcom: spmi-pmic: add more PMIC SUBTYPE IDs")
Fixes: 112d96fd2927 ("soc: qcom: socinfo: Add some PMICs")
Acked-by: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20240128-pm2250-pm4125-rename-v2-1-d51987e9f83a@linaro.org
Signed-off-by: Bjorn Andersson 
Signed-off-by: Sasha Levin

soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver

2023-04-07T19:08:39+00:00

This takes the already existing duplicated support in both ufs-qcom
and sdhci-msm drivers and makes it a dedicated driver that can be used
by both mentioned drivers.

The reason for this is because, staring with SM8550, the ICE IP block
is shared between UFS and SDCC, which means we need to probe a dedicated
device and share it between those two consumers.

So let's add the ICE dedicated driver as a soc driver.

Platforms that already have ICE supported, will use it as a library
as the of_qcom_ice_get will return an ICE instance created for the
consumer device. This allows the backwards compatibility with old-style
devicetree approach.

Also, add support to HW version 4.x since it works out-of-the-box with
the current driver. The 4.x HW version is found on SM8550 platform.

Signed-off-by: Abel Vesa 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20230407105029.2274111-4-abel.vesa@linaro.org

soc: qcom: spmi-pmic: add more PMIC SUBTYPE IDs

2022-10-17T19:56:14+00:00

Add more IDs that are found in the downstream msm-4.19 kernel under the
path include/linux/qpnp/qpnp-revid.h.

Signed-off-by: Luca Weiss 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Caleb Connolly 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20220922082925.17975-2-luca.weiss@fairphone.com

soc: qcom: spmi-pmic: convert hex numbers to lowercase

2022-10-17T19:56:14+00:00

There are some IDs that are written in uppercase. For consistency
convert them to lowercase.

Signed-off-by: Luca Weiss 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Caleb Connolly 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20220922082925.17975-1-luca.weiss@fairphone.com

mfd: qcom-spmi-pmic: read fab id on supported PMICs

2022-06-18T13:01:16+00:00

The PMI8998 and PM660 expose the fab_id, this is needed by drivers like
the RRADC to calibrate ADC values.

Signed-off-by: Caleb Connolly 
Reviewed-by: Dmitry Baryshkov 
Tested-by: Dmitry Baryshkov 
Acked-by: Lee Jones 
Link: https://lore.kernel.org/r/20220429220904.137297-4-caleb.connolly@linaro.org
Signed-off-by: Jonathan Cameron

mfd: qcom-spmi-pmic: expose the PMIC revid information to clients

2022-06-18T13:01:16+00:00

Some PMIC functions such as the RRADC need to be aware of the PMIC
chip revision information to implement errata or otherwise adjust
behaviour, export the PMIC information to enable this.

This is specifically required to enable the RRADC to adjust
coefficients based on which chip fab the PMIC was produced in,
this can vary per unique device and therefore has to be read at
runtime.

Signed-off-by: Caleb Connolly 
Reviewed-by: Dmitry Baryshkov 
Tested-by: Dmitry Baryshkov 
Acked-by: Lee Jones 
Link: https://lore.kernel.org/r/20220429220904.137297-3-caleb.connolly@linaro.org
Signed-off-by: Jonathan Cameron

soc: qcom: spm: Implement support for SAWv4.1, SDM630/660 L2 AVS

2021-09-21T22:41:48+00:00

Implement the support for SAW v4.1, used in at least MSM8998,
SDM630, SDM660 and APQ variants and, while at it, also add the
configuration for the SDM630/660 Silver and Gold cluster L2
Adaptive Voltage Scaler: this is also one of the prerequisites
to allow the OSM controller to perform DCVS.

Please note that despite there are various "versions" of these
values downstream, these are the only ones that are perfectly
stable on the entire set of tested devices.

Signed-off-by: AngeloGioacchino Del Regno 
Reviewed-by: Stephan Gerhold 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20210729155609.608159-4-angelogioacchino.delregno@somainline.org

cpuidle: qcom_spm: Detach state machine from main SPM handling

2021-09-21T22:41:48+00:00

In commit a871be6b8eee ("cpuidle: Convert Qualcomm SPM driver to a generic
CPUidle driver") the SPM driver has been converted to a
generic CPUidle driver: that was mainly made to simplify the
driver and that was a great accomplishment;
Though, at that time, this driver was only applicable to ARM 32-bit SoCs,
lacking logic about the handling of newer generation SAW.

In preparation for the enablement of SPM features on AArch64/ARM64,
split the cpuidle-qcom-spm driver in two: the CPUIdle related
state machine (currently used only on ARM SoCs) stays there, while
the SPM communication handling lands back in soc/qcom/spm.c and
also making sure to not discard the simplifications that were
introduced in the aforementioned commit.

Since now the "two drivers" are split, the SCM dependency in the
main SPM handling is gone and for this reason it was also possible
to move the SPM initialization early: this will also make sure that
whenever the SAW CPUIdle driver is getting initialized, the SPM
driver will be ready to do the job.

Please note that the anticipation of the SPM initialization was
also done to optimize the boot times on platforms that have their
CPU/L2 idle states managed by other means (such as PSCI), while
needing SAW initialization for other purposes, like AVS control.

Signed-off-by: AngeloGioacchino Del Regno 
Reviewed-by: Stephan Gerhold 
Tested-by: Stephan Gerhold 
Acked-by: Daniel Lezcano 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20210729155609.608159-2-angelogioacchino.delregno@somainline.org