linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adam Ford <aford173@gmail.com>
To: Leonard Crestez <leonard.crestez@nxp.com>
Cc: "Stephen Boyd" <sboyd@kernel.org>,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Artur Świgoń" <a.swigon@partner.samsung.com>,
	"Jacky Bai" <ping.bai@nxp.com>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Angus Ainslie" <angus@akkea.ca>,
	"Alexandre Bailon" <abailon@baylibre.com>,
	"Matthias Kaehlcke" <mka@chromium.org>,
	"Abel Vesa" <abel.vesa@nxp.com>,
	"Saravana Kannan" <saravanak@google.com>,
	"Krzysztof Kozlowski" <krzk@kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	"MyungJoo Ham" <myungjoo.ham@samsung.com>,
	"NXP Linux Team" <linux-imx@nxp.com>,
	devicetree <devicetree@vger.kernel.org>,
	linux-pm@vger.kernel.org, "Martin Kepplinger" <martink@posteo.de>,
	"Silvano di Ninno" <silvano.dininno@nxp.com>,
	arm-soc <linux-arm-kernel@lists.infradead.org>,
	"Dong Aisheng" <aisheng.dong@nxp.com>,
	"Anson Huang" <Anson.Huang@nxp.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Sascha Hauer" <kernel@pengutronix.de>,
	"Fabio Estevam" <fabio.estevam@nxp.com>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Georgi Djakov" <georgi.djakov@linaro.org>
Subject: Re: [PATCH v7 0/5] PM / devfreq: Add dynamic scaling for imx8m ddr controller
Date: Wed, 18 Dec 2019 07:35:12 -0600	[thread overview]
Message-ID: <CAHCN7xKNwit8ueUO0OkebfYh=4hsL7_+DRWEbn2dEt0H322W4w@mail.gmail.com> (raw)
In-Reply-To: <cover.1574458460.git.leonard.crestez@nxp.com>

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

  parent reply	other threads:[~2019-12-18 13:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-22 21:44 [PATCH v7 0/5] PM / devfreq: Add dynamic scaling for imx8m ddr controller Leonard Crestez
2019-11-22 21:45 ` [PATCH v7 1/5] clk: imx8m: Set CLK_GET_RATE_NOCACHE on dram clocks Leonard Crestez
2019-12-09  1:15   ` Shawn Guo
2019-11-22 21:45 ` [PATCH v7 2/5] clk: imx: Mark dram pll on 8mm and 8mn with CLK_GET_RATE_NOCACHE Leonard Crestez
2019-12-09  1:16   ` Shawn Guo
2019-11-22 21:45 ` [PATCH v7 3/5] dt-bindings: memory: Add bindings for imx8m ddr controller Leonard Crestez
2019-11-22 21:45 ` [PATCH v7 4/5] PM / devfreq: Add dynamic scaling " Leonard Crestez
2019-11-24 23:59   ` Chanwoo Choi
2019-11-26 19:44     ` Rob Herring
2019-11-26 23:25       ` Chanwoo Choi
     [not found]   ` <CGME20191219230258epcas1p16ec64c3a06eafd9f0a3784d18541ce5c@epcas1p1.samsung.com>
2019-12-19 23:09     ` [v8 PATCH] " Chanwoo Choi
2019-12-19 23:10       ` Chanwoo Choi
2019-11-22 21:45 ` [PATCH v7 5/5] arm64: dts: imx8m: Add ddr controller nodes Leonard Crestez
2019-11-28 14:43   ` Adam Ford
2019-11-29  5:33     ` Leonard Crestez
2019-12-09  1:34   ` Shawn Guo
2019-12-18 13:35 ` Adam Ford [this message]
2019-12-18 14:44   ` [PATCH v7 0/5] PM / devfreq: Add dynamic scaling for imx8m ddr controller Leonard Crestez
2019-12-18 15:05     ` Adam Ford
2019-12-18 15:16       ` Leonard Crestez
2019-12-18 15:37         ` Adam Ford
2019-12-18 16:22           ` Leonard Crestez
2019-12-18 16:42             ` Adam Ford
     [not found]               ` <CAHCN7xKjpN_XEGLj-1jMG5mBbF=su67k+10frheLt+L1XaR0-g@mail.gmail.com>
2020-01-13 23:36                 ` Leonard Crestez
2020-01-15 20:09                   ` Adam Ford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHCN7xKNwit8ueUO0OkebfYh=4hsL7_+DRWEbn2dEt0H322W4w@mail.gmail.com' \
    --to=aford173@gmail.com \
    --cc=Anson.Huang@nxp.com \
    --cc=a.swigon@partner.samsung.com \
    --cc=abailon@baylibre.com \
    --cc=abel.vesa@nxp.com \
    --cc=aisheng.dong@nxp.com \
    --cc=angus@akkea.ca \
    --cc=cw00.choi@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fabio.estevam@nxp.com \
    --cc=georgi.djakov@linaro.org \
    --cc=kernel@pengutronix.de \
    --cc=krzk@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=leonard.crestez@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=martink@posteo.de \
    --cc=mka@chromium.org \
    --cc=mturquette@baylibre.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=ping.bai@nxp.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.com \
    --cc=sboyd@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=silvano.dininno@nxp.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).