kernel/linux.git/include/soc/qcom, branch v6.6.39

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

soc: qcom: rpmh: Remove serialization of TCS commands

2021-01-07T16:59:46+00:00

Requests sent to RPMH can be sent as fire-n-forget or response required, with the latter ensuring the command has been completed by the hardware accelerator. Commands in a request with tcs_cmd::wait set, would ensure that those select commands are sent as response required, even though the actual TCS request may be fire-n-forget. Also, commands with .wait flag were also guaranteed to be complete before the following command in the TCS is sent. This means that the next command of the same request blocked until the current request is completed. This could mean waiting for a voltage to settle or series of NOCs be configured before the next command is sent. But drivers using this feature have never cared about the serialization aspect. By not enforcing the serialization we can allow the hardware to run in parallel improving the performance. Let's clarify the usage of this member in the tcs_cmd structure to mean only completion and not serialization. This should also improve the performance of bus requests where changes could happen in parallel. Also, CPU resume from deep idle may see benefits from certain wake requests. Reviewed-by: Douglas Anderson Signed-off-by: Lina Iyer Signed-off-by: Maulik Shah Link: https://lore.kernel.org/r/1610008770-13891-1-git-send-email-mkshah@codeaurora.org Signed-off-by: Bjorn Andersson