Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <dfecf744-30c6-e9b5-5a75-045aca840cae@collabora.com>
Date:   Wed, 18 Jan 2023 13:50:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: [PATCH v9 5/6] soc: qcom: Add support for Core Power Reduction
 v3, v4 and Hardened
Content-Language: en-US
To:     Konrad Dybcio <konrad.dybcio@linaro.org>,
        Robert Marko <robimarko@gmail.com>,
        linux-arm-msm@vger.kernel.org, andersson@kernel.org,
        agross@kernel.org, krzysztof.kozlowski@linaro.org
Cc:     marijn.suijten@somainline.org,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@somainline.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Mark Brown <broonie@kernel.org>, linux-kernel@vger.kernel.org
References: <20230116093845.72621-1-konrad.dybcio@linaro.org>
 <20230116093845.72621-6-konrad.dybcio@linaro.org>
 <5ced2e01-367f-5e0d-8120-aa5ef4d4eeab@gmail.com>
 <233f0d52-4f9d-a512-0450-77e2fb4da878@linaro.org>
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>
In-Reply-To: <233f0d52-4f9d-a512-0450-77e2fb4da878@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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