Re: [PATCH v9 5/6] soc: qcom: Add support for Core Power Reduction v3, v4 and Hardened

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

..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