On Mon, 2019-11-04 at 16:01 -0600, Rob Herring wrote:
> On Thu, Oct 31, 2019 at 11:50:27PM +0200, Leonard Crestez wrote:
> > This is used by the imx-ddrc devfreq driver to implement dynamic
> > frequency scaling of DRAM.
> >
> > Add a devfreq-event link to the dram PMU in order to support on-
> > demand scaling of ddrc based on measured dram bandwidth usage.
> >
> > Support for proactive scaling via interconnect will come later. The
> > high-performance bus masters which need that (display, vpu, gpu)
> > are not yet enabled in upstream anyway.
> >
> > Signed-off-by: Leonard Crestez <leonard.crestez@xxxxxxx>
> > ---
> > arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 18 ++++++++++++++
> > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 17 ++++++++++++-
> > .../boot/dts/freescale/imx8mn-ddr4-evk.dts | 18 ++++++++++++++
> > arch/arm64/boot/dts/freescale/imx8mn.dtsi | 16 ++++++++++++-
> > arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 24
> > +++++++++++++++++++
> > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 16 ++++++++++++-
> > 6 files changed, 106 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> > b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> > index 4f5e408d6e6a..be9abd8e4478 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> > @@ -69,16 +69,34 @@
> > simple-audio-card,codec {
> > sound-dai = <&wm8524>;
> > clocks = <&clk IMX8MM_CLK_SAI3_ROOT>;
> > };
> > };
> > +
> > + ddrc_opp_table: ddrc-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>;
> > + };
> > + };
> > };
> >
> > &A53_0 {
> > cpu-supply = <&buck2_reg>;
> > };
> >
> > +&ddrc {
> > + operating-points-v2 = <&ddrc_opp_table>;
> > +};
> > +
> > &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..5404870d80d5 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > @@ -856,11 +856,26 @@
> > #interrupt-cells = <3>;
> > interrupt-controller;
> > interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> > };
> >
> > - ddr-pmu@3d800000 {
> > + ddrc: dram-controller@3d400000 {
> > + compatible = "fsl,imx8mm-ddrc", "fsl,imx8m-
> > ddrc";
> > + reg = <0x3d400000 0x400000>;
>
> Do you really need the OS to map 4MB of register space? Virtual
> space on 64-bit doesn't matter, but it's still wasting 2KB of memory
> just to map all that if only a few pages are needed. Adds up if the
> whole DT is done this way.
This driver doesn't actually map registers, they're only touched from
firmware.
Information is from memory map.
> > + clock-names = "dram_core",
> > + "dram_pll",
> > + "dram_alt",
> > + "dram_apb";
> > + clocks = <&clk IMX8MM_CLK_DRAM_CORE>,
> > + <&clk IMX8MM_DRAM_PLL>,
> > + <&clk IMX8MM_CLK_DRAM_ALT>,
> > + <&clk IMX8MM_CLK_DRAM_APB>;
> > + devfreq-events = <&ddr_pmu>;
> > + operating-points-v2 = <&ddrc_opp_table>;
> > + };
> > +
> > + ddr_pmu: 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..ab2060667671 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
> > @@ -9,16 +9,34 @@
> > #include "imx8mn-evk.dtsi"
> >
> > / {
> > model = "NXP i.MX8MNano DDR4 EVK board";
> > compatible = "fsl,imx8mn-ddr4-evk", "fsl,imx8mn";
> > +
> > + ddrc_opp_table: ddrc-opp-table {
>
> I think it would be better to put this under the ddrc node (and
> named 'opp-table'). Yes, it's kind of silly to have a phandle to a
> child node, but that still works.
That looks much nicer, fixed in v4.
I had to also update yaml to explicitly allow an "opp-table" child.
--
Regards,
Leonard
