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

From: Leonard Crestez
Date: Fri Mar 15 2019 - 13:17:59 EST


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