[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGETcx8MuXkQyD5qZBC948-hOu=kWd4hPk2Qiu-zWOcHBCc=FA@mail.gmail.com>
Date: Mon, 24 Jun 2019 22:00:37 -0700
From: Saravana Kannan <saravanak@...gle.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: MyungJoo Ham <myungjoo.ham@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
Stephen Boyd <sboyd@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Android Kernel Team <kernel-team@...roid.com>,
Linux PM <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov
On Mon, Jun 24, 2019 at 9:11 PM Viresh Kumar <viresh.kumar@...aro.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
Powered by blists - more mailing lists