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

[Lucas Stach <l.stach@pengutronix.de>]

Hi Peng,

Am Montag, dem 19.07.2021 um 12:53 +0000 schrieb 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.

The 8MQ VPU conversion should be pretty trivial, now that I've worked
out the overall structure of the blk-ctrl driver. I'm also aware of
multiple people in the community waiting for this part to land, as it's
blocking Hantro G2 support on i.MX8MQ upstream, so I'm going to stick
to this order. While there is a lot interest in 8MP, there aren't that
many people that even have the hardware yet, while the 8MQ is in pretty
widespread use.

I also have some 8MP GPC work bitrotting in a branch, which I planned
to revive. If you already have something ready, I'm happy to skip that
and review your patches instead.

> 
> 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?

This series (with fixes for the reported issues already squashed in)
can be found here:
https://git.pengutronix.de/cgit/lst/linux/log/?h=imx8m-power-domains

Additional patches to enable MIPI DSI display and one VPU can be found
here:
https://git.pengutronix.de/cgit/lst/linux/log/?h=imx8m-power-domains-testing

Please note that the display patches do not reflect the current status
of the upstream discussions, it's just my known-good stack at the
moment. I'm providing those patches just for contextual reference and
to allow people to see my test setup. I've worked on a custom i.MX8MM
board, so the bits to hook this up for the EVK board are missing. I am
not seeking feedback on any of the display/vpu patches at the moment.

Regards,
Lucas