linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Rajendra Nayak <rnayak@codeaurora.org>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: Stanimir Varbanov <stanimir.varbanov@linaro.org>,
	robh+dt@kernel.org, agross@kernel.org,
	bjorn.andersson@linaro.org, linux-arm-msm@vger.kernel.org,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, mka@chromium.org,
	Taniya Das <tdas@codeaurora.org>
Subject: Re: [PATCH v4 4/5] arm64: dts: sdm845: Add OPP tables and power-domains for venus
Date: Mon, 27 Jul 2020 17:52:12 -0700	[thread overview]
Message-ID: <159589753282.1360974.11628682178494669632@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20200727153806.kgegadvghmkevch3@vireshk-mac-ubuntu>

Quoting Viresh Kumar (2020-07-27 08:38:06)
> On 27-07-20, 17:38, Rajendra Nayak wrote:
> > On 7/27/2020 11:23 AM, Rajendra Nayak wrote:
> > > On 7/24/2020 7:39 PM, Stanimir Varbanov wrote:
> > > > > > +
> > > > > > +                opp-533000000 {
> > > > > > +                    opp-hz = /bits/ 64 <533000000>;
> 
> Is this the highest OPP in table ?
> 
> > > > Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
> > > > defines 533000000 but the real calculated freq is 533000097.
> > > 
> > > I still don't quite understand why the videocc driver returns this
> > > frequency despite this not being in the freq table.
> > 
> > Ok, so I see the same issue on sc7180 also. clk_round_rate() does seem to
> > return whats in the freq table, but clk_set_rate() goes ahead and sets it

I'm happy to see clk_round_rate() return the actual rate that would be
achieved and not just the rate that is in the frequency tables. Would
that fix the problem? It may be that we need to make clk_round_rate() do
some more math on qcom platforms and actually figure out what the rate
is going to be instead of blindly trust the frequency that has been set
in the tables.

> > to 533000097. Subsequently when we try to set a different OPP, it fails to
> > find the 'current' OPP entry for 533000097. This sounds like an issue with the OPP
> > framework? Should we not fall back to the highest OPP as the current OPP?
> > 
> > Stephen/Viresh, any thoughts?
> 
> I think we (in all frameworks generally) try to set a frequency <=
> target frequency and so there may be a problem if the frequency is
> larger than highest supported. IOW, you need to fix tables a bit.
> 

Rounding is annoying for sure.

  reply	other threads:[~2020-07-28  0:52 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-23 11:26 [PATCH v4 0/5] DVFS support for Venus Rajendra Nayak
2020-07-23 11:26 ` [PATCH v4 1/5] dt-bindings: media: venus: Add an optional power domain for perf voting Rajendra Nayak
2020-07-23 17:30   ` Rob Herring
2020-07-23 11:26 ` [PATCH v4 2/5] media: venus: core: Fix error handling in probe Rajendra Nayak
2020-07-24 14:55   ` Stanimir Varbanov
2020-07-23 11:26 ` [PATCH v4 3/5] media: venus: core: Add support for opp tables/perf voting Rajendra Nayak
2020-07-26 12:47   ` Stanimir Varbanov
2020-07-23 11:26 ` [PATCH v4 4/5] arm64: dts: sdm845: Add OPP tables and power-domains for venus Rajendra Nayak
2020-07-23 18:06   ` Stanimir Varbanov
2020-07-24  8:49     ` Rajendra Nayak
2020-07-24 10:16       ` Stanimir Varbanov
2020-07-24  9:02     ` Rajendra Nayak
2020-07-24 16:28       ` Lina Iyer
2020-07-24 16:52         ` Stanimir Varbanov
2020-07-24 17:00           ` Stanimir Varbanov
2020-07-28  0:45         ` Stephen Boyd
2020-07-28 16:52           ` Lina Iyer
2020-07-28 19:51             ` Stephen Boyd
2020-07-28 20:11               ` Lina Iyer
2020-07-29 18:10                 ` Doug Anderson
2020-07-29 20:38                 ` Bjorn Andersson
2020-07-24 14:09     ` Stanimir Varbanov
2020-07-27  5:53       ` Rajendra Nayak
2020-07-27 12:08         ` Rajendra Nayak
2020-07-27 15:38           ` Viresh Kumar
2020-07-28  0:52             ` Stephen Boyd [this message]
2020-07-28  4:17               ` Rajendra Nayak
2020-07-28 19:54                 ` Stephen Boyd
2020-07-23 11:26 ` [PATCH v4 5/5] arm64: dts: sc7180: " Rajendra Nayak

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=159589753282.1360974.11628682178494669632@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mka@chromium.org \
    --cc=rnayak@codeaurora.org \
    --cc=robh+dt@kernel.org \
    --cc=stanimir.varbanov@linaro.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 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).