linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Saravana Kannan <saravanak@google.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Stephen Boyd <sboyd@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Android Kernel Team <kernel-team@android.com>,
	Linux PM <linux-pm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov
Date: Mon, 24 Jun 2019 22:00:37 -0700	[thread overview]
Message-ID: <CAGETcx8MuXkQyD5qZBC948-hOu=kWd4hPk2Qiu-zWOcHBCc=FA@mail.gmail.com> (raw)
In-Reply-To: <20190625041054.2ceuvnuuebc6hsr5@vireshk-i7>

On Mon, Jun 24, 2019 at 9:11 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 24-06-19, 15:17, Saravana Kannan wrote:
> > Here's an example. This can't be done today, but can be done with this change.
> >
> > In arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi you have something
> > like this with the following changes:
> >
> >         bus_g2d_400: bus0 {
> >                 compatible = "samsung,exynos-bus";
> >                 clocks = <&cmu_top CLK_ACLK_G2D_400>;
> >                 clock-names = "bus";
> >                 operating-points-v2 = <&bus_g2d_400_opp_table>;
> >                 status = "disabled";
> >         };
> >
> >         bus_noc2: bus9 {
> >                 compatible = "samsung,exynos-bus";
> >                 clocks = <&cmu_mif CLK_ACLK_BUS2_400>;
> >                 clock-names = "bus";
> >                 operating-points-v2 = <&bus_noc2_opp_table>;
> >                 status = "disabled";
> >         };
>
> And what is the relation between these two busses ?

I can't speak for the Exynos hardware. Maybe Chanwoo knows.

But a couple of common reasons to do this between devices are:
1. These were the combination of frequencies that were
validated/screen during the manufacturing process.
2. These are the sensible performance combinations between two devices
interacting with each other. So that when one runs fast the other
doesn't become the bottleneck.
3. Hardware bugs requiring some kind of frequency ratio between devices.

All of the cases above are some real world scenarios I've come across.
CPU and L2/L3 on ARM systems are a good example of (2) but the passive
governor doesn't work with CPUs yet. But I plan to work on that later
as that's not related to this patch series.

-Saravana

> >         bus_g2d_400_opp_table: opp_table2 {
> >                 compatible = "operating-points-v2";
> >                 opp-shared;
> >
> >                 opp-400000000 {
> >                         opp-hz = /bits/ 64 <400000000>;
> >                         opp-microvolt = <1075000>;
> > +                       required-opps = <&noc2_400>;
> >                 };
> >                 opp-267000000 {
> >                         opp-hz = /bits/ 64 <267000000>;
> >                         opp-microvolt = <1000000>;
> > +                       required-opps = <&noc2_200>;
> >                 };
> >                 opp-200000000 {
> >                         opp-hz = /bits/ 64 <200000000>;
> >                         opp-microvolt = <975000>;
> > +                       required-opps = <&noc2_200>;
> >                 };
> >                 opp-160000000 {
> >                         opp-hz = /bits/ 64 <160000000>;
> >                         opp-microvolt = <962500>;
> > +                       required-opps = <&noc2_134>;
> >                 };
> >                 opp-134000000 {
> >                         opp-hz = /bits/ 64 <134000000>;
> >                         opp-microvolt = <950000>;
> > +                       required-opps = <&noc2_134>;
> >                 };
> >                 opp-100000000 {
> >                         opp-hz = /bits/ 64 <100000000>;
> >                         opp-microvolt = <937500>;
> > +                       required-opps = <&noc2_100>;
> >                 };
> >         };
> >
> >         bus_noc2_opp_table: opp_table6 {
> >                 compatible = "operating-points-v2";
> >
> > -               opp-400000000 {
> > +               noc2_400: opp-400000000 {
> >                         opp-hz = /bits/ 64 <400000000>;
> >                 };
> > -               opp-200000000 {
> > +               noc2_200: opp-200000000 {
> >                         opp-hz = /bits/ 64 <200000000>;
> >                 };
> > -               opp-134000000 {
> > +               noc2_134: opp-134000000 {
> >                         opp-hz = /bits/ 64 <134000000>;
> >                 };
> > -               opp-100000000 {
> > +               noc2_100: opp-100000000 {
> >                         opp-hz = /bits/ 64 <100000000>;
> >                 };
> >         };
> >
> > Thanks,
> > Saravana
>
> --
> viresh

  reply	other threads:[~2019-06-25  5:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-22  0:34 [PATCH v1 0/3] Add required-opps support to devfreq passive gov Saravana Kannan
2019-06-22  0:34 ` [PATCH v1 1/3] OPP: Allow required-opps even if the device doesn't have power-domains Saravana Kannan
2019-06-22  0:34 ` [PATCH v1 2/3] OPP: Add function to look up required OPP's for a given OPP Saravana Kannan
2019-06-22 11:49   ` Chanwoo Choi
2019-06-22 21:41     ` Saravana Kannan
2019-06-23  4:27       ` Chanwoo Choi
2019-06-23  6:07         ` Saravana Kannan
2019-06-22  0:34 ` [PATCH v1 3/3] PM / devfreq: Add required OPPs support to passive governor Saravana Kannan
2019-06-22 12:00   ` Chanwoo Choi
2019-06-22 21:45     ` Saravana Kannan
2019-06-24  9:43 ` [PATCH v1 0/3] Add required-opps support to devfreq passive gov Viresh Kumar
2019-06-24 22:17   ` Saravana Kannan
2019-06-25  4:10     ` Viresh Kumar
2019-06-25  5:00       ` Saravana Kannan [this message]
2019-06-25  5:22         ` Viresh Kumar
2019-06-25  5:29           ` Saravana Kannan
2019-06-26  6:32             ` Viresh Kumar
2019-06-26 18:10               ` Saravana Kannan
2019-06-28  6:49                 ` Viresh Kumar
2019-06-28 20:26                   ` Saravana Kannan
2019-07-11 23:16                     ` Saravana Kannan

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='CAGETcx8MuXkQyD5qZBC948-hOu=kWd4hPk2Qiu-zWOcHBCc=FA@mail.gmail.com' \
    --to=saravanak@google.com \
    --cc=cw00.choi@samsung.com \
    --cc=kernel-team@android.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=sboyd@kernel.org \
    --cc=viresh.kumar@linaro.org \
    --cc=vireshk@kernel.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).