| Message ID | 20230217-topic-cpr3h-v12-0-1a4d050e1e67@linaro.org |
|---|---|
| Headers | show |
| Series | (no cover subject) | expand |
On Wed, 28 Jun 2023 16:00:42 +0200, Konrad Dybcio wrote: > 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> > --- > .../devicetree/bindings/opp/opp-v2-qcom-level.yaml | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.example.dtb: /example-0/pmic: failed to match any schema with compatible: ['ti,twl6035-pmic', 'ti,palmas-pmic'] Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.example.dtb: /example-0/pmic: failed to match any schema with compatible: ['ti,twl6035-pmic', 'ti,palmas-pmic'] Documentation/devicetree/bindings/i2c/qcom,i2c-cci.example.dtb: /example-0/cci@ac4a000/i2c-bus@1/camera@60: failed to match any schema with compatible: ['ovti,ov7251'] Documentation/devicetree/bindings/net/marvell,mvusb.example.dtb: /example-0/usb/mdio@1/switch@0: failed to match any schema with compatible: ['marvell,mv88e6190'] Documentation/devicetree/bindings/net/qca,ar71xx.example.dtb: /example-0/ethernet@1a000000/mdio/switch@10: failed to match any schema with compatible: ['qca,ar9331-switch'] Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.example.dtb: /example-0/memory-controller@13410000/ethernet@6: failed to match any schema with compatible: ['davicom,dm9000'] Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.example.dtb: /example-0/iomcu@ffd7e000: failed to match any schema with compatible: ['hisilicon,hi3660-iomcu', 'syscon'] Documentation/devicetree/bindings/leds/common.example.dtb: /example-2/i2c/led-controller@30: failed to match any schema with compatible: ['panasonic,an30259a'] Documentation/devicetree/bindings/dma/dma-router.example.dtb: /example-0/dma-router@4a002b78: failed to match any schema with compatible: ['ti,dra7-dma-crossbar'] Documentation/devicetree/bindings/dma/dma-controller.example.dtb: /example-0/dma-controller@48000000: failed to match any schema with compatible: ['ti,omap-sdma'] Documentation/devicetree/bindings/media/rockchip-isp1.example.dtb: /example-0/parent/i2c/camera@36: failed to match any schema with compatible: ['ovti,ov5695'] Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.example.dtb: /example-1/syscon@20e00000: failed to match any schema with compatible: ['sprd,sc9863a-glbregs', 'syscon', 'simple-mfd'] Documentation/devicetree/bindings/clock/milbeaut-clock.example.dtb: /example-2/serial@1e700010: failed to match any schema with compatible: ['socionext,milbeaut-usio-uart'] Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.example.dtb: /example-0/cpuctrl@a22000/clock@0: failed to match any schema with compatible: ['hisilicon,hix5hd2-clock'] Documentation/devicetree/bindings/arm/hisilicon/controller/hi3798cv200-perictrl.example.dtb: /example-0/peripheral-controller@8a20000/phy@850: failed to match any schema with compatible: ['hisilicon,hi3798cv200-combphy'] Documentation/devicetree/bindings/arm/hisilicon/controller/sysctrl.example.dtb: /example-0/system-controller@802000/clock@0: failed to match any schema with compatible: ['hisilicon,hi3620-clock'] Documentation/devicetree/bindings/sound/audio-graph-card2.example.dtb: /example-0/cpu: failed to match any schema with compatible: ['cpu-driver'] Documentation/devicetree/bindings/sound/audio-graph-card2.example.dtb: /example-0/codec: failed to match any schema with compatible: ['codec-driver'] Documentation/devicetree/bindings/input/sprd,sc27xx-vibrator.example.dtb: /example-0/pmic@0: failed to match any schema with compatible: ['sprd,sc2731'] Documentation/devicetree/bindings/input/mediatek,pmic-keys.example.dtb: /example-0/pmic: failed to match any schema with compatible: ['mediatek,mt6397'] Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.example.dtb: /example-0/avs-monitor@7d5d2000: failed to match any schema with compatible: ['brcm,bcm2711-avs-monitor', 'syscon', 'simple-mfd'] Documentation/devicetree/bindings/thermal/imx-thermal.example.dtb: /example-0/anatop@20c8000: failed to match any schema with compatible: ['fsl,imx6q-anatop', 'syscon', 'simple-mfd'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230217-topic-cpr3h-v12-3-1a4d050e1e67@linaro.org The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
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/ > out of this. > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > drivers/cpufreq/cpufreq-dt-platdev.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c > index e2b20080de3a..adb3579a1fee 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -143,6 +143,7 @@ static const struct of_device_id blocklist[] __initconst = { > > { .compatible = "qcom,apq8096", }, > { .compatible = "qcom,msm8996", }, > + { .compatible = "qcom,msm8998", }, > { .compatible = "qcom,qcs404", }, > { .compatible = "qcom,sa8155p" }, > { .compatible = "qcom,sa8540p" }, > > -- > 2.41.0 >
On 28.06.2023 18:03, Rob Herring wrote: > On Wed, Jun 28, 2023 at 04:00:43PM +0200, Konrad Dybcio wrote: >> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> >> >> Add the bindings for the CPR3 driver to the documentation. > > Bindings are for h/w, not drivers. This shows how ancient this patch is, from before it was common knowledge ;) > >> >> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> >> [Konrad: Make binding check pass; update AGdR's email] >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >> --- >> .../devicetree/bindings/soc/qcom/qcom,cpr3.yaml | 289 +++++++++++++++++++++ >> 1 file changed, 289 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml >> new file mode 100644 >> index 000000000000..46b94dffaf85 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml >> @@ -0,0 +1,289 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: "http://devicetree.org/schemas/soc/qcom/qcom,cpr3.yaml#" >> +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > > Drop quotes Ack > >> + >> +title: Qualcomm Core Power Reduction v3/v4/Hardened (CPR3, CPR4, CPRh) >> + >> +description: >> + CPR (Core Power Reduction) is a technology to reduce core power of a CPU >> + (or another device). Each OPP of a device corresponds to a "corner" that >> + has a range of valid voltages for a particular frequency. >> + The CPR monitors dynamic factors such as temperature, etc. and suggests >> + or (in the CPR-hardened case) applies voltage adjustments to save power >> + and meet silicon characteristic requirements for a given chip unit. >> + >> +maintainers: >> + - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> >> + >> +properties: >> + compatible: >> + oneOf: >> + - description: CPRv3 controller >> + items: >> + - const: qcom,cpr3 >> + - description: CPRv4 controller >> + items: >> + - const: qcom,cpr4 >> + - description: CPRv4-Hardened controller >> + items: >> + - enum: >> + - qcom,msm8998-cprh >> + - qcom,sdm630-cprh >> + - const: qcom,cprh >> + >> + reg: >> + description: Base address and size of the CPR controller(s) >> + maxItems: 2 > > What is each entry? I thought the description was clear enough, but I'll add items:. > >> + >> + interrupts: >> + maxItems: 1 >> + >> + clocks: >> + items: >> + - description: CPR reference clock >> + >> + vdd-supply: >> + description: Autonomous Phase Control (APC) or other power supply >> + >> + '#power-domain-cells': >> + const: 1 >> + >> + qcom,acc: >> + $ref: /schemas/types.yaml#/definitions/phandle >> + description: phandle to syscon for writing ACC settings >> + >> + nvmem-cells: >> + description: Cells containing the fuse corners and revision data >> + maxItems: 32 >> + >> + nvmem-cell-names: >> + maxItems: 32 >> + >> + operating-points-v2: true >> + >> + power-domains: true > > Need to define how many. Ack > >> + >> +required: >> + - compatible >> + - reg >> + - clocks >> + - operating-points-v2 >> + - "#power-domain-cells" >> + - nvmem-cells >> + - nvmem-cell-names >> + >> +additionalProperties: false >> + >> +allOf: >> + - if: >> + properties: >> + compatible: >> + contains: >> + enum: >> + - qcom,msm8998-cprh >> + then: >> + properties: >> + nvmem-cell-names: >> + items: >> + - const: cpr_speed_bin >> + - const: cpr_fuse_revision >> + - const: cpr0_quotient1 >> + - const: cpr0_quotient2 >> + - const: cpr0_quotient3 >> + - const: cpr0_quotient4 >> + - const: cpr0_quotient_offset2 >> + - const: cpr0_quotient_offset3 >> + - const: cpr0_quotient_offset4 >> + - const: cpr0_init_voltage1 >> + - const: cpr0_init_voltage2 >> + - const: cpr0_init_voltage3 >> + - const: cpr0_init_voltage4 >> + - const: cpr0_ring_osc1 >> + - const: cpr0_ring_osc2 >> + - const: cpr0_ring_osc3 >> + - const: cpr0_ring_osc4 >> + - const: cpr1_quotient1 >> + - const: cpr1_quotient2 >> + - const: cpr1_quotient3 >> + - const: cpr1_quotient4 >> + - const: cpr1_quotient_offset2 >> + - const: cpr1_quotient_offset3 >> + - const: cpr1_quotient_offset4 >> + - const: cpr1_init_voltage1 >> + - const: cpr1_init_voltage2 >> + - const: cpr1_init_voltage3 >> + - const: cpr1_init_voltage4 >> + - const: cpr1_ring_osc1 >> + - const: cpr1_ring_osc2 >> + - const: cpr1_ring_osc3 >> + - const: cpr1_ring_osc4 >> + >> +examples: >> + - | >> + #include <dt-bindings/clock/qcom,gcc-msm8998.h> >> + #include <dt-bindings/interrupt-controller/irq.h> >> + >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; >> + >> + cpu@0 { >> + compatible = "qcom,kryo280"; >> + device_type = "cpu"; >> + reg = <0x0 0x0>; >> + operating-points-v2 = <&cpu0_opp_table>; >> + power-domains = <&apc_cprh 0>; >> + power-domain-names = "cprh"; > > The name should be local to the device, not based on the provider. > > Do you really need a name here with only 1? Yes, cpufreq drivers need to dance around the genpd and OPP frameworks, which requires a name. Konrad > >> + }; >> + >> + cpu@100 { >> + compatible = "qcom,kryo280"; >> + device_type = "cpu"; >> + reg = <0x0 0x100>; >> + operating-points-v2 = <&cpu4_opp_table>; >> + power-domains = <&apc_cprh 1>; >> + power-domain-names = "cprh"; >> + }; >> + }; >> + >> + cpu0_opp_table: opp-table-cpu0 { >> + compatible = "operating-points-v2"; >> + opp-shared; >> + >> + opp-1843200000 { >> + opp-hz = /bits/ 64 <1843200000>; >> + required-opps = <&cprh_opp3>; >> + }; >> + >> + opp-1094400000 { >> + opp-hz = /bits/ 64 <1094400000>; >> + required-opps = <&cprh_opp2>; >> + }; >> + >> + opp-300000000 { >> + opp-hz = /bits/ 64 <300000000>; >> + required-opps = <&cprh_opp1>; >> + }; >> + }; >> + >> + cpu4_opp_table: opp-table-cpu4 { >> + compatible = "operating-points-v2"; >> + opp-shared; >> + >> + opp-2208000000 { >> + opp-hz = /bits/ 64 <2208000000>; >> + required-opps = <&cprh_opp3>; >> + }; >> + >> + opp-1113600000 { >> + opp-hz = /bits/ 64 <1113600000>; >> + required-opps = <&cprh_opp2>; >> + }; >> + >> + opp-300000000 { >> + opp-hz = /bits/ 64 <300000000>; >> + required-opps = <&cprh_opp1>; >> + }; >> + }; >> + >> + cprh_opp_table: opp-table-cprh { >> + compatible = "operating-points-v2-qcom-level"; >> + >> + cprh_opp1: opp-1 { >> + opp-level = <1>; >> + qcom,opp-fuse-level = <1>; >> + qcom,opp-cloop-vadj = <0>; >> + qcom,opp-oloop-vadj = <0>; >> + }; >> + >> + cprh_opp2: opp-2 { >> + opp-level = <2>; >> + qcom,opp-fuse-level = <2>; >> + qcom,opp-cloop-vadj = <0>; >> + qcom,opp-oloop-vadj = <0>; >> + }; >> + >> + cprh_opp3: opp-3 { >> + opp-level = <3>; >> + qcom,opp-fuse-level = <2 3>; >> + qcom,opp-cloop-vadj = <0>; >> + qcom,opp-oloop-vadj = <0>; >> + }; >> + }; >> + >> + apc_cprh: power-controller@179c8000 { >> + compatible = "qcom,msm8998-cprh", "qcom,cprh"; >> + reg = <0x0179c8000 0x4000>, <0x0179c4000 0x4000>; >> + clocks = <&gcc GCC_HMSS_RBCPR_CLK>; >> + >> + operating-points-v2 = <&cprh_opp_table>; >> + #power-domain-cells = <1>; >> + >> + nvmem-cells = <&cpr_efuse_speedbin>, >> + <&cpr_fuse_revision>, >> + <&cpr_quot0_pwrcl>, >> + <&cpr_quot1_pwrcl>, >> + <&cpr_quot2_pwrcl>, >> + <&cpr_quot3_pwrcl>, >> + <&cpr_quot_offset1_pwrcl>, >> + <&cpr_quot_offset2_pwrcl>, >> + <&cpr_quot_offset3_pwrcl>, >> + <&cpr_init_voltage0_pwrcl>, >> + <&cpr_init_voltage1_pwrcl>, >> + <&cpr_init_voltage2_pwrcl>, >> + <&cpr_init_voltage3_pwrcl>, >> + <&cpr_ro_sel0_pwrcl>, >> + <&cpr_ro_sel1_pwrcl>, >> + <&cpr_ro_sel2_pwrcl>, >> + <&cpr_ro_sel3_pwrcl>, >> + <&cpr_quot0_perfcl>, >> + <&cpr_quot1_perfcl>, >> + <&cpr_quot2_perfcl>, >> + <&cpr_quot3_perfcl>, >> + <&cpr_quot_offset1_perfcl>, >> + <&cpr_quot_offset2_perfcl>, >> + <&cpr_quot_offset3_perfcl>, >> + <&cpr_init_voltage0_perfcl>, >> + <&cpr_init_voltage1_perfcl>, >> + <&cpr_init_voltage2_perfcl>, >> + <&cpr_init_voltage3_perfcl>, >> + <&cpr_ro_sel0_perfcl>, >> + <&cpr_ro_sel1_perfcl>, >> + <&cpr_ro_sel2_perfcl>, >> + <&cpr_ro_sel3_perfcl>; >> + nvmem-cell-names = "cpr_speed_bin", >> + "cpr_fuse_revision", >> + "cpr0_quotient1", >> + "cpr0_quotient2", >> + "cpr0_quotient3", >> + "cpr0_quotient4", >> + "cpr0_quotient_offset2", >> + "cpr0_quotient_offset3", >> + "cpr0_quotient_offset4", >> + "cpr0_init_voltage1", >> + "cpr0_init_voltage2", >> + "cpr0_init_voltage3", >> + "cpr0_init_voltage4", >> + "cpr0_ring_osc1", >> + "cpr0_ring_osc2", >> + "cpr0_ring_osc3", >> + "cpr0_ring_osc4", >> + "cpr1_quotient1", >> + "cpr1_quotient2", >> + "cpr1_quotient3", >> + "cpr1_quotient4", >> + "cpr1_quotient_offset2", >> + "cpr1_quotient_offset3", >> + "cpr1_quotient_offset4", >> + "cpr1_init_voltage1", >> + "cpr1_init_voltage2", >> + "cpr1_init_voltage3", >> + "cpr1_init_voltage4", >> + "cpr1_ring_osc1", >> + "cpr1_ring_osc2", >> + "cpr1_ring_osc3", >> + "cpr1_ring_osc4"; >> + }; >> +... >> >> -- >> 2.41.0 >>
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 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 :)
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,