Hi Peng,

Am Montag, dem 19.07.2021 um 12:53 +0000 schrieb Peng Fan:

Hi Lucas,

quoted

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.

quoted

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

quoted

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