mbox series

[v4,0/6] PM / devfreq: Add dynamic scaling for imx8m ddr controller

Message ID cover.1573252696.git.leonard.crestez@nxp.com (mailing list archive)
Headers show
Series PM / devfreq: Add dynamic scaling for imx8m ddr controller | expand

Message

Leonard Crestez Nov. 8, 2019, 10:39 p.m. UTC 
This adds support for dynamic scaling of the DDR Controller (ddrc) present in
imx8m series. 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 atomically useful 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.

Angus/Martin: You previously attempted to test on purism boards, this updated
version should work without hacks and has no dependencies.

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/

Leonard Crestez (6):
  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
  PM / devfreq: imx8m-ddrc: Measure bandwidth with perf
  arm64: dts: imx8m: Add ddr controller nodes

 .../memory-controllers/fsl/imx8m-ddrc.yaml    |  61 ++
 arch/arm64/boot/dts/freescale/imx8mm-evk.dts  |  18 +
 arch/arm64/boot/dts/freescale/imx8mm.dtsi     |  13 +-
 .../boot/dts/freescale/imx8mn-ddr4-evk.dts    |  18 +
 arch/arm64/boot/dts/freescale/imx8mn.dtsi     |  13 +-
 arch/arm64/boot/dts/freescale/imx8mq-evk.dts  |  24 +
 arch/arm64/boot/dts/freescale/imx8mq.dtsi     |  13 +-
 drivers/clk/imx/clk-imx8mm.c                  |  13 +-
 drivers/clk/imx/clk-imx8mn.c                  |  14 +-
 drivers/clk/imx/clk-imx8mq.c                  |  15 +-
 drivers/clk/imx/clk-pll14xx.c                 |   7 +
 drivers/clk/imx/clk.h                         |   1 +
 drivers/devfreq/Kconfig                       |  10 +
 drivers/devfreq/Makefile                      |   1 +
 drivers/devfreq/imx8m-ddrc.c                  | 569 ++++++++++++++++++
 15 files changed, 777 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml
 create mode 100644 drivers/devfreq/imx8m-ddrc.c

Comments

Martin Kepplinger June 22, 2020, 1:58 p.m. UTC | #1 
hi Leondard,

before using this patchset I'd like to ask: Do you have plans to create
an update and push this forward? It is useful.

thanks a lot,

                               martin
Leonard Crestez June 24, 2020, 6:08 a.m. UTC | #2 
On 6/22/20 4:58 PM, Martin Kepplinger wrote:
> hi Leondard,
> 
> before using this patchset I'd like to ask: Do you have plans to create
> an update and push this forward? It is useful.

Hello.

I am no longer with NXP and don't have access to imx hardware right now.

However the series that you replied to is very old and was accepted many 
months ago. You shouldn't have to apply out-of-tree kernel patches.

--
Regards,
Leonard
Martin Kepplinger June 25, 2020, 6:57 a.m. UTC | #3 
hi Leonard,

On 24.06.20 08:08, Leonard Crestez wrote:
> On 6/22/20 4:58 PM, Martin Kepplinger wrote:
>> hi Leondard,
>>
>> before using this patchset I'd like to ask: Do you have plans to create
>> an update and push this forward? It is useful.
> 
> Hello.
> 
> I am no longer with NXP and don't have access to imx hardware right now.

I guess it'll get even harder to get the ATF part for devfreq
implemented now :) Thanks for the update and all the best for your new
stuff.

> 
> However the series that you replied to is very old and was accepted many
> months ago. You shouldn't have to apply out-of-tree kernel patches.
> 

that particular series doesn't seem to be in mainline, see
https://elixir.bootlin.com/linux/latest/source/drivers/devfreq/imx8m-ddrc.c#L283
or do I miss something?

do you know who at nxp would be likely actively working on devfreq?

thanks,
                           martin
Abel Vesa June 25, 2020, 2:47 p.m. UTC | #4 
On 20-06-25 08:57:52, Martin Kepplinger wrote:
> hi Leonard,
> 
> On 24.06.20 08:08, Leonard Crestez wrote:
> > On 6/22/20 4:58 PM, Martin Kepplinger wrote:
> >> hi Leondard,
> >>
> >> before using this patchset I'd like to ask: Do you have plans to create
> >> an update and push this forward? It is useful.
> > 
> > Hello.
> > 
> > I am no longer with NXP and don't have access to imx hardware right now.
> 
> I guess it'll get even harder to get the ATF part for devfreq
> implemented now :) Thanks for the update and all the best for your new
> stuff.
> 
> > 
> > However the series that you replied to is very old and was accepted many
> > months ago. You shouldn't have to apply out-of-tree kernel patches.
> > 
> 
> that particular series doesn't seem to be in mainline, see
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Fdevfreq%2Fimx8m-ddrc.c%23L283&data=02%7C01%7Cabel.vesa%40nxp.com%7Cb00f437e756d4850238f08d818d51b59%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637286650857331523&sdata=S7%2BN3%2BiTFkUW5YnmVzl36wEBlr%2BkTatGoDDrvY9XfTk%3D&reserved=0
> or do I miss something?
> 
> do you know who at nxp would be likely actively working on devfreq?

Hi Martin,

I will be working on this in the following weeks.

> 
> thanks,
>                            martin
Martin Kepplinger June 29, 2020, 6:32 a.m. UTC | #5 
On 25.06.20 16:47, Abel Vesa wrote:
> On 20-06-25 08:57:52, Martin Kepplinger wrote:
>> hi Leonard,
>>
>> On 24.06.20 08:08, Leonard Crestez wrote:
>>> On 6/22/20 4:58 PM, Martin Kepplinger wrote:
>>>> hi Leondard,
>>>>
>>>> before using this patchset I'd like to ask: Do you have plans to create
>>>> an update and push this forward? It is useful.
>>>
>>> Hello.
>>>
>>> I am no longer with NXP and don't have access to imx hardware right now.
>>
>> I guess it'll get even harder to get the ATF part for devfreq
>> implemented now :) Thanks for the update and all the best for your new
>> stuff.
>>
>>>
>>> However the series that you replied to is very old and was accepted many
>>> months ago. You shouldn't have to apply out-of-tree kernel patches.
>>>
>>
>> that particular series doesn't seem to be in mainline, see
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Fdevfreq%2Fimx8m-ddrc.c%23L283&data=02%7C01%7Cabel.vesa%40nxp.com%7Cb00f437e756d4850238f08d818d51b59%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637286650857331523&sdata=S7%2BN3%2BiTFkUW5YnmVzl36wEBlr%2BkTatGoDDrvY9XfTk%3D&reserved=0
>> or do I miss something?
>>
>> do you know who at nxp would be likely actively working on devfreq?
> 
> Hi Martin,
> 
> I will be working on this in the following weeks.
> 

hi Abel,

that's good to hear. I'm basically always happy to test changes to
devfreq (the ondemand governor or an atf implementation).

thanks,
                        martin