linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Sibi Sankar <sibis@codeaurora.org>
Cc: bjorn.andersson@linaro.org, viresh.kumar@linaro.org,
	Sudeep Holla <sudeep.holla@arm.com>,
	swboyd@chromium.org, agross@kernel.org, robh+dt@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,
	mka@chromium.org
Subject: Re: [PATCH 2/2] arm64: dts: qcom: sc7280: Add cpu OPP tables
Date: Wed, 5 May 2021 09:49:08 +0100	[thread overview]
Message-ID: <20210505084908.3lynedmblmqagr72@bogus> (raw)
In-Reply-To: <1fc9fb8d9a94909ff9b7b76d598bd266@codeaurora.org>

Hi Sibi,

On Tue, May 04, 2021 at 11:55:10PM +0530, Sibi Sankar wrote:
> Hey Sudeep,
>
> Thanks for the review!
>
> On 2021-05-04 20:12, Sudeep Holla wrote:

[...]

> >
> > NACK, this breaks if there is a mismatch from what is read from the
> > hardware and what is presented in this table above. Either add it from the
> > some bootloader or other boot code to this table reading from the
> > hardware/firmware or find a way to link them without this.
> >
> > Sorry I had warned long back about this when such links were discussed
> > as part of interconnect binding.
>
> Not sure why this warrants a NACK, as this was consensus for mapping cpu
> freq to DDR/L3 bandwidth votes. (We use the same solution on SDM845 and
> SC7180). The opp tables are optional and when specified puts in votes for
> DDR/L3. In the future the table can be safely dropped when more useful
> devfreq governors are upstreamed.
> cpufreq: qcom: Don't add frequencies without an OPP

(You can always add commit sha to make it easy to search)

But I am not sure how this is related to the above commit anyways.

>
> I guess your main concern for breakage is ^^ commit? The original design is
> to list a super set of frequencies supported by all variants of the SoC
> along with the required DDR/L3 bandwidth values. When we run into
> non-documented frequency we just wouldn't put in bw votes for it which
> should be fine since the entire opp_table is optional. If this is the reason
> for the NACK I can try get it reverted with Matthias's ack.

No my main concern is this platform uses "qcom-cpufreq-hw" driver and the
fact that the OPPs are retrieved from the hardware lookup table invalidates
whatever we have in DT. In short it will be junk and becomes obsolete.
So what I suggested before is still valid. You simply can't have static
OPP tables in the DT for this platform. Do get some boot code to fetch the
same from the h/w LUT and patch to the DT or figure out any other way to
manage dynamically.

So NACK still stands for static addition of OPPs to the DT as in this patch.

--
Regards,
Sudeep

  parent reply	other threads:[~2021-05-05  8:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 14:28 [PATCH 0/2] DDR/L3 Scaling support on SC7280 SoCs Sibi Sankar
2021-04-30 14:28 ` [PATCH 1/2] cpufreq: blacklist SC7280 in cpufreq-dt-platdev Sibi Sankar
2021-05-03 16:20   ` Matthias Kaehlcke
2021-04-30 14:28 ` [PATCH 2/2] arm64: dts: qcom: sc7280: Add cpu OPP tables Sibi Sankar
2021-05-03 16:36   ` Matthias Kaehlcke
2021-05-04  7:05     ` Sibi Sankar
2021-05-04 14:42   ` Sudeep Holla
2021-05-04 18:25     ` Sibi Sankar
2021-05-04 19:16       ` Matthias Kaehlcke
2021-05-05  8:49       ` Sudeep Holla [this message]
2021-05-05 10:09         ` Sibi Sankar
2021-05-05 11:41           ` Sudeep Holla
2021-05-05 11:37         ` Viresh Kumar
2021-05-05 11:44           ` Sudeep Holla

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=20210505084908.3lynedmblmqagr72@bogus \
    --to=sudeep.holla@arm.com \
    --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=swboyd@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).