On Sa, 2020-10-10 at 02:16 +0000, Jacky Bai wrote: > > -----Original Message----- > > From: Lucas Stach [mailto:l.stach@xxxxxxxxxxxxxx] > > Sent: Friday, October 9, 2020 7:12 PM > > To: Jacky Bai <ping.bai@xxxxxxx>; Shawn Guo <shawnguo@xxxxxxxxxx>; Rob > > Herring <robh+dt@xxxxxxxxxx> > > Cc: dl-linux-imx <linux-imx@xxxxxxx>; Fabio Estevam > > <festevam@xxxxxxxxx>; Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>; > > Marek Vasut <marex@xxxxxxx>; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; > > devicetree@xxxxxxxxxxxxxxx; kernel@xxxxxxxxxxxxxx; > > patchwork-lst@xxxxxxxxxxxxxx > > Subject: Re: [PATCH 00/11] i.MX8MM power domain support > > > > Hi Jacky, > > > > On Fr, 2020-10-09 at 03:00 +0000, Jacky Bai wrote: > > > > -----Original Message----- > > > > From: Lucas Stach [mailto:l.stach@xxxxxxxxxxxxxx] > > > > Sent: Wednesday, September 30, 2020 11:50 PM > > > > To: Shawn Guo <shawnguo@xxxxxxxxxx>; Rob Herring > > > > <robh+dt@xxxxxxxxxx> > > > > Cc: dl-linux-imx <linux-imx@xxxxxxx>; Fabio Estevam > > > > <festevam@xxxxxxxxx>; Frieder Schrempf > > > > <frieder.schrempf@xxxxxxxxxx>; Marek Vasut <marex@xxxxxxx>; > > > > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; > > > > devicetree@xxxxxxxxxxxxxxx; kernel@xxxxxxxxxxxxxx; > > > > patchwork-lst@xxxxxxxxxxxxxx > > > > Subject: [PATCH 00/11] i.MX8MM power domain support > > > > > > > > Hi all, > > > > > > > > this adds power domain support for the i.MX8MM to the existing GPCv2 > > driver. > > > > It is not complete yet, as it is still missing the VPU and display > > > > power domains, as those require support for the BLK_CTL regions of > > > > the VPUMIX and DISPLAYMIX domains. A Linux driver for those regions > > > > on the i.MX8MP is currently under development and we plan to use > > > > this as a template for the i.MX8MM when the dust has settled. The > > > > changes in this series have been made with this in mind, so once the > > > > BLK_CTL driver exists it should be a matter of hooking things > > > > together via DT, with no further changes required on the GPCv2 driver side > > (famous last words). > > > > Special thanks to Marek Vasut who helped with testing and debugging > > > > of early versions of this code. > > > > > > > > > > Lucas, > > > > > > thanks for working on this, but I think current support for 8MM can NOT 100% > > work due to HW limitation. > > > Maybe, we need further discussion before moving forward, otherwise, we > > > will meet awkward situation when NXP doing LTS upgrade. Below are some > > info shared. > > > 1. The GPU & VPU related power domains need to do special handling due > > to HW limitation, can refer to the power domain sequence > > > In NXP release. > > > > For the GPU this driver already does the same thing as the TF-A based > > implementation by driving the GPU2D and GPU3D domains together and > > triggering the SRC reset. > > > > For the VPU I expect that we can do all the necessary syncing with a proper > > VPU BLK_CTL driver. > > > > Ok, thanks. I saw the reset handling in this patchset. > > > > 2. another reason that we do power domain control in TF-A in NXP release is > > that MAIN NOC power domain can only be controlled by > > > TF-A, and before MAIN NOC power domain, we need to check other > > MIXs' power status. If other power domain is controlled by linux side, > > > It is not easy to cross world status sync. > > > > This is a valid concern and I want to learn more about this. When do you turn > > off MAIN NOC power in the TF-A? Is it just system suspend? If so I think it's a > > valid requirement for the kernel driver to shut down all the peripheral power > > domains before entering system suspend. > > > > The main NOC will be off just in system suspend case. Main NoC on/off is controlled by > GPC HW slot method. As all the MIXs with ADB400 bridge are connected on the main NoC, > we must make sure that all these ADB400 port in power down status when main NoC power off > in system suspend, otherwise system will hang when resume. Previously, all the MIX power domain > is controlled by TF-A, then TF-A knows the status of each MIX, if any MIX is on, we will skip the NOC > power down setting. And that just means the SoC doesn't enter the desired low-power state when going into suspend, right? I think it would be much easier and less error prone to just mandate that all peripheral power domains must be powered down before trying to enter system suspend. Is there any use-case where you would legitimately want to enter a high power suspend state with some of ther peripheral power domains still active? > > > 3. either 8MM, 8MN, or 8MP, the power domain design is different, I am not > > sure if it is the good to add hundreds line of code in GPCv2 each time > > > a new SOC is added. > > > > I don't buy into this argument. We have lots of drivers in the Linux kernel that > > require some changes for new SoC generations, that's what Linux drivers are > > for. The complexity of the hardware doesn't disappear just because you push > > some of the driver bits into TF-A, you just handle the complexity at a different > > palce and IMHO that the wrong place. The power domains have complex > > interactions with other drivers in the Linux system, so debugging and > > deplyong fixes is much easier when the power domain handling is fully done > > by a kernel driver. > > Actually, due to the security requirement from other system solution provider, > for example, Microsoft Azure Sphere, it has strict requirement for power domain > to be controlled by secure subsystem(either TF-A, TEE or dedicated secure domain controller). > Same requirement for reset control, and system critical clock control. Yes, I'm aware of those requirements, but to satisfy those you need a full implementation of all those parts in the secure subsystem. Doing it just for the power domains adds complexity for no gain, as you still won't be able to meet all the requirements and frankly I don't think this is a realistic goal to achieve with the current i.MX8M family of SoCs. Meeting those requirements needs a fully system approach where the secure subsystem parts are made sufficiently independent from the non- secure parts on a hardware level, which I don't see on the i.MX8M SoC and hardware design guide. > For NXP i.MX8M family, it is ok to implement in linux kernel, just a tradeoff to find out a place > to hide the complexity ^_^. > > BTW, for virtualization support, it is better to put the power domain in a central place to simplify > the VM implementation. Same as above. If you can make all the relevant bits (clock, reset, power-domain, regulator) available via a virtualization friendly API, then I would see a point in adding complexity for this abstraction. As long as this added abstraction only solves a very tiny bit of the overall picture, I just don't see the point in the added complexity and (from a Linux PoV) obfuscation. Regards, Lucas > BR > Jacky Bai > > > Regards, > > Lucas > > > > > BR > > > Jacky Bai > > > > > > > Regards, > > > > Lucas > > > > > > > > Lucas Stach (11): > > > > soc: imx: gpcv2: move to more ideomatic error handling in probe > > > > soc: imx: gpcv2: move domain mapping to domain driver probe > > > > soc: imx: gpcv2: split power up and power down sequence control > > > > soc: imx: gpcv2: wait for ADB400 handshake > > > > soc: imx: gpcv2: add runtime PM support for power-domains > > > > soc: imx: gpcv2: allow domains without power-sequence control > > > > soc: imx: gpcv2: add support for optional resets > > > > dt-bindings: add defines for i.MX8MM power domains > > > > soc: imx: gpcv2: add support for i.MX8MM power domains > > > > arm64: dts: imx8mm: add GPC node and power domains > > > > arm64: dts: imx8mm: put USB controllers into power-domains > > > > > > > > .../bindings/power/fsl,imx-gpcv2.yaml | 8 + > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 59 +++ > > > > drivers/soc/imx/gpcv2.c | 501 > > > > +++++++++++++++--- > > > > include/dt-bindings/power/imx8mm-power.h | 22 + > > > > 4 files changed, 516 insertions(+), 74 deletions(-) create mode > > > > 100644 include/dt-bindings/power/imx8mm-power.h > > > > > > > > -- > > > > 2.20.1
