From: Viresh Kumar <viresh.kumar@linaro.org>
To: Heiko Stuebner <heiko@sntech.de>
Cc: linux-pm@vger.kernel.org, linux-rockchip@lists.infradead.org,
Klaus Goger <klaus.goger@theobroma-systems.com>,
vincent.guittot@linaro.org
Subject: Re: cpufreq(-dt) with two clocks but one regulator
Date: Sun, 17 Sep 2017 18:24:16 -0700 [thread overview]
Message-ID: <20170918012416.GB17030@ubuntu> (raw)
In-Reply-To: <1515316.mHJbnBRRvK@phil>
Hi Heiko,
On 15-09-17, 00:53, Heiko Stuebner wrote:
> Hi Viresh,
>
> if possible I'd like a pointer in the right direction for the following
> situation:
>
> The rk3368 has two cpu clusters of 4 Cortex-A53 cores each, with separate
> clock supplies
These must be represented by two cpufreq policies no matter what. That's how the
hardware is.
> but sharing its supplying regulator.
That should be fine.
> It looks like it was
> originally meant for some switched big-little system, with the little
> cluster maxing out at 1.2GHz while the big cluster can reach 1.5GHz.
So, right now all can go to 1.5 GHz?
> This of course fails miserably with current cpufreq, as the two sets
> of operating points fight over control of the regulator
Why so? I am not sure I understood this part yet. Both the clusters should try
to set their constraints and the intersection should be selected by the
regulator core? Can you share the OPP tables, so that we can discuss more.
> and after talking
> with real-life users of the soc it seems most desireable to have all
> 8 cores available at 1.2GHz than only 4 at 1.5GHz max.
What's wrong with all at 1.5 GHz?
> But as the clock seems to be bound to the opp table itself simply sharing
> the table of course also doesn't work
No, the OPP table shouldn't be shared at all. Its something to be shared by a
cluster only.
> as only the first clock would be set.
>
>
> I'm currently only seeing somehow hacky options to solve this, so if you
> have some direction on how to solve something like this I would be really
> grateful :-)
I think it should just work, but otherwise as well we can update some framework
to make it work. Lets just get on the same line first and help me understand it
better.
--
viresh
next prev parent reply other threads:[~2017-09-18 1:24 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 [this message]
2017-09-18 22:40 ` Heiko Stuebner
2017-09-18 23:37 ` Doug Anderson
2017-09-19 9:19 ` Heiko Stübner
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=20170918012416.GB17030@ubuntu \
--to=viresh.kumar@linaro.org \
--cc=heiko@sntech.de \
--cc=klaus.goger@theobroma-systems.com \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=vincent.guittot@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).