On 20.11.2019 17:41, Angus Ainslie wrote: > Hi Leonard, > > On 2019-11-20 07:04, Leonard Crestez wrote: >> On 20.11.2019 16:08, Angus Ainslie wrote: >>> Hi Leonard, >>> >>> On 2019-11-14 12:09, Leonard Crestez wrote: >>>> Add initial support for dynamic frequency switching on pieces of the >>>> imx >>>> interconnect fabric. >>>> >>>> All this driver does is set a clk rate based on an opp table, it does >>>> not map register areas. >>>> >>> >>> Is this working with mainline ATF or does it still need to be used >>> with your modified ATF code ? >> >> This series doesn't perform SMC calls, that's done by the imx8m-ddrc >> driver: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11244283%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7C186d3c14d8bc41216e3b08d76dd0106d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637098612732915017&sdata=ER10Ts4hk2Ft7%2FWBZ7r8lyFkB6un1VRwk0rSvRMm3ew%3D&reserved=0 >> >> This particular patch allows switching NOC frequency but that's just >> clk_set_rate. >> >> DDRC frequency switching requires the imx branch of ATF (v2.0 + ~200 >> patches) otherwise you will get probe failures. Source for imx atf is >> published here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Fimx-atf%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7C186d3c14d8bc41216e3b08d76dd0106d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637098612732915017&sdata=KcdzTQaW4xxualeRUU%2B9LjBeq99wUtzDBxrHWLVbkDo%3D&reserved=0 > > Ok I was under the impression that the imx_2.0.y_busfreq branch below > was based on this. Shouldn't those patches be added to the imx ATF ? Already done, it's just that CAF public releases are only made after internal testing. TF-A is open-source so I push patches to my personal github to help more adventurous developers. >> For your particular 8mq B0 case slightly different setpoints are used >> and the fix is not in any public release yet so you need this: >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcdleonard%2Farm-trusted-firmware%2Fcommits%2Fimx_2.0.y_busfreq&data=02%7C01%7Cleonard.crestez%40nxp.com%7C186d3c14d8bc41216e3b08d76dd0106d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637098612732925012&sdata=Ape5T7xfiR0yfSuO1Lv9OQhmK5p3f0ROWpzJiAMw1VA%3D&reserved=0 >> > > We also have 2n14w ( is that B1 ? ) imx8mq's that we are working with. Errata is e11327 and does not appear on 2N14W: https://www.nxp.com/docs/en/errata/IMX8MDQLQ_1N14W.pdf https://www.nxp.com/docs/en/errata/IMX8MDQLQ_2N14W.pdf You should be able to test with a published release: https://source.codeaurora.org/external/imx/imx-atf/log/?h=imx_4.19.35_1.1.0 >> Is "mainline ATF" an important criteria for Purism? > > Yes we intend to bring all of our patches to mainline and were hoping > that NXP would be doing the same. Shouldn't a mainline kernel run on a > mainline ATF ? You can still use mainline ATF (tested right now) but the imx8m-ddrc driver won't probe. The ability to mix and match different branches of firmware and kernel is very useful for testing. There might be slight incompatibilities but in theory if a feature depends on both firmware and kernel support then it should gracefully degrade rather than crash or hang. ATF support for this feature will be mainlined eventually, I picked the linux side first because review is more challenging and changes are much larger relative to what we have in our internal tree. -- Regards, Leonard
