mbox series

[00/13] Enable CPRh/3/4, CPU Scaling on various QCOM SoCs

Message ID 20201126184559.3052375-1-angelogioacchino.delregno@somainline.org
Headers show
Series Enable CPRh/3/4, CPU Scaling on various QCOM SoCs | expand

Message

AngeloGioacchino Del Regno Nov. 26, 2020, 6:45 p.m. UTC
This patch series is definitely big.
Yup. But it all goes together... here's why:

This series implements full support for CPU scaling on *many* Qualcomm
SoCs and partial support for the others on which the Operating State
Manager is not present.
Since this is a bit tangled, let's go step by step.

First of all, there's the SPM: this is a component that we can find on
very old chips, like MSM8974; there, it has been used to actually do the
power scaling basically "on its own" - sending the cores in a specific
sleep mode to save power.
On the newer ones, including MSM8998, SDM630, 660 and others, it is still
present! Though, this time, it's being used for the cluster caches and it
has a different firmware (and maybe it's also slightly different HW),
implementing the SAWv4.1 set and getting controlled *not by the OS* but
by other controllers in the SoC (like the OSM).

Contrary from MSM8974 and the like, this new version of the SPM just
requires us to set the initial parameters for AVS and *nothing else*, as
its states will be totally managed internally.

Then, hardening here we come!
In all the new SoCs - as new as SM8150 and most probably even newer ones -
there are also new versions of "the same old story".. and here I'm
referring to the Core Power Reduction (CPR) block: since MSM8996 (or
around that time frame), this block has got a sort of major change...
which actually varies the register set and implements "threads".
I won't go far with explaining that in this cover letter (as it's all
explained in the commits) but, in short, here's the catch:
CPR v3, v4 and CPR-Hardened are all based over the same register set
and are extensions of their previous.

A sort of special treatment must be given to CPR-Hardened (CPRh): this is
the one that's present on the newest SoCs, as this is a hardened version
of CPR4 and - in this version - it has got the ability to also get managed
internally, along with the SAWv4.1, by the Operating State Manager (OSM).

And finally, we get to the OSM.
This final piece appeared on MSM8998 for the first time (as far as I know),
and it is (a sort of microcontroller?) doing the "real deal": CPU DVFS
through a lookup table providing "corners" - or "performance states" - to
the OS; pretty straightforward way of offloading a whole lot of tasks that
the kernel would otherwise have to do.

And there we go with the full picture:
- From SDM845 onwards, SAW, CPRh and OSM are getting setup by the
  bootloader/TZ *before* booting the OS, so then all the OS has to do
  is to request a specific performance state to the OSM hardware and
  forget about all the rest, which is anyway protected by the hypervisor
  (so there's no access anyway); BUT:
- In MSM/APQ 8998, SDM/SDA 630/636/660 (and other variants), there is no
  setup of any of these puzzle pieces, and they're also (basically) fully
  accessible, which means that the OS must do it in order to get in the
  same state as the newer ones and to get the entire scaling hardware to
  start rolling.

"Simply", that's it. Now that I've written a kilometer-long "short
explaination" of what's going on, there's a shorter version of it:
- On new SoCs, the bootloader sets up the entire thing
- On old ones, the OS must do what the bootloader didn't do.
- That's what this patch series does. :))

There's also slightly more: since - as already explained - the
CPR-Hardened is an incremental upgrade of CPR v3->v4, it was necessary
for me to also implement support for these two versions, present in
"another whole bunch" of Qualcomm SoCs, including MSM8953, MSM8996 and
others, which is used to do either power reduction or complete voltage
scaling for the CPU clusters on these old ones... and, well, also
in 8998/630/660 along with the Hardened one... and the reason is...
that this piece of HW is also capable of doing the same with the GPU,
even though this is not yet implemented in this set.

I didn't feel like implementing the Multimedia Subsystem (MMSS) part
of the CPR3/4 in this patch series because, eh, it's already long enough,
I'd say.

Perhaps, later... :)

AngeloGioacchino Del Regno (13):
  cpuidle: qcom_spm: Detach state machine from main SPM handling
  soc: qcom: spm: Implement support for SAWv4.1, SDM630/660 L2 AVS
  soc: qcom: spm: Add compatible for MSM8998 SAWv4.1 L2
  cpufreq: blacklist SDM630/636/660 in cpufreq-dt-platdev
  soc: qcom: cpr: Move common functions to new file
  arm64: qcom: qcs404: Change CPR nvmem-names
  dt-bindings: avs: cpr: Convert binding to YAML schema
  soc: qcom: Add support for Core Power Reduction v3, v4 and Hardened
  MAINTAINERS: Add entry for Qualcomm CPRv3/v4/Hardened driver
  dt-bindings: soc: qcom: cpr3: Add bindings for CPR3 driver
  dt-bindings: cpufreq: Convert qcom-cpufreq-hw to YAML binding
  cpufreq: qcom-hw: Implement CPRh aware OSM programming
  dt-bindings: cpufreq: qcom-hw: Add bindings for 8998

 .../bindings/cpufreq/cpufreq-qcom-hw.txt      |  173 +-
 .../bindings/cpufreq/qcom,cpufreq-hw.yaml     |  219 ++
 .../bindings/power/avs/qcom,cpr.txt           |  131 +-
 .../bindings/soc/qcom/qcom,cpr.yaml           |  115 +
 .../bindings/soc/qcom/qcom,cpr3.yaml          |  226 ++
 MAINTAINERS                                   |    8 +-
 arch/arm64/boot/dts/qcom/qcs404.dtsi          |   26 +-
 drivers/cpufreq/cpufreq-dt-platdev.c          |    3 +
 drivers/cpufreq/qcom-cpufreq-hw.c             |  914 +++++-
 drivers/cpuidle/Kconfig.arm                   |    1 +
 drivers/cpuidle/cpuidle-qcom-spm.c            |  294 +-
 drivers/soc/qcom/Kconfig                      |   26 +
 drivers/soc/qcom/Makefile                     |    4 +-
 drivers/soc/qcom/cpr-common.c                 |  382 +++
 drivers/soc/qcom/cpr-common.h                 |  113 +
 drivers/soc/qcom/cpr.c                        |  441 +--
 drivers/soc/qcom/cpr3.c                       | 2474 +++++++++++++++++
 drivers/soc/qcom/spm.c                        |  226 ++
 include/soc/qcom/spm.h                        |   45 +
 19 files changed, 4824 insertions(+), 997 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/qcom,cpufreq-hw.yaml
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml
 create mode 100644 drivers/soc/qcom/cpr-common.c
 create mode 100644 drivers/soc/qcom/cpr-common.h
 create mode 100644 drivers/soc/qcom/cpr3.c
 create mode 100644 drivers/soc/qcom/spm.c
 create mode 100644 include/soc/qcom/spm.h

