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: <AM0PR04MB643434FB6A26B4D70F52F350EE080@AM0PR04MB6434.eurprd04.prod.outlook.com>
Date:   Tue, 14 May 2019 19:34:10 +0000
From:   Leonard Crestez <leonard.crestez@....com>
To:     Alexandre Bailon <abailon@...libre.com>,
        Jacky Bai <ping.bai@....com>
CC:     Michael Turquette <mturquette@...libre.com>,
        Linux PM list <linux-pm@...r.kernel.org>,
        Georgi Djakov <georgi.djakov@...aro.org>,
        Patrick Titiano <ptitiano@...libre.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Emilio Lopez <emilio@...pez.com.ar>,
        Hans de Goede <hdegoede@...hat.com>,
        linux-clk <linux-clk@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Zening Wang <zening.wang@....com>,
        Aisheng Dong <aisheng.dong@....com>,
        Kevin Hilman <khilman@...libre.com>,
        Carlo Caione <ccaione@...libre.com>,
        dl-linux-imx <linux-imx@....com>,
        Anson Huang <anson.huang@....com>,
        Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [RFC PATCH 0/3] Add support of busfreq

On 15.03.2019 18:55, Alexandre Bailon wrote:
>> On Wed, Mar 13, 2019 at 12:33 PM Alexandre Bailon <abailon@...libre.com> wrote:

>>> 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.
>>
>> It's not clear to me whether this series actual scales the dram
>> frequency based on what you said above. Is it just theoretical or do
>> you have it working with a pile of out-of-tree patches? Would be good
>> to include that pile of patches in your integration branch that I
>> suggested above.

> The current series only introduce busfreq generic driver, and the
> busfreq driver for the imx8mm.
> As is, the imx8mm driver will just be loaded, but do nothing because
> none of the drivers have been updated to request bandwidth using the
> interconnect framework.
> 
> My intent was to sent a first draft o busfreq, to get some feedback,
> before to send a more complete, and fully functional series.

It's been a while since this was first posted and imx8mm now boots fine 
in linux-next. Is there a more up-to-date WIP branch somewhere? 
Otherwise I can try to hack this series into a bootable form.

 > In addition, the current clock driver of imx8mm doesn't allow dram
 > frequency scaling, so if busfreq driver tries, it will fail (should be
 > harmless because any other clocks should restored to their previous
 > rate).

I'm confused about this. In NXP tree the actual DRAM switch is done 
inside ATF via SIP calls and involves corralling all CPUs. Do you want 
an "dram" clk which wraps the SIP calls required to changing dram 
frequency and root switching etc?

I've been looking at the busfreq implementation in the NXP tree and 
refactoring just the "dram freq switch" behind a clk might work nicely.

This would be similar to the imx_cpu clk used for cpufreq-dt and it 
might even be possible to upstream this separately from the rest of 
busfreq logic dealing with device requests.


I haven't done a very careful review but I noticed you're not using the 
OPP framework and instead redefined everything? It's not clear why.

--
Regards,
Leonard