linux-toradex.git/include/soc/qcom, branch v6.9-rc5

soc: qcom: spm: remove driver-internal structures from the driver API

2024-02-16T17:30:57+00:00

Move internal SPM driver structures to the driver itself, removing them
from the public API. The CPUidle driver doesn't use them at all.

Reviewed-by: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20240102-saw2-spm-regulator-v7-4-0472ec237f49@linaro.org
Signed-off-by: Bjorn Andersson

soc: qcom: socinfo: rename PM2250 to PM4125

2024-01-28T03:45:49+00:00

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

mfd: qcom-spmi-pmic: Add support for PM8937

2023-12-07T13:50:28+00:00

Add the subtype and compatible strings for PM8937.

The PM8937 is found in various SoCs, including MSM8917, MSM8937,
MSM8940 and APQ variants.

Reviewed-by: Caleb Connolly 
Signed-off-by: Dang Huynh 
Link: https://lore.kernel.org/r/20231121-pm8937-v2-1-b0171ab62075@riseup.net
Signed-off-by: Lee Jones

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