From: Viresh Kumar <viresh.kumar@linaro.org>
To: bjorn.andersson@linaro.org,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@somainline.org>
Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
ulf.hansson@linaro.org, jorge.ramirez-ortiz@linaro.org,
broonie@kernel.org, lgirdwood@gmail.com,
daniel.lezcano@linaro.org, nks@flawful.org, agross@kernel.org,
robh+dt@kernel.org, rjw@rjwysocki.net,
konrad.dybcio@somainline.org, martin.botka@somainline.org,
marijn.suijten@somainline.org, phone-devel@vger.kernel.org
Subject: Re: [PATCH 12/13] cpufreq: qcom-hw: Implement CPRh aware OSM programming
Date: Fri, 18 Dec 2020 12:46:21 +0530 [thread overview]
Message-ID: <20201218071621.i6bc2xgn6kthvmuw@vireshk-i7> (raw)
In-Reply-To: <20201126184559.3052375-13-angelogioacchino.delregno@somainline.org>
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.
--
viresh
next prev parent reply other threads:[~2020-12-18 7:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-26 18:45 [PATCH 00/13] Enable CPRh/3/4, CPU Scaling on various QCOM SoCs AngeloGioacchino Del Regno
2020-11-26 18:45 ` [PATCH 01/13] cpuidle: qcom_spm: Detach state machine from main SPM handling AngeloGioacchino Del Regno
2020-11-27 18:07 ` kernel test robot
2020-11-26 18:45 ` [PATCH 02/13] soc: qcom: spm: Implement support for SAWv4.1, SDM630/660 L2 AVS AngeloGioacchino Del Regno
2020-11-26 18:45 ` [PATCH 03/13] soc: qcom: spm: Add compatible for MSM8998 SAWv4.1 L2 AngeloGioacchino Del Regno
2020-11-26 18:45 ` [PATCH 04/13] cpufreq: blacklist SDM630/636/660 in cpufreq-dt-platdev AngeloGioacchino Del Regno
2020-11-26 18:45 ` [PATCH 05/13] soc: qcom: cpr: Move common functions to new file AngeloGioacchino Del Regno
2020-11-26 18:45 ` [PATCH 06/13] arm64: qcom: qcs404: Change CPR nvmem-names AngeloGioacchino Del Regno
2020-11-26 18:45 ` [PATCH 07/13] dt-bindings: avs: cpr: Convert binding to YAML schema AngeloGioacchino Del Regno
2020-11-30 17:03 ` Rob Herring
2020-11-26 18:45 ` [PATCH 08/13] soc: qcom: Add support for Core Power Reduction v3, v4 and Hardened AngeloGioacchino Del Regno
2020-11-26 18:45 ` [PATCH 09/13] MAINTAINERS: Add entry for Qualcomm CPRv3/v4/Hardened driver AngeloGioacchino Del Regno
2020-11-26 18:45 ` [PATCH 10/13] dt-bindings: soc: qcom: cpr3: Add bindings for CPR3 driver AngeloGioacchino Del Regno
2020-11-30 17:22 ` Rob Herring
2020-11-26 18:45 ` [PATCH 11/13] dt-bindings: cpufreq: Convert qcom-cpufreq-hw to YAML binding AngeloGioacchino Del Regno
2020-11-30 17:23 ` Rob Herring
2020-11-30 18:23 ` AngeloGioacchino Del Regno
2020-12-03 11:14 ` Manivannan Sadhasivam
2020-12-04 0:13 ` AngeloGioacchino Del Regno
2020-12-08 15:41 ` Manivannan Sadhasivam
2020-11-26 18:45 ` [PATCH 12/13] cpufreq: qcom-hw: Implement CPRh aware OSM programming AngeloGioacchino Del Regno
2020-12-18 7:16 ` Viresh Kumar [this message]
2020-11-26 18:45 ` [PATCH 13/13] dt-bindings: cpufreq: qcom-hw: Add bindings for 8998 AngeloGioacchino Del Regno
2020-12-08 18:11 ` Rob Herring
2020-12-22 21:11 ` AngeloGioacchino Del Regno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201218071621.i6bc2xgn6kthvmuw@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=agross@kernel.org \
--cc=angelogioacchino.delregno@somainline.org \
--cc=bjorn.andersson@linaro.org \
--cc=broonie@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jorge.ramirez-ortiz@linaro.org \
--cc=konrad.dybcio@somainline.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=martin.botka@somainline.org \
--cc=nks@flawful.org \
--cc=phone-devel@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).