Messages in this thread | | | Date | Wed, 18 Jan 2023 13:50:39 +0100 | Subject | Re: [PATCH v9 5/6] soc: qcom: Add support for Core Power Reduction v3, v4 and Hardened | From | AngeloGioacchino Del Regno <> |
| |
..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
| |