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
