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

[Leonard Crestez]

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