On 10/01/2023 19:56, Konrad Dybcio wrote:
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@xxxxxxxxxxxxxx/
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.
MSM8996 is CPRv3, both CPU and GFX.
After hacking up 8996 I found it quite hard to retrofit it into this
driver. Especially if we look at the GFX CPR (it uses multiple ROs,
which this driver is not very well prepared for). I have the feeling
that this patchset/driver should concentrate on getting CPRh done. We
can consolidate CPR3/CPR3-GFX/CPR4/CPRh after getting (some of) them
done. In the least case I'd suggest using the per-generation functions
that call each other rather than having generation-conditional code in a
single big function.
Some design questions: how do you handle the mem-acc programming? My
understanding is that for CPR3 it should be set on a thread-by-thread
basis rather than having a single global setting. Does CPRh need
additional handling of APM or is it handled by the hardware?
For the reference, on msm8996, CPR3 has two threads (one for power and
one for performance clusters). And then the power thread should scale
accordingly to both power cluster and the CBF (an interconnect between
clusters).
And CPR3-GFX is a lightweight (or reduced) version of CPR3 (and of
course just a single thread/single vreg).
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 ;)
Tested on the following smartphones:
- Sony Xperia XA2 (SDM630)
- Sony Xperia XA2 Ultra (SDM630)
- Sony Xperia 10 (SDM630)
- Sony Xperia XZ Premium (MSM8998)
- F(x)Tec Pro 1 (MSM8998)
--
With best wishes
Dmitry
