From: "Heiko Stübner" <heiko@sntech.de>
To: Doug Anderson <dianders@chromium.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
Klaus Goger <klaus.goger@theobroma-systems.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: cpufreq(-dt) with two clocks but one regulator
Date: Tue, 19 Sep 2017 11:19:45 +0200 [thread overview]
Message-ID: <2997079.BKPG7M6LVv@diego> (raw)
In-Reply-To: <CAD=FV=W+rvgJuNO0gEPN02bYkkJt6i6um=YGjUoaKmyrFhhSiw@mail.gmail.com>
Hi Doug,
Am Montag, 18. September 2017, 16:37:56 CEST schrieb Doug Anderson:
> On Mon, Sep 18, 2017 at 3:40 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> > Current submitted OPPs can be found at
> > https://patchwork.kernel.org/patch/9908519/
> >
> > There were still issues with higher frequencies, so they don't list the
> > 1.2 or 1.5GHz yet.
> >
> > But opp sets pretty tight constraints. I.e. OPPs have of course one
> > preferred voltage, so you end up with u_volt_min = u_volt_max for each
> > operating point, thus the regulator also gets set in this way, removing
> > any
> > intersection and thus making the regulator framework fail to set a voltage
> > for one of the clusters.
> >
> > So for example, you have one cluster running at 600MHz@0.95V and the
> > other cluster running at 1008MHz@1.05V this results in regulator
> > constraints being
> >
> > 0.95V-0.95V
> >
> > and
> >
> > 1.05V-1.05V
> >
> > thus no intersection and whoever comes second looses.
>
> (Untested) Can't you change the opp table and use the fancier
> operating point descriptions that give <target min max>?
funny, that I never noticed that opps are also specified for
(target, min, max) values.
Thanks for pointing me to the right direction and this seems to
actually work. Although I noticed that obviously the max value
needs to always be the global maximum (1125000 here) for both
opp tables, to make the regulator framework happy.
> In theory the above is a more proper hardware description: AKA you're
> describing that it's OK to use the higher voltage even at lower
> operating points.
Thanks
Heiko
next prev parent reply other threads:[~2017-09-19 9:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-14 22:53 cpufreq(-dt) with two clocks but one regulator Heiko Stuebner
2017-09-18 1:24 ` Viresh Kumar
2017-09-18 22:40 ` Heiko Stuebner
2017-09-18 23:37 ` Doug Anderson
2017-09-19 9:19 ` Heiko Stübner [this message]
2017-09-19 15:25 ` Viresh Kumar
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=2997079.BKPG7M6LVv@diego \
--to=heiko@sntech.de \
--cc=dianders@chromium.org \
--cc=klaus.goger@theobroma-systems.com \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=vincent.guittot@linaro.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).