* cpufreq(-dt) with two clocks but one regulator
@ 2017-09-14 22:53 Heiko Stuebner
2017-09-18 1:24 ` Viresh Kumar
0 siblings, 1 reply; 6+ messages in thread
From: Heiko Stuebner @ 2017-09-14 22:53 UTC (permalink / raw)
To: Viresh Kumar; +Cc: linux-pm, linux-rockchip, Klaus Goger
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 but sharing its supplying regulator. 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.
This of course fails miserably with current cpufreq, as the two sets
of operating points fight over control of the regulator 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.
But as the clock seems to be bound to the opp table itself simply sharing
the table of course also doesn't work, 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 :-)
Thanks
Heiko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cpufreq(-dt) with two clocks but one regulator
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
0 siblings, 1 reply; 6+ messages in thread
From: Viresh Kumar @ 2017-09-18 1:24 UTC (permalink / raw)
To: Heiko Stuebner; +Cc: linux-pm, linux-rockchip, Klaus Goger, vincent.guittot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cpufreq(-dt) with two clocks but one regulator
2017-09-18 1:24 ` Viresh Kumar
@ 2017-09-18 22:40 ` Heiko Stuebner
2017-09-18 23:37 ` Doug Anderson
0 siblings, 1 reply; 6+ messages in thread
From: Heiko Stuebner @ 2017-09-18 22:40 UTC (permalink / raw)
To: Viresh Kumar; +Cc: linux-pm, linux-rockchip, Klaus Goger, vincent.guittot
Hi Viresh,
Am Sonntag, 17. September 2017, 18:24:16 CEST schrieb Viresh Kumar:
> On 15-09-17, 00:53, Heiko Stuebner wrote:
> > 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?
No, the little cluster of 4 cores is rated at 1.2GHz max, while the big
cluster of 4 cores is rated at 1.5Ghz
> > 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.
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.
> > 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?
Only one of the two clusters can do that, see above.
> > 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.
Yeah, with dt (and OPPs) being a hardware description that is true.
> > 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.
Heiko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cpufreq(-dt) with two clocks but one regulator
2017-09-18 22:40 ` Heiko Stuebner
@ 2017-09-18 23:37 ` Doug Anderson
2017-09-19 9:19 ` Heiko Stübner
0 siblings, 1 reply; 6+ messages in thread
From: Doug Anderson @ 2017-09-18 23:37 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Viresh Kumar, open list:ARM/Rockchip SoC..., Klaus Goger,
Vincent Guittot, linux-pm@vger.kernel.org
Heiko,
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>?
cluster0_opp: opp-table0 {
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp-hz = /bits/ 64 <312000000>;
opp-microvolt = <950000 950000 1050000>;
clock-latency-ns = <40000>;
};
opp01 {
opp-hz = /bits/ 64 <408000000>;
opp-microvolt = <950000 950000 1050000>;
};
opp02 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <950000 950000 1050000>;
};
opp03 {
opp-hz = /bits/ 64 <816000000>;
opp-microvolt = <1025000 1025000 1050000>;
};
opp04 {
opp-hz = /bits/ 64 <1008000000>;
opp-microvolt = <1125000 1125000 1050000>;
};
};
cluster1_opp: opp-table1 {
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp-hz = /bits/ 64 <312000000>;
opp-microvolt = <950000 950000 1125000>;
clock-latency-ns = <40000>;
};
opp01 {
opp-hz = /bits/ 64 <408000000>;
opp-microvolt = <950000 950000 1125000>;
};
opp02 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <950000 950000 1125000>;
};
opp03 {
opp-hz = /bits/ 64 <816000000>;
opp-microvolt = <975000 975000 1125000>;
};
opp04 {
opp-hz = /bits/ 64 <1008000000>;
opp-microvolt = <1050000>;
};
};
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.
-Doug
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cpufreq(-dt) with two clocks but one regulator
2017-09-18 23:37 ` Doug Anderson
@ 2017-09-19 9:19 ` Heiko Stübner
2017-09-19 15:25 ` Viresh Kumar
0 siblings, 1 reply; 6+ messages in thread
From: Heiko Stübner @ 2017-09-19 9:19 UTC (permalink / raw)
To: Doug Anderson
Cc: Viresh Kumar, open list:ARM/Rockchip SoC..., Klaus Goger,
Vincent Guittot, linux-pm@vger.kernel.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cpufreq(-dt) with two clocks but one regulator
2017-09-19 9:19 ` Heiko Stübner
@ 2017-09-19 15:25 ` Viresh Kumar
0 siblings, 0 replies; 6+ messages in thread
From: Viresh Kumar @ 2017-09-19 15:25 UTC (permalink / raw)
To: Heiko Stübner
Cc: Doug Anderson, open list:ARM/Rockchip SoC..., Klaus Goger,
Vincent Guittot, linux-pm@vger.kernel.org
On 19-09-17, 11:19, Heiko Stübner wrote:
> Am Montag, 18. September 2017, 16:37:56 CEST schrieb Doug Anderson:
> > (Untested) Can't you change the opp table and use the fancier
> > operating point descriptions that give <target min max>?
And that's exactly what I was going to suggest :)
> 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.
Great.
--
viresh
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-09-19 15:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2017-09-19 15:25 ` Viresh Kumar
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).