All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Sibi Sankar <sibis@codeaurora.org>
Cc: bjorn.andersson@linaro.org, mka@chromium.org, robh+dt@kernel.org,
	viresh.kumar@linaro.org, agross@kernel.org, rjw@rjwysocki.net,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	dianders@chromium.org, tdas@codeaurora.org
Subject: Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
Date: Thu, 5 Aug 2021 11:25:36 -0700	[thread overview]
Message-ID: <CAE-0n53b2M7hAw=NnUDW1_EG2N-521K=URQHmARH0DmLf7hwhA@mail.gmail.com> (raw)
In-Reply-To: <352d549f40dfa2ae51589649652d2e97@codeaurora.org>

Quoting Sibi Sankar (2021-08-05 10:47:20)
> Stephen,
>
> Thanks for taking time to review
> the series.
>
> On 2021-08-05 00:31, Stephen Boyd wrote:
> > Quoting Sibi Sankar (2021-07-29 11:04:43)
> >> Qualcomm SoCs (starting with SM8350) support per core voting for L3
> >> cache
> >> frequency.
> >
> > And the L3 cache frequency voting code can't be put into this cpufreq
> > driver?
>
> Yes, it could have gone either into
> the cpufreq driver or l3 interconnect
> provider driver. Taniya/Odelu preferred
> the latter, because of the need for other
> clients to vote for l3 frequencies in
> the future.

What other clients are those?

> The other option to prevent
> register re-arrangement would involve
> using syscons from the cpufreq node, which
> really wasn't necessary since there
> wasn't any register overlap between the
> two drivers.

Let's not do that.

>
> >
> >> So, re-arrange the cpufreq register offsets to allow access for
> >> the L3 interconnect to implement per core control. Also prevent
> >> binding
> >> breakage caused by register offset shuffling by using the
> >> SM8250/SM8350
> >> EPSS compatible.
> >>
> >> Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
> >> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> >> ---
> >>  drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++----
> >>  1 file changed, 19 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
> >> b/drivers/cpufreq/qcom-cpufreq-hw.c
> >> index f86859bf76f1..74ef3b38343b 100644
> >> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> >> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> >> @@ -28,6 +28,7 @@ struct qcom_cpufreq_soc_data {
> >>         u32 reg_volt_lut;
> >>         u32 reg_perf_state;
> >>         u8 lut_row_size;
> >> +       bool skip_enable;
> >>  };
> >>
> >>  struct qcom_cpufreq_data {
> >> @@ -257,19 +258,31 @@ static const struct qcom_cpufreq_soc_data
> >> qcom_soc_data = {
> >>         .reg_volt_lut = 0x114,
> >>         .reg_perf_state = 0x920,
> >>         .lut_row_size = 32,
> >> +       .skip_enable = false,
> >>  };
> >>
> >>  static const struct qcom_cpufreq_soc_data epss_soc_data = {
> >> +       .reg_freq_lut = 0x0,
> >> +       .reg_volt_lut = 0x100,
> >> +       .reg_perf_state = 0x220,
> >> +       .lut_row_size = 4,
> >> +       .skip_enable = true,
> >> +};
> >> +
> >> +static const struct qcom_cpufreq_soc_data epss_sm8250_soc_data = {
> >>         .reg_enable = 0x0,
> >>         .reg_freq_lut = 0x100,
> >>         .reg_volt_lut = 0x200,
> >>         .reg_perf_state = 0x320,
> >>         .lut_row_size = 4,
> >> +       .skip_enable = false,
> >>  };
> >>
> >>  static const struct of_device_id qcom_cpufreq_hw_match[] = {
> >>         { .compatible = "qcom,cpufreq-hw", .data = &qcom_soc_data },
> >>         { .compatible = "qcom,cpufreq-epss", .data = &epss_soc_data },
> >> +       { .compatible = "qcom,sm8250-cpufreq-epss", .data =
> >> &epss_sm8250_soc_data },
> >> +       { .compatible = "qcom,sm8350-cpufreq-epss", .data =
> >> &epss_sm8250_soc_data },
> >>         {}
> >>  };
> >>  MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
> >> @@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct
> >> cpufreq_policy *policy)
> >>         data->res = res;
> >>
> >>         /* HW should be in enabled state to proceed */
> >
> > It looks odd that we're no longer making sure that the clk domain is
> > enabled when we probe the driver. Why is that OK?
>
> On newer EPSS hw it's no longer
> required to perform the additional
> hw enable check. IIRC we don't do
> that on corresponding downstream
> kernels as well.

It's fairly clear that we no longer perform the additional check. The
question is why that's OK.

  reply	other threads:[~2021-08-05 18:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29 18:04 [PATCH 0/4] Fixup register offsets to support per core L3 DCVS Sibi Sankar
2021-07-29 18:04 ` [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350 Sibi Sankar
2021-08-03 19:23   ` Rob Herring
2021-08-04 18:56   ` Stephen Boyd
2021-07-29 18:04 ` [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS Sibi Sankar
2021-08-04 19:01   ` Stephen Boyd
2021-08-05 17:47     ` Sibi Sankar
2021-08-05 18:25       ` Stephen Boyd [this message]
2021-08-06  6:42         ` Sibi Sankar
2021-08-04 23:11   ` Bjorn Andersson
2021-08-04 23:20     ` Bjorn Andersson
2021-07-29 18:04 ` [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node Sibi Sankar
2021-08-04 18:57   ` Stephen Boyd
2021-08-31 15:30   ` Matthias Kaehlcke
2021-08-31 17:04     ` Bjorn Andersson
2021-09-06  3:20       ` Sibi Sankar
2021-09-07 19:14         ` Doug Anderson
2021-07-29 18:04 ` [PATCH 4/4] arm64: dts: qcom: sm8350: " Sibi Sankar
2021-08-04 22:59   ` Bjorn Andersson
2021-08-04 23:58     ` Matthias Kaehlcke
2021-08-30  6:47       ` Sibi Sankar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAE-0n53b2M7hAw=NnUDW1_EG2N-521K=URQHmARH0DmLf7hwhA@mail.gmail.com' \
    --to=swboyd@chromium.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mka@chromium.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=sibis@codeaurora.org \
    --cc=tdas@codeaurora.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.