All of lore.kernel.org
 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 12:41:18 +0100	[thread overview]
Message-ID: <20210505114118.idblntcldomzgmab@bogus> (raw)
In-Reply-To: <5cc53032c1f9f4e0170559c006133f47@codeaurora.org>

On Wed, May 05, 2021 at 03:39:17PM +0530, Sibi Sankar wrote:
> On 2021-05-05 14:19, Sudeep Holla wrote:

[...]

> > 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.
>
> The table provides mapping to bandwidths which aren't available in the
> firmware though. In short we do have to store the mapping somewhere i.e. a
> mapping that lists all possible frequencies to its bandwidth requirements
> needs to be present and using a opp table with the interconnect bw bindings
> was the consensus reached.

I understand and that's exactly what I had pointed out earlier when I
mentioned that I had raised this concern previously.

> Given that a duplicate mapping that lists all possible frequencies to bw is
> inevitable

I disagree, it was made inevitable by not listening to all feedback, sorry.

> and Qualcomm has a way of listing all the supported frequencies for the SoC,
> I feel that dt breakage in the future should be a non-concern.

I don't completely understand this TBH. Also my main worry is as we move more
towards abstract scale and/or index based, any addition or deletion of OPPs
results in change in the index or scale. It may be dealt on absolute scale
today everywhere and not a problem *today*, but it will break IMO.

> Not sure why you call it junk since it solves the perf/power requirements on
> SDM845/SC7180 SoCs. When it becomes obsolete it would mean that they are
> better devfreq governors available upstream and that's a good reason for the
> opp tables to go away.
>

Nope, I meant the firmware updates the OPP table underneath for whatever
valid reasons it may have.

> > 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.
>
> moving the logic to boot loader doesn't magically fix your concerns though
> (since it would also need a superset of available frequencies).


OK that's interesting. I wanted to fetch the exact list from the hardware
every time.

> It will suffer from the same problems with an additional dependency on
> firmware propagation in case of breakages which is something you can avoid
> for the simple cpu based scaling solution.

IMO the cross dependency is one part of problem and fetching the exact list
of OPPs available for the CPU is another. I meant to fix the latter in boot
code. The former is something I assume DT bindings deals with.

> >
> > So NACK still stands for static addition of OPPs to the DT as in this
> > patch.
>
> I'll let Viresh take the call since this solution is already used on older SoCs.

Sure, definitely I am just expressing my concern with NACK and I don't have
the final say 😁.

--
Regards,
Sudeep

  reply	other threads:[~2021-05-05 11:41 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
2021-05-05 10:09         ` Sibi Sankar
2021-05-05 11:41           ` Sudeep Holla [this message]
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=20210505114118.idblntcldomzgmab@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 \
    --subject='Re: [PATCH 2/2] arm64: dts: qcom: sc7280: Add cpu OPP tables' \
    /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

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.