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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <dfecf744-30c6-e9b5-5a75-045aca840cae@collabora.com>
Date:   Wed, 18 Jan 2023 13:50:39 +0100
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Robert Marko <robimarko@...il.com>,
        linux-arm-msm@...r.kernel.org, andersson@...nel.org,
        agross@...nel.org, krzysztof.kozlowski@...aro.org
Cc:     marijn.suijten@...ainline.org,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 5/6] soc: qcom: Add support for Core Power Reduction
 v3, v4 and Hardened

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