| Message ID | cover.1574458460.git.leonard.crestez@nxp.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | PM / devfreq: Add dynamic scaling for imx8m ddr controller | expand |
On Fri, Nov 22, 2019 at 3:45 PM Leonard Crestez <leonard.crestez@nxp.com> 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. > > Changes since v6: > * Replace ARCH_MXC || COMPILE_TEST with ARCH_MXC && HAVE_ARM_SMCCC > * Collect reviews > Link to v6: https://patchwork.kernel.org/cover/11244283/ > > I'd rather not fix COMPILE_TEST with ifdefs for this driver, if anything > that should be fixed in smccc header. ARCH_MXC doesn't imply SMCCC, it > also covers some very old chips which don't have it. > > Resending full series because that's the standard method. > > Changes since v5: > * Fix a dram_apb/dram_alt mixup in imx8m_ddrc_set_freq > * Make clk_get_parent_by_index static (kbuild robot) > * Adjust messages in imx8m_ddrc_set_freq > * Use a for loop inside imx8m_ddrc_check_opps instead of while > * More elaborate description in dt-bindings file. > Link to v5: https://patchwork.kernel.org/cover/11240289/ > > Changes since v4: > * Restore empty _get_dev_status: testing shows this is *NOT* optional. If > absent then switching to simple_ondemand governor will trigger an Oops. > * Keep clk registration on single-line in clk-imx8m* for consistency with rest > of the file. > * Drop explicit "select PM_OPP" > * Check for NULL new_dram_core_parent > * Rename "out_dis_" labels to out_disable_* > * Use dev_warn on imx8m_ddrc_set_freq error paths after SMC call (where > operation is not abandoned). > * More elaborate error messages in imx8m_ddrc_target > * More elaborate checks when fetching clks in imx8m_ddrc_set_freq > * Rename ddrc nodes to memory-controller@* as per devicetree.org "Generic Names > Recommendation" > * Defer perf support, it requires perf changes to fetch PMU by DT > Link to v4: https://patchwork.kernel.org/cover/11235685/ > > Changes since v3: > * Rename to imx8m-ddrc. Similar blocks are present on imx7d and imx8qxp/imx8qm > but soc integration is different. > * Move dt bindings to /memory-controllers/fsl/ > * Fix dt validation issues > * Fix imx8mm.dtsi ddrc referencing ddrc_opp_table which is only defined in evk > * Move opps to child of ddrc device node > * Only add imx_ddrc_get_dev_status in perf patch. > * Adjust print messages > Link to v3: https://patchwork.kernel.org/cover/11221935/ > > Changes since v2: > * Add support for entire imx8m family including imx8mq B0. > * Also mark dram PLLs as CLK_GET_RATE_NO_CACHE (required for imx8mq b0 low OPP) > * Explicitly update dram pll rate at the end of imx_ddrc_set_freq. > * Use do_div in imx-ddrc (kbuild robot) > * Improve explanations around adding CLK_GET_RATE_NO_CACHE to dram clks. > (Stephen Boyd) > * Handle ddrc devfreq-events earlier for fewer probe defers. > * Validate DDRC opp tables versus firmware: supported OPPs depend on board and > SOC revision. > * Move DDRC opp tables to board dts because they can vary based on ram type on > board. > * Verify DDRC rate is changed in clk tree and otherwise report an error. > * Change imx_ddrc_freq.rate to be measure in MT/s and round down from HZ in > imx_ddrc_find_freq instead. > * Split away from NOC scaling and interconnect support. > Link to v2: https://patchwork.kernel.org/cover/11104113/ > > Changes since v1: > * bindings: Stop using "contains" for "compatible" > * bindings: Set "additionalProperties: false" and document missing stuff. > * Remove (c) from NXP copyright notice > * Fix various checkpatch issues > * Remove unused dram_alt_root clk from imx-ddrc > Link to v1: https://patchwork.kernel.org/cover/11090649/ > > 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? > 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. thanks, adam > > -- > 2.17.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 18.12.2019 15:35, Adam Ford wrote: > On Fri, Nov 22, 2019 at 3:45 PM Leonard Crestez <leonard.crestez@nxp.com> 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. >> >> Changes since v6: >> * Replace ARCH_MXC || COMPILE_TEST with ARCH_MXC && HAVE_ARM_SMCCC >> * Collect reviews >> Link to v6: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11244283%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275120308&sdata=ZEZnG6pijjj4MObC99c6%2BvC8BFEfT1KLVxbJCNocoWw%3D&reserved=0 >> >> I'd rather not fix COMPILE_TEST with ifdefs for this driver, if anything >> that should be fixed in smccc header. ARCH_MXC doesn't imply SMCCC, it >> also covers some very old chips which don't have it. >> >> Resending full series because that's the standard method. >> >> Changes since v5: >> * Fix a dram_apb/dram_alt mixup in imx8m_ddrc_set_freq >> * Make clk_get_parent_by_index static (kbuild robot) >> * Adjust messages in imx8m_ddrc_set_freq >> * Use a for loop inside imx8m_ddrc_check_opps instead of while >> * More elaborate description in dt-bindings file. >> Link to v5: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11240289%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275130306&sdata=mMqglPQign%2B6NHgmDYoZ74%2FZeThGI6%2FgNkajo1VaHTI%3D&reserved=0 >> >> Changes since v4: >> * Restore empty _get_dev_status: testing shows this is *NOT* optional. If >> absent then switching to simple_ondemand governor will trigger an Oops. >> * Keep clk registration on single-line in clk-imx8m* for consistency with rest >> of the file. >> * Drop explicit "select PM_OPP" >> * Check for NULL new_dram_core_parent >> * Rename "out_dis_" labels to out_disable_* >> * Use dev_warn on imx8m_ddrc_set_freq error paths after SMC call (where >> operation is not abandoned). >> * More elaborate error messages in imx8m_ddrc_target >> * More elaborate checks when fetching clks in imx8m_ddrc_set_freq >> * Rename ddrc nodes to memory-controller@* as per devicetree.org "Generic Names >> Recommendation" >> * Defer perf support, it requires perf changes to fetch PMU by DT >> Link to v4: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11235685%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275130306&sdata=LXG4bo0l7FOttZIolJE73CK67AAAW72xfx8yq3Vld7o%3D&reserved=0 >> >> Changes since v3: >> * Rename to imx8m-ddrc. Similar blocks are present on imx7d and imx8qxp/imx8qm >> but soc integration is different. >> * Move dt bindings to /memory-controllers/fsl/ >> * Fix dt validation issues >> * Fix imx8mm.dtsi ddrc referencing ddrc_opp_table which is only defined in evk >> * Move opps to child of ddrc device node >> * Only add imx_ddrc_get_dev_status in perf patch. >> * Adjust print messages >> Link to v3: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11221935%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275130306&sdata=%2FFGddgm7jq87j7tz6gNd%2B7V%2BGX4KF5RaPsnXK2kITdQ%3D&reserved=0 >> >> Changes since v2: >> * Add support for entire imx8m family including imx8mq B0. >> * Also mark dram PLLs as CLK_GET_RATE_NO_CACHE (required for imx8mq b0 low OPP) >> * Explicitly update dram pll rate at the end of imx_ddrc_set_freq. >> * Use do_div in imx-ddrc (kbuild robot) >> * Improve explanations around adding CLK_GET_RATE_NO_CACHE to dram clks. >> (Stephen Boyd) >> * Handle ddrc devfreq-events earlier for fewer probe defers. >> * Validate DDRC opp tables versus firmware: supported OPPs depend on board and >> SOC revision. >> * Move DDRC opp tables to board dts because they can vary based on ram type on >> board. >> * Verify DDRC rate is changed in clk tree and otherwise report an error. >> * Change imx_ddrc_freq.rate to be measure in MT/s and round down from HZ in >> imx_ddrc_find_freq instead. >> * Split away from NOC scaling and interconnect support. >> Link to v2: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11104113%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275130306&sdata=3hh0dR1h4Esc6qo79QQKH%2FkUQjrOUgLANR0PcIz1Pss%3D&reserved=0 >> >> Changes since v1: >> * bindings: Stop using "contains" for "compatible" >> * bindings: Set "additionalProperties: false" and document missing stuff. >> * Remove (c) from NXP copyright notice >> * Fix various checkpatch issues >> * Remove unused dram_alt_root clk from imx-ddrc >> Link to v1: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11090649%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275130306&sdata=Hj6NEmoaRHoR%2BQpFoUDdTlybO%2FSTatO2fFo20UGLJf0%3D&reserved=0 >> >> 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. >> 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 echo userspace > governor echo 25000000 > userspace/set_freq cat /sys/kernel/debug/clk/dram_core_clk/clk_rate echo 750000000 > userspace/set_freq cat /sys/kernel/debug/clk/dram_core_clk/clk_rate -- Regards, Leonard
On Wed, Dec 18, 2019 at 8:44 AM Leonard Crestez <leonard.crestez@nxp.com> wrote: > > On 18.12.2019 15:35, Adam Ford wrote: > > On Fri, Nov 22, 2019 at 3:45 PM Leonard Crestez <leonard.crestez@nxp.com> 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. > >> > >> Changes since v6: > >> * Replace ARCH_MXC || COMPILE_TEST with ARCH_MXC && HAVE_ARM_SMCCC > >> * Collect reviews > >> Link to v6: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11244283%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275120308&sdata=ZEZnG6pijjj4MObC99c6%2BvC8BFEfT1KLVxbJCNocoWw%3D&reserved=0 > >> > >> I'd rather not fix COMPILE_TEST with ifdefs for this driver, if anything > >> that should be fixed in smccc header. ARCH_MXC doesn't imply SMCCC, it > >> also covers some very old chips which don't have it. > >> > >> Resending full series because that's the standard method. > >> > >> Changes since v5: > >> * Fix a dram_apb/dram_alt mixup in imx8m_ddrc_set_freq > >> * Make clk_get_parent_by_index static (kbuild robot) > >> * Adjust messages in imx8m_ddrc_set_freq > >> * Use a for loop inside imx8m_ddrc_check_opps instead of while > >> * More elaborate description in dt-bindings file. > >> Link to v5: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11240289%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275130306&sdata=mMqglPQign%2B6NHgmDYoZ74%2FZeThGI6%2FgNkajo1VaHTI%3D&reserved=0 > >> > >> Changes since v4: > >> * Restore empty _get_dev_status: testing shows this is *NOT* optional. If > >> absent then switching to simple_ondemand governor will trigger an Oops. > >> * Keep clk registration on single-line in clk-imx8m* for consistency with rest > >> of the file. > >> * Drop explicit "select PM_OPP" > >> * Check for NULL new_dram_core_parent > >> * Rename "out_dis_" labels to out_disable_* > >> * Use dev_warn on imx8m_ddrc_set_freq error paths after SMC call (where > >> operation is not abandoned). > >> * More elaborate error messages in imx8m_ddrc_target > >> * More elaborate checks when fetching clks in imx8m_ddrc_set_freq > >> * Rename ddrc nodes to memory-controller@* as per devicetree.org "Generic Names > >> Recommendation" > >> * Defer perf support, it requires perf changes to fetch PMU by DT > >> Link to v4: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11235685%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275130306&sdata=LXG4bo0l7FOttZIolJE73CK67AAAW72xfx8yq3Vld7o%3D&reserved=0 > >> > >> Changes since v3: > >> * Rename to imx8m-ddrc. Similar blocks are present on imx7d and imx8qxp/imx8qm > >> but soc integration is different. > >> * Move dt bindings to /memory-controllers/fsl/ > >> * Fix dt validation issues > >> * Fix imx8mm.dtsi ddrc referencing ddrc_opp_table which is only defined in evk > >> * Move opps to child of ddrc device node > >> * Only add imx_ddrc_get_dev_status in perf patch. > >> * Adjust print messages > >> Link to v3: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11221935%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275130306&sdata=%2FFGddgm7jq87j7tz6gNd%2B7V%2BGX4KF5RaPsnXK2kITdQ%3D&reserved=0 > >> > >> Changes since v2: > >> * Add support for entire imx8m family including imx8mq B0. > >> * Also mark dram PLLs as CLK_GET_RATE_NO_CACHE (required for imx8mq b0 low OPP) > >> * Explicitly update dram pll rate at the end of imx_ddrc_set_freq. > >> * Use do_div in imx-ddrc (kbuild robot) > >> * Improve explanations around adding CLK_GET_RATE_NO_CACHE to dram clks. > >> (Stephen Boyd) > >> * Handle ddrc devfreq-events earlier for fewer probe defers. > >> * Validate DDRC opp tables versus firmware: supported OPPs depend on board and > >> SOC revision. > >> * Move DDRC opp tables to board dts because they can vary based on ram type on > >> board. > >> * Verify DDRC rate is changed in clk tree and otherwise report an error. > >> * Change imx_ddrc_freq.rate to be measure in MT/s and round down from HZ in > >> imx_ddrc_find_freq instead. > >> * Split away from NOC scaling and interconnect support. > >> Link to v2: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11104113%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275130306&sdata=3hh0dR1h4Esc6qo79QQKH%2FkUQjrOUgLANR0PcIz1Pss%3D&reserved=0 > >> > >> Changes since v1: > >> * bindings: Stop using "contains" for "compatible" > >> * bindings: Set "additionalProperties: false" and document missing stuff. > >> * Remove (c) from NXP copyright notice > >> * Fix various checkpatch issues > >> * Remove unused dram_alt_root clk from imx-ddrc > >> Link to v1: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11090649%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb7adb366b79f4c564c7908d783bf23ae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637122729275130306&sdata=Hj6NEmoaRHoR%2BQpFoUDdTlybO%2FSTatO2fFo20UGLJf0%3D&reserved=0 > >> > >> 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. > > >> 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? I applied them against 5.5-r1, but if there is a better branch somewhere, I can try that as well. adam > echo userspace > governor > echo 25000000 > userspace/set_freq > cat /sys/kernel/debug/clk/dram_core_clk/clk_rate > echo 750000000 > userspace/set_freq > cat /sys/kernel/debug/clk/dram_core_clk/clk_rate > > -- > Regards, > Leonard
On 18.12.2019 17:05, Adam Ford wrote: > On Wed, Dec 18, 2019 at 8:44 AM Leonard Crestez <leonard.crestez@nxp.com> wrote: >> >> On 18.12.2019 15:35, Adam Ford wrote: >>> On Fri, Nov 22, 2019 at 3:45 PM Leonard Crestez <leonard.crestez@nxp.com> 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://source.codeaurora.org/external/imx/imx-atf/log/?h=imx_4.19.35_1.1.0 Or this: https://github.com/cdleonard/arm-trusted-firmware/commits/imx_2.0.y_busfreq Support on upstream ATF is not yet available -- Regards, Leonard
On Wed, Dec 18, 2019 at 9:16 AM Leonard Crestez <leonard.crestez@nxp.com> wrote: > > On 18.12.2019 17:05, Adam Ford wrote: > > On Wed, Dec 18, 2019 at 8:44 AM Leonard Crestez <leonard.crestez@nxp.com> wrote: > >> > >> On 18.12.2019 15:35, Adam Ford wrote: > >>> On Fri, Nov 22, 2019 at 3:45 PM Leonard Crestez <leonard.crestez@nxp.com> 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://source.codeaurora.org/external/imx/imx-atf/log/?h=imx_4.19.35_1.1.0 > > Or this: > https://github.com/cdleonard/arm-trusted-firmware/commits/imx_2.0.y_busfreq > > 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 I am still learning the imx8mm platform, so please forgive my ignorance. adam > > -- > Regards, > Leonard
On 18.12.2019 17:37, Adam Ford wrote: > On Wed, Dec 18, 2019 at 9:16 AM Leonard Crestez <leonard.crestez@nxp.com> wrote: >> >> On 18.12.2019 17:05, Adam Ford wrote: >>> On Wed, Dec 18, 2019 at 8:44 AM Leonard Crestez <leonard.crestez@nxp.com> wrote: >>>> >>>> On 18.12.2019 15:35, Adam Ford wrote: >>>>> On Fri, Nov 22, 2019 at 3:45 PM Leonard Crestez <leonard.crestez@nxp.com> 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
On Wed, Dec 18, 2019 at 10:22 AM Leonard Crestez <leonard.crestez@nxp.com> wrote: > > On 18.12.2019 17:37, Adam Ford wrote: > > On Wed, Dec 18, 2019 at 9:16 AM Leonard Crestez <leonard.crestez@nxp.com> wrote: > >> > >> On 18.12.2019 17:05, Adam Ford wrote: > >>> On Wed, Dec 18, 2019 at 8:44 AM Leonard Crestez <leonard.crestez@nxp.com> wrote: > >>>> > >>>> On 18.12.2019 15:35, Adam Ford wrote: > >>>>> On Fri, Nov 22, 2019 at 3:45 PM Leonard Crestez <leonard.crestez@nxp.com> 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 :( U-Boot 2020.01-rc4-00244-gf39abbbc53-dirty (Dec 18 2019 - 09:27:40 -0600) > > 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/ I will try your versions and see what happens. > My bootloader prints the following BuildInfo: > - ATF 70fa7bc > > - U-Boot 2019.04-00019-g4d377539a119 > Thanks for your help. adam > -- > Regards, > Leonard
On 10.01.2020 20:34, Adam Ford wrote: > On Wed, Dec 18, 2019 at 10:42 AM Adam Ford <aford173@gmail.com > <mailto:aford173@gmail.com>> wrote: > > > 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 :( > > U-Boot 2020.01-rc4-00244-gf39abbbc53-dirty (Dec 18 2019 - 09:27:40 > -0600) > > > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Fuboot-imx%2Flog%2F%3Fh%3Dimx_v2019.04_4.19.35_1.1.0&data=02%7C01%7Cleonard.crestez%40nxp.com%7C5babd2cb3fec4dc0a21008d795fbbc4a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637142780735473321&sdata=LhleGMcJzjiNsPbVxmPbvgRVMnl%2F2HxUqVYKcgCFiEg%3D&reserved=0> > > https://source.codeaurora.org/external/imx/imx-mkimage/ > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Fimx-mkimage%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7C5babd2cb3fec4dc0a21008d795fbbc4a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637142780735483320&sdata=enJQ9hgVkIG7frJ9v6QBQAgJBL8j3hWB7RAKa8XhPaw%3D&reserved=0> > > I will try your versions and see what happens. > > > My bootloader prints the following BuildInfo: > > - ATF 70fa7bc > > > > - U-Boot 2019.04-00019-g4d377539a119 > > > > Thanks for your help. > > > I wanted to try again after everything was merged into linux-next. > > I am using the U-Boot master (as of 10 Jan 2020), with ATF from > 4.19.35_1.1.0 from Code Aurora. I have tried your ATF, but I don't see > any change in behavior. I have made the DDRC a module, but I still get > the same error message. > > [ 2.204554] imx8m-ddrc-devfreq 3d400000.memory-controller: failed to > init firmware freq info: -19 > > Is there something else I can try? Yes, the NXP branch of uboot from Code Aurora (my commit hash is above). I understand you want to use uboot and atf master, apparently they both need to be patched for this feature to work. It would still be interesting to validate. -- Regards, Leonard
On Mon, Jan 13, 2020 at 5:36 PM Leonard Crestez <leonard.crestez@nxp.com> wrote: > > On 10.01.2020 20:34, Adam Ford wrote: > > On Wed, Dec 18, 2019 at 10:42 AM Adam Ford <aford173@gmail.com > > <mailto:aford173@gmail.com>> wrote: > > > > 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 :( > > > > U-Boot 2020.01-rc4-00244-gf39abbbc53-dirty (Dec 18 2019 - 09:27:40 > > -0600) > > > > > > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Fuboot-imx%2Flog%2F%3Fh%3Dimx_v2019.04_4.19.35_1.1.0&data=02%7C01%7Cleonard.crestez%40nxp.com%7C5babd2cb3fec4dc0a21008d795fbbc4a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637142780735473321&sdata=LhleGMcJzjiNsPbVxmPbvgRVMnl%2F2HxUqVYKcgCFiEg%3D&reserved=0> > > > https://source.codeaurora.org/external/imx/imx-mkimage/ > > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Fimx-mkimage%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7C5babd2cb3fec4dc0a21008d795fbbc4a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637142780735483320&sdata=enJQ9hgVkIG7frJ9v6QBQAgJBL8j3hWB7RAKa8XhPaw%3D&reserved=0> > > > > I will try your versions and see what happens. > > > > > My bootloader prints the following BuildInfo: > > > - ATF 70fa7bc > > > > > > - U-Boot 2019.04-00019-g4d377539a119 > > > > > > > Thanks for your help. > > > > > > I wanted to try again after everything was merged into linux-next. > > > > I am using the U-Boot master (as of 10 Jan 2020), with ATF from > > 4.19.35_1.1.0 from Code Aurora. I have tried your ATF, but I don't see > > any change in behavior. I have made the DDRC a module, but I still get > > the same error message. > > > > [ 2.204554] imx8m-ddrc-devfreq 3d400000.memory-controller: failed to > > init firmware freq info: -19 > > > > Is there something else I can try? > > Yes, the NXP branch of uboot from Code Aurora (my commit hash is above). > > I understand you want to use uboot and atf master, apparently they both > need to be patched for this feature to work. It would still be > interesting to validate. I was able to get the 8MM to work with this new driver using the uboot branch from Code Aurora. Could you point me to what in U-Boot needs to be pulled forward to the mainline? I'd be willing to help if I can. Thanks for your help. adam > > -- > Regards, > Leonard