| Message ID | 20210716232916.3572966-1-l.stach@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | i.MX8MM GPC improvements and BLK_CTRL driver | expand |
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
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
Am Montag, dem 19.07.2021 um 18:56 +0200 schrieb Lucas Stach: > Hi Peng, > > > [...] > > > 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. > And just a heads-up in case anyone is testing this series right now: I've found some issues with suspend-resume and I'm working on them right now. I'll send a v2 shortly and will also update those public branches. Regards, Lucas
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, 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. 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