On 23.08.19 16:36, 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. > > The devfreq parts are posted separately, this series only intersects in > devicetree: https://patchwork.kernel.org/cover/11104113/ > > 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 this > > The rest of the changes are small and deal with review comments. > hi Leonard, When I run https://github.com/cdleonard/linux/tree/next_imx_busfreq and https://github.com/cdleonard/arm-trusted-firmware/tree/imx_2.0.y_busfreq on imx8mq, probe() fails: [ 1.082847] imx-ddrc-devfreq 3d400000.dram-controller: failed to init firmware freq info: -19 [ 1.091434] imx-ddrc-devfreq: probe of 3d400000.dram-controller rejects match -19 in imx_ddrc_init_freq_info()'s check: if (priv->freq_count <= 0 || priv->freq_count > IMX_DDRC_MAX_FREQ_COUNT) That would indicate that I'm missing something in ATF? I'm pretty sure I'm running your tree though. Does anything come to your mind what I might be doing wrong? Am I running your "correct" linux tree? Remember I'm on imx8mq, so I don't exactly test this RFC of yours. Also, how are your plans to rebase / update your ATF tree? And since there's a lot in there: what additions are necessary for this devfreq to work? Lastly, how do you test? Is /sys/class/devfreq supposted to get populated? thanks for your work! martin
