linux-kernel - Re: [RFC PATCH 0/3] Add support of busfreq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <VI1PR04MB55334013173D78F365CA5E19EE440@VI1PR04MB5533.eurprd04.prod.outlook.com>
Date:   Fri, 15 Mar 2019 17:17:53 +0000
From:   Leonard Crestez <leonard.crestez@....com>
To:     Alexandre Bailon <abailon@...libre.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "georgi.djakov@...aro.org" <georgi.djakov@...aro.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
CC:     Aisheng Dong <aisheng.dong@....com>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "ptitiano@...libre.com" <ptitiano@...libre.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Zening Wang <zening.wang@....com>,
        "khilman@...libre.com" <khilman@...libre.com>,
        "ccaione@...libre.com" <ccaione@...libre.com>,
        Jacky Bai <ping.bai@....com>, dl-linux-imx <linux-imx@....com>,
        Ranjani Vaidyanathan <ranjani.vaidyanathan@....com>,
        Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [RFC PATCH 0/3] Add support of busfreq

On 3/15/19 11:31 AM, Alexandre Bailon wrote:
>>> This series is sent as RFC mostly because the current support of i.MX SoC won't
>>> benefit of busfreq framework, because the clocks' driver don't support
>>> interconnect / dram frequency scaling.
>>> As exemple, this series implements busfreq for i.MX8MM whose upstreaming
>>> is in progress. Because this relies on ATF to do the frequency scaling, it won't
>>> be hard make it work.

>> How can I test this patch series?
>> Any additional patches you can share with us?
>> Or what else we need to do to test it? We can help with it.

> Many other patches will be required to test the series.
> There are a couple of patches that updates i.MX device drivers to
> request for bandwidth (does similar thing as bus_freq_request and
> bus_freq_release).

The interconnect framework asks for bandwidth in bytes/second but in NXP 
tree most requests are of the form "request_bus_freq(BUS_FREQ_HIGH);". 
In many cases (ethernet) it doesn't seem you can calculate a specific 
bandwidth usefully.

Instead of asking for "infinite bandwidth zero latency" to force 
everything to "high" it would be nicer to "request an opp".

Power-domain bindings mentioned that consumer-devices can specify a 
"required-opps" property but I've found zero users in tree. Maybe some 
helpers could be written to parse that property and automatically 
request ICC opp on device suspend/resume via device-links?

I know that stuff was written for genpd but it looks like a very good 
fit to me.

> In addition, a patch to that allow to scale the DRAM
> frequency using CCF is required. I'm still working on this patch.

I'm not sure what you mean here, do you want a clk set_rate to change 
the DRAM freq? It makes sense for DDRC to be a node in the interconnect 
framework and switch OPP inside icc implementation via an ATF call.

--
Regards,
Leonard