..snip..
+
+static const struct cpr_desc sdm630_cpr_desc = {
..snip..
+ },
+};
Hi Konrad, I am trying to add IPQ8074 support to CPR as its the last thing
missing for upstream CPU scaling, and I really want to get rid of the downstream driver.
However, I am having hard time figuring some of these parameters, some are easy to
read from the DTS or driver defines, however arent the fuse corners supposed to be read
from the fuses and not hardcocded in the thread structures?
They reside in socname-regulator.dtsi most of the time.
Some parameters are read from fuses (per-unit capabilities
that let your specific chip run at a specific voltage offset),
but there's also some per-SoC-model data that needs to be
taken into account when performing the calculations.. This
is actually a smart move from Qualcomm (well, for them
anyway), as they put as little data in fuses as possible,
saving them space on this tiiiiny ROM.
Mind you, I dont have any docs so I am mostly using the downstream kernel as the reference.
This driver doesn't do anything more than its downstream
counterpart, everything we need should be there on msm-X.Y.
One flaw in this revision is that it doesn't yet support
multiple speed bins, so if your SoC has n of those, you
may get confused by n sets of values.. This is easy to
improve on in future, but this initial submission is
already very fat to begin with..
Hello Robert, Konrad,
since it is a bit difficult to find and follow discussions started/written in
a random place of a file (and reviews, as well), can you please cut off the
unnecessary text before sending out a reply?
Anyway, the fuse corners are actually read from fuses; the values that you see
hardcoded are references and safety min/max values which purpose is to both
perform calculation after fuse reading and to ensure safety (example: you put
a wrong bits range to read from fuses, the driver saves you by refusing to set
a very high voltage on the CPU core[s]).
As for where to find the values, I personally don't precisely remember, as that
was done more than 1.5 years ago, but what I recall is that they're scattered
across multiple files, including devicetree and drivers.
I also remember that I had to add debugging prints to the downstream driver in
order to get one of the values right... but that may have been due to MSM8998
values being a bit strange.
Thanks,
Angelo
