Hi Lucas,

Subject: [PATCH 00/17] i.MX8MM GPC improvements and BLK_CTRL driver

Thanks for your work on this. I'll give a look and test tomorrow.

Hi all,

over the last few days I've taken on the job to give the blk-ctrl driver initially
worked on by Peng Fan another spin. What I've come up with now looks quite
a bit different, as the power sequencing shared between the blk-ctrls and the
GPC is not really feasible to model with a strict hierarchy of power domains.
In my design the blk-ctrl driver is the instance driving the sequence for those
power domains where a blk-ctrl is part of the picture.

For those that aren't familiar with the power domain architecture on the
i.MX8M*, here's a short overview, to hopefully make it easier to review this
series. The i.MX8M* reuses the GPCv2 (General Power Controller)IP block,
already known from the i.MX7. On the i.MX7 all power domains were
independent and all the reset and bus isolation sequencing was handled in
hardware by the GPC. Software only needed to request power up/down for
the domain and things mostly happened behind the scenes. On i.MX8M*
things got more complex, as there are now nested power domains and
coupling of the data busses is handled by AMBA domain bridges (ADB), which
aren't sequenced by the GPC hardware, but have handshake requests/acks
wired up to a register in the GPC that needs to be handled by software. Due
to hardware issues some of the reset sequencing also needs to be handled by
software, as the GPC isn't always able to properly trigger the SRC reset for the
peripherals inside the power domains.

Generally with all those nested domains there exists a outer *MIX (e.g.
VPUMIX, DISPMIX) domain that contains the ADB and the BLK_CTRL.
Handshake with the ADB can only happen after the *MIX domain is powered
up and some domain specific initialization in the BLK_CTRL is done. The ADB
is connected to a bus clock from CCM that needs to be enabled for the ADB to
work. Also there might be additional resets and clock gates for the ADB in the
BLK_CTRL MMIO region, which is also only accessible after the *MIX domain
is powered up.
Some peripherals are directly located in the *MIX domain, but others are
placed in inner domains located in the *MIX domain. In order to power up
those nested domains the *MIX domain must already be powered up and the
ADB handshake must be finished. Reset is handled via the BLK_CTRL, instead
of the SRC, which contains resets and clock gates for the peripherals.
The general flow for those inner domains is:
1. Assert reset and ungate clocks in BLK_CTRL to allow reset to propagate 2.
Request power up at the GPC 3. Deassert reset

Failing to meet the ADB handshake and/or reset sequencing requirements will
generally lead to system hangs (not necessarily at the point where the
sequence is violated). The blk-ctrl driver as implemented hides this behind
virtual power domains. Peripherals don't need to care whether they are
located directly inside the *MIX domain or in a nested domain, they all just
use the power domains exposed by the BLK_CTRL driver, which handles the
sequencing requiments internally.

Currently this series implements both the VPU and DISP blk-ctrls for the
i.MX8MM SoC, but I'm quite confident that the design is sound and can be
trivially extended for the other i.MX8M* SoCs. On my personal TODO list is
the conversion of the i.MX8MQ VPU blk-ctrl to the new model, which should
finally allow us to drive the G1 and G2 VPUs independently. After that I'm
going to look at the i.MX8MP, 

Would you take 8MP before 8MQ? 8MP is more popular.
If you not mind, I could post my local 8MP GPC part based on your patchset.
Anyway my local 8MP blk-ctl will be dropped.

as this is a current focus of my work and has

even more blk-ctrl instances. But before moving on to those, I would like to
gather some feedback and testing on this series.

I will also provide a branch with those patches and the WIP VPU and display
patches I used to test this. But that will have to wait for next week, as it's
getting pretty late here.

Do you have a public branch now?

Thanks,
Peng.

Regards,
Lucas

Frieder Schrempf (1):
  arm64: dts: imx8mm: Add GPU nodes for 2D and 3D core

Lucas Stach (14):
  Revert "soc: imx: gpcv2: move reset assert after requesting domain
    power up"
  soc: imx: gpcv2: add lockdep annotation
  soc: imx: gpcv2: add domain option to keep domain clocks enabled
  soc: imx: gpcv2: keep i.MX8M* bus clocks enabled
  dt-bindings: soc: add binding for i.MX8MM VPU blk-ctrl
  dt-bindings: power: imx8mm: add defines for VPU blk-ctrl domains
  soc: imx: add i.MX8M blk-ctrl driver
  dt-bindings: soc: add binding for i.MX8MM DISP blk-ctrl
  dt-bindings: power: imx8mm: add defines for DISP blk-ctrl domains
  soc: imx: imx8m-blk-ctrl: add DISP blk-ctrl
  arm64: dts: imx8mm: add GPC node
  arm64: dts: imx8mm: put USB controllers into power-domains
  arm64: dts: imx8mm: add VPU blk-ctrl
  arm64: dts: imx8mm: add DISP blk-ctrl

Marek Vasut (2):
  soc: imx: gpcv2: Turn domain->pgc into bitfield
  soc: imx: gpcv2: Set both GPC_PGC_nCTRL(GPU_2D|GPU_3D) for MX8MM
GPU
    domain

 .../soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml     |  97 ++++
 .../soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml      |  79 +++
 arch/arm64/boot/dts/freescale/imx8mm.dtsi     | 180 +++++++
 drivers/soc/imx/Makefile                      |   1 +
 drivers/soc/imx/gpcv2.c                       |  99 ++--
 drivers/soc/imx/imx8m-blk-ctrl.c              | 464
++++++++++++++++++
 include/dt-bindings/power/imx8mm-power.h      |   9 +
 7 files changed, 888 insertions(+), 41 deletions(-)  create mode 100644
Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml
 create mode 100644
Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml
 create mode 100644 drivers/soc/imx/imx8m-blk-ctrl.c

--
2.30.2

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel