| Message ID | cover.1574458460.git.leonard.crestez@nxp.com |
|---|---|
| Headers | show |
| Series | PM / devfreq: Add dynamic scaling for imx8m ddr controller | expand |
On Sun, Nov 24, 2019 at 4:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote: > > Hi Leonard, > > On 11/23/19 6:45 AM, Leonard Crestez wrote: > > Add driver for dynamic scaling the DDR Controller on imx8m chips. Actual > > frequency switching is implemented inside TF-A, this driver wraps the > > SMC calls and synchronizes the clk tree. > > > > The DRAM clocks on imx8m have the following structure (abridged): > > > > +----------+ |\ +------+ > > | dram_pll |-------|M| dram_core | | > > +----------+ |U|---------->| D | > > /--|X| | D | > > dram_alt_root | |/ | R | > > | | C | > > +---------+ | | > > |FIX DIV/4| | | > > +---------+ | | > > composite: | | | > > +----------+ | | | > > | dram_alt |----/ | | > > +----------+ | | > > | dram_apb |-------------------->| | > > +----------+ +------+ > > > > The dram_pll is used for higher rates and dram_alt is used for lower > > rates. The dram_alt and dram_apb clocks are "imx composite" and their > > parent can also be modified. > > > > This 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. > > > > The driver relies on dram_pll dram_alt and dram_apb being marked with > > CLK_GET_RATE_NOCACHE for rate updates. > > > > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> > > Acked-by: Chanwoo Choi <cw00.choi@samsung.com> > > --- > > drivers/devfreq/Kconfig | 9 + > > drivers/devfreq/Makefile | 1 + > > drivers/devfreq/imx8m-ddrc.c | 465 +++++++++++++++++++++++++++++++++++ > > 3 files changed, 475 insertions(+) > > create mode 100644 drivers/devfreq/imx8m-ddrc.c > > > > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > > index 59027d7ddf2a..5eac479dd05f 100644 > > --- a/drivers/devfreq/Kconfig > > +++ b/drivers/devfreq/Kconfig > > @@ -89,10 +89,19 @@ config ARM_EXYNOS_BUS_DEVFREQ > > Each memory bus group could contain many memoby bus block. It reads > > PPMU counters of memory controllers by using DEVFREQ-event device > > and adjusts the operating frequencies and voltages with OPP support. > > This does not yet operate with optimal voltages. > > > > +config ARM_IMX8M_DDRC_DEVFREQ > > + tristate "i.MX8M DDRC DEVFREQ Driver" > > + depends on ARCH_MXC && HAVE_ARM_SMCCC > > I'll edit it as following and applied it. You corrupted the URLs in the binding patch when applying the series: Traceback (most recent call last): File "/usr/local/lib/python3.6/dist-packages/jsonschema/validators.py", line 774, in resolve_from_url document = self.store[url] File "/usr/local/lib/python3.6/dist-packages/jsonschema/_utils.py", line 22, in __getitem__ return self.store[self.normalize(uri)] KeyError: 'https://protect2.fireeye.com/url?k=b51ff83f-e8cff0d7-b51e7370-000babff32e3-c25c03b8af1b12ee&u=http://devicetree.org/meta-schemas/core.yaml' Rob
On 11/27/19 4:44 AM, Rob Herring wrote: > On Sun, Nov 24, 2019 at 4:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote: >> >> Hi Leonard, >> >> On 11/23/19 6:45 AM, Leonard Crestez wrote: >>> Add driver for dynamic scaling the DDR Controller on imx8m chips. Actual >>> frequency switching is implemented inside TF-A, this driver wraps the >>> SMC calls and synchronizes the clk tree. >>> >>> The DRAM clocks on imx8m have the following structure (abridged): >>> >>> +----------+ |\ +------+ >>> | dram_pll |-------|M| dram_core | | >>> +----------+ |U|---------->| D | >>> /--|X| | D | >>> dram_alt_root | |/ | R | >>> | | C | >>> +---------+ | | >>> |FIX DIV/4| | | >>> +---------+ | | >>> composite: | | | >>> +----------+ | | | >>> | dram_alt |----/ | | >>> +----------+ | | >>> | dram_apb |-------------------->| | >>> +----------+ +------+ >>> >>> The dram_pll is used for higher rates and dram_alt is used for lower >>> rates. The dram_alt and dram_apb clocks are "imx composite" and their >>> parent can also be modified. >>> >>> This 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. >>> >>> The driver relies on dram_pll dram_alt and dram_apb being marked with >>> CLK_GET_RATE_NOCACHE for rate updates. >>> >>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> >>> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> >>> --- >>> drivers/devfreq/Kconfig | 9 + >>> drivers/devfreq/Makefile | 1 + >>> drivers/devfreq/imx8m-ddrc.c | 465 +++++++++++++++++++++++++++++++++++ >>> 3 files changed, 475 insertions(+) >>> create mode 100644 drivers/devfreq/imx8m-ddrc.c >>> >>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig >>> index 59027d7ddf2a..5eac479dd05f 100644 >>> --- a/drivers/devfreq/Kconfig >>> +++ b/drivers/devfreq/Kconfig >>> @@ -89,10 +89,19 @@ config ARM_EXYNOS_BUS_DEVFREQ >>> Each memory bus group could contain many memoby bus block. It reads >>> PPMU counters of memory controllers by using DEVFREQ-event device >>> and adjusts the operating frequencies and voltages with OPP support. >>> This does not yet operate with optimal voltages. >>> >>> +config ARM_IMX8M_DDRC_DEVFREQ >>> + tristate "i.MX8M DDRC DEVFREQ Driver" >>> + depends on ARCH_MXC && HAVE_ARM_SMCCC >> >> I'll edit it as following and applied it. > > You corrupted the URLs in the binding patch when applying the series: > > Traceback (most recent call last): > File "/usr/local/lib/python3.6/dist-packages/jsonschema/validators.py", > line 774, in resolve_from_url > document = self.store[url] > File "/usr/local/lib/python3.6/dist-packages/jsonschema/_utils.py", > line 22, in __getitem__ > return self.store[self.normalize(uri)] > KeyError: 'https://protect2.fireeye.com/url?k=b51ff83f-e8cff0d7-b51e7370-000babff32e3-c25c03b8af1b12ee&u=http://devicetree.org/meta-schemas/core.yaml' > I'm sorry the url was changed when I applied them because of the internal security system.. I fixed and updated it to devfreq next branch. Thanks, Chanwoo Choi
On Fri, Nov 22, 2019 at 3:46 PM Leonard Crestez <leonard.crestez@nxp.com> wrote: > > This is used by the imx-ddrc devfreq driver to implement dynamic > frequency scaling of DRAM. > > Support for proactive scaling via interconnect will come later. The > high-performance bus masters which need that (display, vpu, gpu) are > mostly not yet enabled in upstream anyway. > > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> > --- > 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 ++++++++ > 6 files changed, 90 insertions(+) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts > index 28ab17a277bb..ecf0d385c164 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts > @@ -75,10 +75,28 @@ > > &A53_0 { > cpu-supply = <&buck2_reg>; > }; > > +&ddrc { > + operating-points-v2 = <&ddrc_opp_table>; > + > + ddrc_opp_table: opp-table { > + compatible = "operating-points-v2"; > + > + opp-25M { > + opp-hz = /bits/ 64 <25000000>; > + }; > + opp-100M { > + opp-hz = /bits/ 64 <100000000>; > + }; > + opp-750M { > + opp-hz = /bits/ 64 <750000000>; > + }; > + }; > +}; The SoC's device tree has the opp for the SoC. Since the SoC also has the DDR controller, why not put the opp for the DDR into the SoC's device tree set for its maximum rates. If the individual boards need to change them, they can do it on a case-by-case basis. As more and more people add devices based on imx8m q/m/n, I can imaging a lot of these entries will be duplicated if they base their design on the reference evk for their respective SoC. > + > &fec1 { > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_fec1>; > phy-mode = "rgmii-id"; > phy-handle = <ðphy0>; > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi > index 6edbdfe2d0d7..3d4802375715 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi > @@ -856,10 +856,20 @@ > #interrupt-cells = <3>; > interrupt-controller; > interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; > }; > > + ddrc: memory-controller@3d400000 { > + compatible = "fsl,imx8mm-ddrc", "fsl,imx8m-ddrc"; > + reg = <0x3d400000 0x400000>; > + clock-names = "core", "pll", "alt", "apb"; > + clocks = <&clk IMX8MM_CLK_DRAM_CORE>, > + <&clk IMX8MM_DRAM_PLL>, > + <&clk IMX8MM_CLK_DRAM_ALT>, > + <&clk IMX8MM_CLK_DRAM_APB>; > + }; > + > ddr-pmu@3d800000 { > compatible = "fsl,imx8mm-ddr-pmu", "fsl,imx8m-ddr-pmu"; > reg = <0x3d800000 0x400000>; > interrupt-parent = <&gic>; > interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; > diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts > index 071949412caf..b051c927c11e 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts > @@ -15,10 +15,28 @@ > > &A53_0 { > cpu-supply = <&buck2_reg>; > }; > > +&ddrc { > + operating-points-v2 = <&ddrc_opp_table>; > + > + ddrc_opp_table: opp-table { > + compatible = "operating-points-v2"; > + > + opp-25M { > + opp-hz = /bits/ 64 <25000000>; > + }; > + opp-100M { > + opp-hz = /bits/ 64 <100000000>; > + }; > + opp-600M { > + opp-hz = /bits/ 64 <600000000>; > + }; > + }; > +}; > + > &i2c1 { > pmic@4b { > compatible = "rohm,bd71847"; > reg = <0x4b>; > pinctrl-0 = <&pinctrl_pmic>; > diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi > index e91625063f8e..3a79fdddc72b 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi > @@ -757,10 +757,20 @@ > #interrupt-cells = <3>; > interrupt-controller; > interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; > }; > > + ddrc: memory-controller@3d400000 { > + compatible = "fsl,imx8mn-ddrc", "fsl,imx8m-ddrc"; > + reg = <0x3d400000 0x400000>; > + clock-names = "core", "pll", "alt", "apb"; > + clocks = <&clk IMX8MN_CLK_DRAM_CORE>, > + <&clk IMX8MN_DRAM_PLL>, > + <&clk IMX8MN_CLK_DRAM_ALT>, > + <&clk IMX8MN_CLK_DRAM_APB>; > + }; > + > ddr-pmu@3d800000 { > compatible = "fsl,imx8mn-ddr-pmu", "fsl,imx8m-ddr-pmu"; > reg = <0x3d800000 0x400000>; > interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; > }; > diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts > index c36685916683..ee6dc5f07622 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts > @@ -103,10 +103,34 @@ > > &A53_3 { > cpu-supply = <&buck2_reg>; > }; > > +&ddrc { > + operating-points-v2 = <&ddrc_opp_table>; > + > + ddrc_opp_table: opp-table { > + compatible = "operating-points-v2"; > + > + opp-25M { > + opp-hz = /bits/ 64 <25000000>; > + }; > + opp-100M { > + opp-hz = /bits/ 64 <100000000>; > + }; > + /* > + * On imx8mq B0 PLL can't be bypassed so low bus is 166M > + */ > + opp-166M { > + opp-hz = /bits/ 64 <166935483>; > + }; > + opp-800M { > + opp-hz = /bits/ 64 <800000000>; > + }; > + }; > +}; > + > &fec1 { > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_fec1>; > phy-mode = "rgmii-id"; > phy-handle = <ðphy0>; > diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi > index 7f9319452b58..d1fcf9887f8b 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi > @@ -1111,10 +1111,20 @@ > interrupt-controller; > interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; > interrupt-parent = <&gic>; > }; > > + ddrc: memory-controller@3d400000 { > + compatible = "fsl,imx8mq-ddrc", "fsl,imx8m-ddrc"; > + reg = <0x3d400000 0x400000>; > + clock-names = "core", "pll", "alt", "apb"; > + clocks = <&clk IMX8MQ_CLK_DRAM_CORE>, > + <&clk IMX8MQ_DRAM_PLL_OUT>, > + <&clk IMX8MQ_CLK_DRAM_ALT>, > + <&clk IMX8MQ_CLK_DRAM_APB>; > + }; > + > ddr-pmu@3d800000 { > compatible = "fsl,imx8mq-ddr-pmu", "fsl,imx8m-ddr-pmu"; > reg = <0x3d800000 0x400000>; > interrupt-parent = <&gic>; > interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; > -- > 2.17.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 2019-11-28 4:43 PM, Adam Ford wrote: > On Fri, Nov 22, 2019 at 3:46 PM Leonard Crestez <leonard.crestez@nxp.com> wrote: >> >> This is used by the imx-ddrc devfreq driver to implement dynamic >> frequency scaling of DRAM. >> >> Support for proactive scaling via interconnect will come later. The >> high-performance bus masters which need that (display, vpu, gpu) are >> mostly not yet enabled in upstream anyway. >> >> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> >> --- >> 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 ++++++++ >> 6 files changed, 90 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts >> index 28ab17a277bb..ecf0d385c164 100644 >> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts >> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts >> @@ -75,10 +75,28 @@ >> >> &A53_0 { >> cpu-supply = <&buck2_reg>; >> }; >> >> +&ddrc { >> + operating-points-v2 = <&ddrc_opp_table>; >> + >> + ddrc_opp_table: opp-table { >> + compatible = "operating-points-v2"; >> + >> + opp-25M { >> + opp-hz = /bits/ 64 <25000000>; >> + }; >> + opp-100M { >> + opp-hz = /bits/ 64 <100000000>; >> + }; >> + opp-750M { >> + opp-hz = /bits/ 64 <750000000>; >> + }; >> + }; >> +}; > > The SoC's device tree has the opp for the SoC. Since the SoC also has > the DDR controller, why not put the opp for the DDR into the SoC's > device tree set for its maximum rates. If the individual boards need > to change them, they can do it on a case-by-case basis. > > As more and more people add devices based on imx8m q/m/n, I can > imaging a lot of these entries will be duplicated if they base their > design on the reference evk for their respective SoC. The OPPs can vary from board to board for the same SoC. For example ddr4 and lpddr4 variants of the NXP evk boards have different setpoints. If a default set was included in soc dtsi then some boards would end up having to use /delete-node/ and I wanted to avoid that. Last I check that feature wasn't even officially documented for dtc? Perhaps this could be revisited if it ends up being duplicated on many boards. -- Regards, Leonard
On Fri, Nov 22, 2019 at 11:45:00PM +0200, Leonard Crestez wrote: > These clocks are only modified as part of DRAM frequency switches during > which DRAM itself is briefly inaccessible. The switch is performed with > a SMC call to by TF-A which runs from a SRAM area; upon returning to > linux several clocks bits are modified and we need to update them. > > For rate bits an easy solution is to just mark with > CLK_GET_RATE_NOCACHE so that new rates are always read back from > registers. > > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> > Reviewed-by: Abel Vesa <abel.vesa@nxp.com> Applied, thanks.
On Fri, Nov 22, 2019 at 11:45:01PM +0200, Leonard Crestez wrote: > DRAM frequency switches are executed in firmware and can change the > configuration of the DRAM PLL outside linux. Mark these CLKs with > CLK_GET_RATE_NOCACHE so we always read back the PLL config registers and > recalculate rates. > > In current DRAM frequency tables on 8mm/8mn only the maximum frequency > uses the PLL so it's always configured in the same way. However reading > back the PLL configuration is the correct behavior and allows additional > setpoints in the future. > > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> > Reviewed-by: Abel Vesa <abel.vesa@nxp.com> Applied, thanks.
On Fri, Nov 22, 2019 at 11:45:04PM +0200, Leonard Crestez wrote: > This is used by the imx-ddrc devfreq driver to implement dynamic > frequency scaling of DRAM. > > Support for proactive scaling via interconnect will come later. The > high-performance bus masters which need that (display, vpu, gpu) are > mostly not yet enabled in upstream anyway. > > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> > --- > 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 ++++++++ > 6 files changed, 90 insertions(+) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts > index 28ab17a277bb..ecf0d385c164 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts > @@ -75,10 +75,28 @@ > > &A53_0 { > cpu-supply = <&buck2_reg>; > }; > > +&ddrc { > + operating-points-v2 = <&ddrc_opp_table>; > + > + ddrc_opp_table: opp-table { > + compatible = "operating-points-v2"; > + > + opp-25M { > + opp-hz = /bits/ 64 <25000000>; > + }; As an idiomatic practice, we have newline between nodes. I fixed it up and applied the patch. Shawn > + opp-100M { > + opp-hz = /bits/ 64 <100000000>; > + }; > + opp-750M { > + opp-hz = /bits/ 64 <750000000>; > + }; > + }; > +}; > + > &fec1 { > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_fec1>; > phy-mode = "rgmii-id"; > phy-handle = <ðphy0>; > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi > index 6edbdfe2d0d7..3d4802375715 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi > @@ -856,10 +856,20 @@ > #interrupt-cells = <3>; > interrupt-controller; > interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; > }; > > + ddrc: memory-controller@3d400000 { > + compatible = "fsl,imx8mm-ddrc", "fsl,imx8m-ddrc"; > + reg = <0x3d400000 0x400000>; > + clock-names = "core", "pll", "alt", "apb"; > + clocks = <&clk IMX8MM_CLK_DRAM_CORE>, > + <&clk IMX8MM_DRAM_PLL>, > + <&clk IMX8MM_CLK_DRAM_ALT>, > + <&clk IMX8MM_CLK_DRAM_APB>; > + }; > + > ddr-pmu@3d800000 { > compatible = "fsl,imx8mm-ddr-pmu", "fsl,imx8m-ddr-pmu"; > reg = <0x3d800000 0x400000>; > interrupt-parent = <&gic>; > interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; > diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts > index 071949412caf..b051c927c11e 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts > @@ -15,10 +15,28 @@ > > &A53_0 { > cpu-supply = <&buck2_reg>; > }; > > +&ddrc { > + operating-points-v2 = <&ddrc_opp_table>; > + > + ddrc_opp_table: opp-table { > + compatible = "operating-points-v2"; > + > + opp-25M { > + opp-hz = /bits/ 64 <25000000>; > + }; > + opp-100M { > + opp-hz = /bits/ 64 <100000000>; > + }; > + opp-600M { > + opp-hz = /bits/ 64 <600000000>; > + }; > + }; > +}; > + > &i2c1 { > pmic@4b { > compatible = "rohm,bd71847"; > reg = <0x4b>; > pinctrl-0 = <&pinctrl_pmic>; > diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi > index e91625063f8e..3a79fdddc72b 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi > @@ -757,10 +757,20 @@ > #interrupt-cells = <3>; > interrupt-controller; > interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; > }; > > + ddrc: memory-controller@3d400000 { > + compatible = "fsl,imx8mn-ddrc", "fsl,imx8m-ddrc"; > + reg = <0x3d400000 0x400000>; > + clock-names = "core", "pll", "alt", "apb"; > + clocks = <&clk IMX8MN_CLK_DRAM_CORE>, > + <&clk IMX8MN_DRAM_PLL>, > + <&clk IMX8MN_CLK_DRAM_ALT>, > + <&clk IMX8MN_CLK_DRAM_APB>; > + }; > + > ddr-pmu@3d800000 { > compatible = "fsl,imx8mn-ddr-pmu", "fsl,imx8m-ddr-pmu"; > reg = <0x3d800000 0x400000>; > interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; > }; > diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts > index c36685916683..ee6dc5f07622 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts > @@ -103,10 +103,34 @@ > > &A53_3 { > cpu-supply = <&buck2_reg>; > }; > > +&ddrc { > + operating-points-v2 = <&ddrc_opp_table>; > + > + ddrc_opp_table: opp-table { > + compatible = "operating-points-v2"; > + > + opp-25M { > + opp-hz = /bits/ 64 <25000000>; > + }; > + opp-100M { > + opp-hz = /bits/ 64 <100000000>; > + }; > + /* > + * On imx8mq B0 PLL can't be bypassed so low bus is 166M > + */ > + opp-166M { > + opp-hz = /bits/ 64 <166935483>; > + }; > + opp-800M { > + opp-hz = /bits/ 64 <800000000>; > + }; > + }; > +}; > + > &fec1 { > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_fec1>; > phy-mode = "rgmii-id"; > phy-handle = <ðphy0>; > diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi > index 7f9319452b58..d1fcf9887f8b 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi > @@ -1111,10 +1111,20 @@ > interrupt-controller; > interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; > interrupt-parent = <&gic>; > }; > > + ddrc: memory-controller@3d400000 { > + compatible = "fsl,imx8mq-ddrc", "fsl,imx8m-ddrc"; > + reg = <0x3d400000 0x400000>; > + clock-names = "core", "pll", "alt", "apb"; > + clocks = <&clk IMX8MQ_CLK_DRAM_CORE>, > + <&clk IMX8MQ_DRAM_PLL_OUT>, > + <&clk IMX8MQ_CLK_DRAM_ALT>, > + <&clk IMX8MQ_CLK_DRAM_APB>; > + }; > + > ddr-pmu@3d800000 { > compatible = "fsl,imx8mq-ddr-pmu", "fsl,imx8m-ddr-pmu"; > reg = <0x3d800000 0x400000>; > interrupt-parent = <&gic>; > interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; > -- > 2.17.1 >
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