Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Leonard Crestez <leonard.crestez@nxp.com>
To:     Anson Huang <anson.huang@nxp.com>,
        Alexandre Bailon <abailon@baylibre.com>,
        Jacky Bai <ping.bai@nxp.com>,
        Georgi Djakov <georgi.djakov@linaro.org>
CC:     Michael Turquette <mturquette@baylibre.com>,
        Linux PM list <linux-pm@vger.kernel.org>,
        Patrick Titiano <ptitiano@baylibre.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Stephen Boyd <sboyd@codeaurora.org>,
        Emilio Lopez <emilio@elopez.com.ar>,
        Hans de Goede <hdegoede@redhat.com>,
        linux-clk <linux-clk@vger.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        Zening Wang <zening.wang@nxp.com>,
        Aisheng Dong <aisheng.dong@nxp.com>,
        Kevin Hilman <khilman@baylibre.com>,
        Carlo Caione <ccaione@baylibre.com>,
        dl-linux-imx <linux-imx@nxp.com>,
        Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [RFC PATCH 0/3] Add support of busfreq
Thread-Topic: [RFC PATCH 0/3] Add support of busfreq
Thread-Index: AQHU2dO+g7FtRU5+MUaLzLMJn01eLA==
Date:   Tue, 4 Jun 2019 20:13:18 +0000
Message-ID: <VI1PR04MB5055E9AB9BD3D68BB6C1F6C2EE150@VI1PR04MB5055.eurprd04.prod.outlook.com>
References: <20190313193408.23740-1-abailon@baylibre.com>
 <CAEG3pNA+U1tw4sWq9i2cTni6QKQkLyd3qyZXd2i8M7WFDF4ZsQ@mail.gmail.com>
 <8af96425-a6f5-0114-7abb-c2a67b952e1b@baylibre.com>
 <AM0PR04MB643434FB6A26B4D70F52F350EE080@AM0PR04MB6434.eurprd04.prod.outlook.com>
 <DB3PR0402MB39167B9EAE9A741AB0F20E30F5150@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fc6a45d7-1d39-4d95-c153-08d6e92915a8
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2019 20:13:18.4216
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: leonard.crestez@nxp.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5919
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 6/4/2019 11:44 AM, Anson Huang wrote:=0A=
>>>>> As exemple, this series implements busfreq for i.MX8MM whose=0A=
>>>>> upstreaming is in progress. Because this relies on ATF to do the=0A=
>>>>> frequency scaling, it won't be hard make it work.=0A=
> =0A=
> I have similar question as previous reviewer, is there any branch that we=
 can test=0A=
> this series?=0A=
=0A=
I've been looking at this and pushed a fixed-up functional variant to my =
=0A=
personal github:=0A=
=0A=
     https://github.com/cdleonard/linux/commits/next_imx8mm_busfreq=0A=
=0A=
It builds and probes and switches DRAM freq between low and high based =0A=
on whether ethernet is down or up (for testing purposes). The pile of =0A=
out-of-tree patches required to get this work is quite small.=0A=
=0A=
The DRAM freq switch is done via a clk wrapper previously sent as RFC:=0A=
=0A=
     https://patchwork.kernel.org/patch/10968303/=0A=
=0A=
That part needs more work but it could serve as a neat encapsulation =0A=
similar to imx_cpu clk used for cpufreq-dt.=0A=
=0A=
> And, from the patch, it has multiple levels description of fabric arch, w=
hile we ONLY=0A=
> intend to scale "bus" frequency per devices' request, here "bus" includes=
 DRAM, NOC and=0A=
> AHB, AXI, should we make it more flatter, such as just a virtual fabric a=
s a single provider, and then=0A=
> all other devices as nodes under this provider?=0A=
=0A=
The imx8mm interconnect bindings describe many bus endpoints but all =0A=
requests are aggregated to a single platform-level OPP which is =0A=
equivalent to "low/audio/high mode" from NXP tree.=0A=
=0A=
It might be better to associate clks to several ICC nodes and this way =0A=
scale NOC and DRAM separately? As far as I understand an interconnect =0A=
provider is free to decide on granularity.=0A=
=0A=
As a wilder idea it might even be possible to use a stanard =0A=
"devfreq-with-perfmon" for DDRC and have interconnect request a min freq =
=0A=
to that instead of doing clk_set_rate on dram directly. That could bring =
=0A=
features from both worlds, scaling both proactively and reactively.=0A=
=0A=
--=0A=
Regards,=0A=
Leonard=0A=