[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f7c2f7dd-dcc7-4f3a-9c04-e370ba608de5@linaro.org>
Date: Thu, 7 Sep 2023 10:34:48 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Varadarajan Narayanan <quic_varada@...cinc.com>,
ilia.lin@...nel.org, agross@...nel.org, andersson@...nel.org,
rafael@...nel.org, viresh.kumar@...aro.org, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
mturquette@...libre.com, sboyd@...nel.org,
quic_kathirav@...cinc.com, linux-pm@...r.kernel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH v1 06/10] cpufreq: qti: Enable cpufreq for ipq53xx
On 7.09.2023 07:21, Varadarajan Narayanan wrote:
> IPQ53xx have different OPPs available for the CPU based on
> SoC variant. This can be determined through use of an eFuse
> register present in the silicon.
>
> Added support for ipq53xx on nvmem driver which helps to
> determine OPPs at runtime based on the eFuse register which
> has the CPU frequency limits. opp-supported-hw dt binding
> can be used to indicate the available OPPs for each limit.
>
> nvmem driver also creates the "cpufreq-dt" platform_device after
> passing the version matching data to the OPP framework so that the
> cpufreq-dt handles the actual cpufreq implementation.
>
> Signed-off-by: Kathiravan T <quic_kathirav@...cinc.com>
> Signed-off-by: Varadarajan Narayanan <quic_varada@...cinc.com>
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> drivers/cpufreq/qcom-cpufreq-nvmem.c | 15 +++++++++++++++
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 02ec58a..f0c45d4 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
Viresh probably picks up patches for both files, so it should
be fine, but I'd say it's 'eeeh' to edit 2 separate drivers at
once.
> @@ -178,6 +178,7 @@ static const struct of_device_id blocklist[] __initconst = {
> { .compatible = "ti,am625", },
> { .compatible = "ti,am62a7", },
>
> + { .compatible = "qcom,ipq5332", },
> { .compatible = "qcom,ipq8064", },
> { .compatible = "qcom,apq8064", },
> { .compatible = "qcom,msm8974", },
> diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> index 84d7033..49d21b0 100644
> --- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
> +++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> @@ -146,6 +146,20 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,
> return PTR_ERR(speedbin);
>
> switch (msm_id) {
> + case QCOM_ID_IPQ5332:
> + case QCOM_ID_IPQ5322:
> + case QCOM_ID_IPQ5312:
> + case QCOM_ID_IPQ5302:
> + case QCOM_ID_IPQ5300:
> + /* Fuse Value Freq BIT to set
> + * ---------------------------------
> + * 2’b00 No Limit BIT(0)
> + * 2’b01 1.5 GHz BIT(1)
> + * 2’b10 1.2 Ghz BIT(2)
> + * 2’b11 1.0 GHz BIT(3)
I think the last column is a bit excessive, it says exactly
the same as the line below.
Actually, with this data being present in the devicetree, perhaps
this comment could be entirely skipped.
Konrad
> + */
> + drv->versions = 1 << (unsigned int)(*speedbin);
> + break;
> case QCOM_ID_MSM8996:
> case QCOM_ID_APQ8096:
> drv->versions = 1 << (unsigned int)(*speedbin);
> @@ -359,6 +373,7 @@ static const struct of_device_id qcom_cpufreq_match_list[] __initconst = {
> { .compatible = "qcom,apq8096", .data = &match_data_kryo },
> { .compatible = "qcom,msm8996", .data = &match_data_kryo },
> { .compatible = "qcom,qcs404", .data = &match_data_qcs404 },
> + { .compatible = "qcom,ipq5332", .data = &match_data_kryo },
> { .compatible = "qcom,ipq8064", .data = &match_data_krait },
> { .compatible = "qcom,apq8064", .data = &match_data_krait },
> { .compatible = "qcom,msm8974", .data = &match_data_krait },
Powered by blists - more mailing lists