cpufreq(-dt) with two clocks but one regulator

cpufreq(-dt) with two clocks but one regulator

[Heiko Stuebner]

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

Re: cpufreq(-dt) with two clocks but one regulator

[Viresh Kumar]

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

Re: cpufreq(-dt) with two clocks but one regulator

[Heiko Stuebner]

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

Re: cpufreq(-dt) with two clocks but one regulator

[Doug Anderson]

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

Re: cpufreq(-dt) with two clocks but one regulator

[Heiko Stübner]

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

Re: cpufreq(-dt) with two clocks but one regulator

[Viresh Kumar]

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