On 18.12.2019 17:37, Adam Ford wrote: > On Wed, Dec 18, 2019 at 9:16 AM Leonard Crestez <leonard.crestez@xxxxxxx> wrote: >> >> On 18.12.2019 17:05, Adam Ford wrote: >>> On Wed, Dec 18, 2019 at 8:44 AM Leonard Crestez <leonard.crestez@xxxxxxx> wrote: >>>> >>>> On 18.12.2019 15:35, Adam Ford wrote: >>>>> On Fri, Nov 22, 2019 at 3:45 PM Leonard Crestez <leonard.crestez@xxxxxxx> wrote: >>>>>> >>>>>> This adds support for dynamic scaling of the DDR Controller (ddrc) >>>>>> present on i.MX8M series chips. Actual frequency switching is >>>>>> implemented inside TF-A, this driver wraps the SMC calls and >>>>>> synchronizes the clk tree. >>>>>> >>>>>> DRAM frequency switching requires clock manipulation but during this operation >>>>>> DRAM itself is briefly inaccessible so this operation is performed a SMC call >>>>>> to by TF-A which runs from a SRAM area. Upon returning to linux the clock tree >>>>>> is updated to correspond to hardware configuration. >>>>>> >>>>>> This is handled via CLK_GET_RATE_NO_CACHE for dividers but muxes are handled >>>>>> manually: the driver will prepare/enable the new parents ahead of switching (so >>>>>> that the expected roots are enabled) and afterwards it will call clk_set_parent >>>>>> to ensure the parents in clock framework are up-to-date. >>>>>> >>>>>> This series is useful standalone and roughly similar to devfreq drivers for >>>>>> tegra and rockchip. >>>>>> >>>>>> Running at lower dram rates saves power but can affect the functionality of >>>>>> other blocks in the chip (display, vpu etc). Support for in-kernel constraints >>>>>> will some separately. >>>>>> >>>>>> This series has no dependencies outside linux-next. The driver depends >>>>>> on features from the NXP branch of TF-A and will cleanly fail to probe >>>>>> on mainline. There are also plans to upstream dram dvfs in TF-A. >>>>>> >>>>>> Leonard Crestez (5): >>>>>> clk: imx8m: Set CLK_GET_RATE_NOCACHE on dram clocks >>>>>> clk: imx: Mark dram pll on 8mm and 8mn with CLK_GET_RATE_NOCACHE >>>>>> dt-bindings: memory: Add bindings for imx8m ddr controller >>>>>> PM / devfreq: Add dynamic scaling for imx8m ddr controller >>>>>> arm64: dts: imx8m: Add ddr controller nodes >>>>>> >>>>>> .../memory-controllers/fsl/imx8m-ddrc.yaml | 72 +++ >>>>>> arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 18 + >>>>>> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 10 + >>>>>> .../boot/dts/freescale/imx8mn-ddr4-evk.dts | 18 + >>>>>> arch/arm64/boot/dts/freescale/imx8mn.dtsi | 10 + >>>>>> arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 24 + >>>>>> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 10 + >>>>>> drivers/clk/imx/clk-imx8mm.c | 11 +- >>>>>> drivers/clk/imx/clk-imx8mn.c | 12 +- >>>>>> drivers/clk/imx/clk-imx8mq.c | 12 +- >>>>>> drivers/clk/imx/clk-pll14xx.c | 7 + >>>>>> drivers/clk/imx/clk.h | 1 + >>>>>> drivers/devfreq/Kconfig | 9 + >>>>> >>>>> Since there is a Kconfig change, should there me a defconfig change? >>>> >>>> Yes, you need to enable CONFIG_ARM_IMX8M_DDRC_DEVFREQ in order to test >>>> this. Enabling as "m" should work. >>> >>> I enabled it as 'm' but I was more curious to know if we should push >>> this upstream with the rest of the series. >> >> I skipped enabling because it's very experimental; maybe after imx >> interconnect is also enabled? >> >>>>>> drivers/devfreq/Makefile | 1 + >>>>>> drivers/devfreq/imx8m-ddrc.c | 465 ++++++++++++++++++ >>>>>> 15 files changed, 670 insertions(+), 10 deletions(-) >>>>>> create mode 100644 Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml >>>>>> create mode 100644 drivers/devfreq/imx8m-ddrc.c >>>>> >>>>> I applied the whole series against 5.5-rc1 and I am trying to test it. >>>>> I know the 4.14 kernel NXP posted on Code Aurora is capable to >>>>> lowering the DDRC controller to 25MHz on the 8MM when the video is >>>>> off. Since there is no video support yet for the 8MM, I was expecting >>>>> to see the DDRC clock to be at or around 25MHz. >>>>> >>>>> Using debug FS, I can see the dram core clock is still running at >>>>> 750MHz, and measuring power, it shows something consistent with what I >>>>> see on the Code Aurora kernel with video turned on and the clock at >>>>> 750MHz. >>>>> >>>>> Is there some way to get the dram_core_clk to drop to 25MHz to see >>>>> some power reduction? The same commands used in the Yocto build don't >>>>> apply here since we don't have video. >>>> >>>> Current upstream driver just keeps current frequency by default. Try the >>>> following: >>>> >>>> cd /sys/class/devfreq/devices/devfreq0 >>> >>> can't cd to /sys/class/devfreq/devices/devfreq0: No such file or directory >>> >>> I did some checking and I found: >>> imx8m-ddrc-devfreq 3d400000.memory-controller: failed to init >>> firmware freq info: -19 >>> >>> Was there some prerequisite patches I needed to apply before your series? >> >> You need a recent version of TF-A from nxp ( upstream). Try this: >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Fimx-atf%2Flog%2F%3Fh%3Dimx_4.19.35_1.1.0&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cc07fadd829994fe6293c08d783d02fa9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122802480130351&sdata=dVovGr1ttwrnSz39MPNNVg%2FB8HV5AjrHXGbksO3XvVo%3D&reserved=0 >> >> Or 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%7Cc07fadd829994fe6293c08d783d02fa9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122802480140347&sdata=Q9KPq60FOxJ7GflwupNaXvbqHIR40Ej5GxeY%2BhHI658%3D&reserved=0 >> >> Support on upstream ATF is not yet available > > I cloned your github branch and built it per the instructions in the > u-boot readme file. > did a make clean on u-boot, copied the bl31.bin to u-boot and rebuild > per U-Boot's instructions. > > U-Boot booted and Linux booted, but I still get: > > imx8m-ddrc-devfreq 3d400000.memory-controller: failed to init > firmware freq info: -19 Which version of u-boot is that, upstream? I'm subscribed to uboot mailing list and I see that imx8m support has its own separate issues but my familiarity is limited :( I've only ever tested with NXP uboot and the NXP version of mkimage: https://source.codeaurora.org/external/imx/uboot-imx/log/?h=imx_v2019.04_4.19.35_1.1.0 https://source.codeaurora.org/external/imx/imx-mkimage/ My bootloader prints the following BuildInfo: - ATF 70fa7bc - U-Boot 2019.04-00019-g4d377539a119 -- Regards, Leonard