Comments

Rob Herring Nov. 30, 2020, 5:03 p.m. UTC | #1
On Thu, 26 Nov 2020 19:45:53 +0100, AngeloGioacchino Del Regno wrote:
> Convert the qcom,cpr.txt document to YAML schema and place it in the
> appropriate directory, since commit a7305e684fc moves this driver
> from power/avs to soc/qcom, but forgets to move the documentation.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
> ---
>  .../bindings/power/avs/qcom,cpr.txt           | 131 +-----------------
>  .../bindings/soc/qcom/qcom,cpr.yaml           | 115 +++++++++++++++
>  MAINTAINERS                                   |   2 +-
>  3 files changed, 117 insertions(+), 131 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml: properties:clock-names: [{'const': 'ref'}] is not of type 'object', 'boolean'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml: ignoring, error in schema: properties: clock-names
warning: no schema found in file: ./Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml


See https://patchwork.ozlabs.org/patch/1406855

The base for the patch is generally the last rc1. Any dependencies
should be noted.

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.
Rob Herring Nov. 30, 2020, 5:22 p.m. UTC | #2
On Thu, 26 Nov 2020 19:45:56 +0100, AngeloGioacchino Del Regno wrote:
> Add the bindings for the CPR3 driver to the documentation.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
> ---
>  .../bindings/soc/qcom/qcom,cpr3.yaml          | 226 ++++++++++++++++++
>  1 file changed, 226 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml: properties:clock-names: [{'const': 'ref'}] is not of type 'object', 'boolean'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml: ignoring, error in schema: properties: clock-names
warning: no schema found in file: ./Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml
Error: Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.example.dts:39.9-30 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:342: Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1364: dt_binding_check] Error 2


See https://patchwork.ozlabs.org/patch/1406856

The base for the patch is generally the last rc1. Any dependencies
should be noted.

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.
Viresh Kumar Dec. 18, 2020, 7:16 a.m. UTC | #3
On 26-11-20, 19:45, AngeloGioacchino Del Regno wrote:
> On new SoCs (SDM845 onwards) the Operating State Manager (OSM) is
> being programmed in the bootloader and write-protected by the
> hypervisor, leaving to the OS read-only access to some of its
> registers (in order to read the Lookup Tables and also some
> status registers) and write access to the p-state register, for
> for the OS to request a specific performance state to trigger a
> DVFS switch on the CPU through the OSM hardware.
> 
> On old SoCs though (MSM8998, SDM630/660 and variants), the
> bootloader will *not* initialize the OSM (and the CPRh, as it
> is a requirement for it) before booting the OS, making any
> request to trigger a performance state change ineffective, as
> the hardware doesn't have any Lookup Table, nor is storing any
> parameter to trigger a DVFS switch. In this case, basically all
> of the OSM registers are *not* write protected for the OS, even
> though some are - but write access is granted through SCM calls.
> 
> This commit introduces support for OSM programming, which has to
> be done on these old SoCs that were distributed (almost?) always
> with a bootloader that does not do any CPRh nor OSM init before
> booting the kernel.
> In order to program the OSM on these SoCs, it is necessary to
> fullfill a "special" requirement: the Core Power Reduction
> Hardened (CPRh) hardware block must be initialized, as the OSM
> is "talking" to it in order to perform the Voltage part of DVFS;
> here, we are calling initialization of this through Linux generic
> power domains, specifically by requesting a genpd attach from the
> qcom-cpufreq-hw driver, which will give back voltages associated
> to each CPU frequency that has been declared in the OPPs, scaled
> and interpolated with the previous one, and will also give us
> parameters for the Array Power Mux (APM) and mem-acc, in order
> for this driver to be then able to generate the Lookup Tables
> that will be finally programmed to the OSM hardware.
> 
> After writing the parameters to the OSM and enabling it, all the
> programming work will never happen anymore until a OS reboot, so
> all of the allocations and "the rest" will be disposed-of: this
> is done mainly to leave the code that was referred only to the
> new SoCs intact, as to also emphasize on the fact that the OSM
> HW is, in the end, the exact same; apart some register offsets
> that are slightly different, the entire logic is the same.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
> ---
>  drivers/cpufreq/qcom-cpufreq-hw.c | 914 +++++++++++++++++++++++++++++-
>  1 file changed, 884 insertions(+), 30 deletions(-)

This is a lot of code, I need someone from Qcom's team to review it
and make sure it doesn't break anything for the existing platforms.