Messages in this thread | | | From | Leonard Crestez <> | Subject | Re: [RFC PATCH 0/3] Add support of busfreq | Date | Fri, 15 Mar 2019 17:17:53 +0000 |
| |
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
| |