Hi Leonard, On 9/16/19 05:34, Leonard Crestez wrote: > On 23.08.2019 17:37, Leonard Crestez wrote: >> This series add imx support for interconnect via devfreq: the ICC >> framework is used to aggregate requests from devices and then those are >> converted to DEV_PM_QOS_MIN_FREQUENCY requests for devfreq. >> >> Since there is no single devicetree node that can represent the "interconnect" >> new API is added to allow individual devfreq nodes to act as parsing proxies >> all mapping to a single soc-level icc provider. This is still RFC >> because of this > > Any comments? I made a lot of changes relative to previous versions, > most of them solely to avoid adding a virtual node in DT bindings. > > The only current interconnect provider implementation is for qcom and it > uses a firmware node as the provider node (with #interconnect-cells). > However there is no obvious equivalent of that for imx and many other SOCs. Not sure if it will help, but have you seen the qcs404 interconnect driver? There is also mt8183 interconnect provider driver on LKML. > On imx there are multiple pieces of scalable fabric which can be defined > in DT as devfreq devices and it sort of makes sense to add > #interconnect-cells to those. However when it comes to describing the > SOC interconnect graph it's much more convenient to have a single > per-SOC platform driver. Is all the NoC configuration done only by ATF? Are there any NoC related memory mapped registers? Thanks, Georgi
