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

[Peng Fan]

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