| Message ID | 20230217-topic-cpr3h-v12-0-1a4d050e1e67@linaro.org |
|---|---|
| Headers | show |
| Series | (no cover subject) | expand |
On 28-06-23, 09:56, Rob Herring wrote: > On Wed, Jun 28, 2023 at 04:00:40PM +0200, Konrad Dybcio wrote: > > From: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> > > > > Add the MSM8998 to the blacklist since the CPU scaling is handled > > s/blacklist/denylist/ or s/blacklist/blocklist/ They are already named allowlist and blocklist. > > @@ -143,6 +143,7 @@ static const struct of_device_id blocklist[] __initconst = {
On 28/06/2023 16:00, Konrad Dybcio wrote: > From: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> > > Add the MSM8998 to the blacklist since the CPU scaling is handled It is "blocklist", not "blacklist" (both in commit msg and subject). Best regards, Krzysztof
On 03/07/2023 06:17, Viresh Kumar wrote: > On 28-06-23, 09:56, Rob Herring wrote: >> On Wed, Jun 28, 2023 at 04:00:40PM +0200, Konrad Dybcio wrote: >>> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> >>> >>> Add the MSM8998 to the blacklist since the CPU scaling is handled >> >> s/blacklist/denylist/ or s/blacklist/blocklist/ > > They are already named allowlist and blocklist. This was about commit msg and subject. They are not named like this. Best regards, Krzysztof
On 04-07-23, 10:07, Krzysztof Kozlowski wrote: > On 03/07/2023 06:17, Viresh Kumar wrote: > > On 28-06-23, 09:56, Rob Herring wrote: > >> On Wed, Jun 28, 2023 at 04:00:40PM +0200, Konrad Dybcio wrote: > >>> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> > >>> > >>> Add the MSM8998 to the blacklist since the CPU scaling is handled > >> > >> s/blacklist/denylist/ or s/blacklist/blocklist/ > > > > They are already named allowlist and blocklist. > > This was about commit msg and subject. They are not named like this. Yeah, I was just saying we have proper names in the code and they must be used here in commit. Sorry for not being clear earlier :)
Il 28/06/23 16:00, Konrad Dybcio ha scritto: > CPR3 and newer can be fed per-OPP voltage adjustment values for both > open- and closed-loop paths to make better decisions about settling > on the final voltage offset target. Document these properties. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Changes in v12: - Add the !independent! patch to block cpufreq-dt from probing on 8998 (it tries to when we attach OPP tables to the CPU nodes) - Include all promised changes to the CPR3 driver from v11 (I managed to send the wrong version of that patch last time around..) - Partially rewrite debugfs code (to make it work and be cleaner) - use FIELD_PREP/GET throughout the driver (managed to squash a bug when exploring that) - Fix and finish the removal of cpr_get_ro_factor() by introducing cpr_thread_desc.ro_scaling_factor_common - Replace underscores in node names with '-' - Fix some formatstring issues that clang apparently doesn't care about - Link to v11: https://lore.kernel.org/r/20230217-topic-cpr3h-v11-0-ba22b4daa5d6@linaro.org Add support for Core Power Reduction v3, v4 and Hardened Changes in v11: CPR COMMON: - split the commonizing patch, make it actually do what it says on the tin.. - fix some overflow bugs CPR3: - fix some overflow bugs - don't assume "lack of qcom,opp-?loop-vadj" means val=0" CPR BINDINGS: - drop quotes in items - drop clock-names (there's just a single one) - rewrite the description a bit - fix up the example - drop bogus minItems - "acc-syscon" -> "qcom,acc" DTS: - fix qfprom children so that the bits=<> doesn't overflow reg[size] - drop unrelated changes - place one reg entry per line Link to v10: https://lore.kernel.org/r/20230217-topic-cpr3h-v10-0-67aed8fdfa61@linaro.org Changes in v10: - Skip "Let qcom,opp-fuse-level be a 2-long array" (Applied by Viresh) - Use b4 (it may be the first time you're receiving this if git send-email omitted you before..) - +Cc Robert Marko (expressed interest in previous revisions) - Add "Document CPR3 open/closed loop volt adjustment" CPR: - %hhu -> %u (checkpatch) CPR BINDINGS: - Drop QCS404 fuse set (it doesn't use this driver, what did I even think..) but leave the allOf:if: block for expansion (sdm660, msm8996, ipqABCD should follow soon..) - Drop Rob's R-b (as things changed *again*, please take one more look to make sure you're okay with this file, Rob..) Link to v9: https://lore.kernel.org/linux-arm-msm/20230116093845.72621-1-konrad.dybcio@linaro.org/ Changes in v9: - Restore forgotten MAINTAINERS patch (oops) CPR: - Include the missing header (big oops!) - Fix kconfig dependencies CPR bindings: - Fix cpu reg in example (why didn't dt_binding_check scream at that) - Add newlines between nodes in example - Change opp table node names to opp-table-cpu[04] - Change opp table labels to cpu[04]_opp_table - Change CPRh opp subnode names to opp-N from oppN - Remove some stray newlines - Bring back nvmem-cell-names and add the 8998's set - Allow power-domains for VDDCX_AO voting - Remove Rob's r-b, there's been quite a bit of changes.. CPR DT: - Send the correct revision of the patch this time around.. OPP bindings: - Add Rob's ack Link to v8: https://lore.kernel.org/linux-arm-msm/20230110175605.1240188-1-konrad.dybcio@linaro.org/ Changes in v8: - Overtake this series from AGdR - Apply all review comments from v7 except Vladimir's request to not create the include/ header; it will be strictly necessary for OSM-aware cpufreq_hw programming, which this series was more or less created just for.. - Drop QCS404 dtsi change, account for not breaking backwards compat in [3/5] - Add type phandle type reference to acc-syscon in [1/5] - Update AGdR's email addresses for maintainer entries - Add [2/5] to make dt_binding_check happy - Separate the CPRh DT addition from cpufreq_hw addition, sort and properly indent new nodes - Drop CPR yaml conversion, that happened in meantime - Reorder the patches to make a bit more sense - Tested again on MSM8998 Xperia XZ Premium (Maple) - I take no responsibility for AGdR's cheeky jokes, only the code! Link to v7: https://lore.kernel.org/lkml/20210901155735.629282-1-angelogioacchino.delregno@somainline.org/ Changes in v7: - Rebased on linux-next as of 210901 - Changed cpr_read_efuse calls to nvmem_cell_read_variable_le_u32, following what was done in commit c77634b9d916 Changes in v6: - Fixes from Bjorn's review - After a conversation with Viresh, it turned out I was abusing the OPP API to pass the APM and MEM-ACC thresholds to qcom-cpufreq-hw, so now the driver is using the genpd created virtual device and passing drvdata instead to stop the abuse - Since the CPR commonization was ignored for more than 6 months, it is now included in the CPRv3/4/h series, as there is no point in commonizing without having this driver - Rebased on v5.13 Changes in v5: - Fixed getting OPP table when not yet installed by the caller of power domain attachment Changes in v4: - Huge patch series has been split for better reviewability, as suggested by Bjorn Changes in v3: - Fixed YAML doc issues - Removed unused variables and redundant if branch Changes in v2: - Implemented dynamic Memory Accelerator corners support, needed by MSM8998 - Added MSM8998 Silver/Gold parameters This commit introduces a new driver, based on the one for cpr v1, to enable support for the newer Qualcomm Core Power Reduction hardware, known downstream as CPR3, CPR4 and CPRh, and support for MSM8998 and SDM630 CPU power reduction. In these new versions of the hardware, support for various new features was introduced, including voltage reduction for the GPU, security hardening and a new way of controlling CPU DVFS, consisting in internal communication between microcontrollers, specifically the CPR-Hardened and the Operating State Manager. The CPR v3, v4 and CPRh are present in a broad range of SoCs, from the mid-range to the high end ones including, but not limited to, MSM8953/8996/8998, SDM630/636/660/845. As to clarify, SDM845 does the CPR/SAW/OSM setup in TZ firmware, but this is limited to the CPU context; despite GPU CPR support being not implemented in this series, it is planned for the future, and some SDM845 need the CPR (in the context of GPU CPR) to be configured from this driver. It is also planned to add the CPR data for MSM8996, since this driver does support the CPRv4 found on that SoC, but I currently have no time to properly test that on a real device, so I prefer getting this big implementation merged before adding more things on top. As for MSM8953, we (read: nobody from SoMainline) have no device with this chip: since we are unable to test the cpr data and the entire driver on that one, we currently have no plans to do this addition in the future. This is left to other nice developers: I'm sure that somebody will come up with that, sooner or later Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> --- AngeloGioacchino Del Regno (8): cpufreq: blacklist MSM8998 in cpufreq-dt-platdev MAINTAINERS: Add entry for Qualcomm CPRv3/v4/Hardened driver dt-bindings: soc: qcom: cpr3: Add bindings for CPR3 driver soc: qcom: cpr: Move common functions to new file soc: qcom: cpr-common: Add support for flat fuse adjustment soc: qcom: cpr-common: Add threads support soc: qcom: Add support for Core Power Reduction v3, v4 and Hardened arm64: dts: qcom: msm8998: Configure CPRh Konrad Dybcio (2): dt-bindings: opp: v2-qcom-level: Document CPR3 open/closed loop volt adjustment soc: qcom: cpr: Use u64 for frequency .../devicetree/bindings/opp/opp-v2-qcom-level.yaml | 14 + .../devicetree/bindings/soc/qcom/qcom,cpr3.yaml | 289 ++ MAINTAINERS | 6 + arch/arm64/boot/dts/qcom/msm8998.dtsi | 757 ++++++ drivers/cpufreq/cpufreq-dt-platdev.c | 1 + drivers/soc/qcom/Kconfig | 22 + drivers/soc/qcom/Makefile | 2 + drivers/soc/qcom/cpr-common.c | 362 +++ drivers/soc/qcom/cpr-common.h | 109 + drivers/soc/qcom/cpr.c | 394 +-- drivers/soc/qcom/cpr3.c | 2855 ++++++++++++++++++++ include/soc/qcom/cpr.h | 17 + 12 files changed, 4460 insertions(+), 368 deletions(-) --- base-commit: 5c875096d59010cee4e00da1f9c7bdb07a025dc2 change-id: 20230217-topic-cpr3h-de232bfb47ec Best regards,