[PATCH v2 12/13] arm64: dts: imx8mm: add GPC node and power domains
Adam Ford
aford173 at gmail.com
Thu Feb 18 10:19:51 EST 2021
On Thu, Feb 18, 2021 at 6:54 AM Adam Ford <aford173 at gmail.com> wrote:
>
> On Thu, Jan 14, 2021 at 4:39 AM Frieder Schrempf
> <frieder.schrempf at kontron.de> wrote:
> >
> > On 09.12.20 16:26, Frieder Schrempf wrote:
> > > Hi Lucas,
> > >
> > > On 05.11.20 18:44, Lucas Stach wrote:
> > >> This adds the DT nodes to describe the power domains available on the
> > >> i.MX8MM. Things are a bit more complex compared to other GPCv2 power
> > >> domain setups, as there is now a hierarchy of domains where complete
> > >> subsystems (HSIO, GPU, DISPLAY) can be gated as a whole, but also
> > >> fine granular gating within those subsystems is possible.
> > >>
> > >> Note that this is still incomplete, as both VPU and DISP domains are
> > >> missing their reset clocks. Those aren't directly sourced from the CCM,
> > >> but have another level of clock gating in the BLKCTL of those domains,
> > >> which needs a separate driver.
> > >>
> > >> Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
> > >> ---
> > >> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 58 +++++++++++++++++++++++
> > >> 1 file changed, 58 insertions(+)
> > >>
> > >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > >> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > >> index b83f400def8b..c21901a8aea9 100644
> > >> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > >> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > >> @@ -4,6 +4,8 @@
> > >> */
> > >> #include <dt-bindings/clock/imx8mm-clock.h>
> > >> +#include <dt-bindings/power/imx8mm-power.h>
> > >> +#include <dt-bindings/reset/imx8mq-reset.h>
> > >> #include <dt-bindings/gpio/gpio.h>
> > >> #include <dt-bindings/input/input.h>
> > >> #include <dt-bindings/interrupt-controller/arm-gic.h>
> > >> @@ -547,6 +549,62 @@
> > >> interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
> > >> #reset-cells = <1>;
> > >> };
> > >> +
> > >> + gpc: gpc at 303a0000 {
> > >> + compatible = "fsl,imx8mm-gpc";
> > >> + reg = <0x303a0000 0x10000>;
> > >> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> > >> + interrupt-parent = <&gic>;
> > >> + interrupt-controller;
> > >> + #interrupt-cells = <3>;
> > >> +
> > >> + pgc {
> > >> + #address-cells = <1>;
> > >> + #size-cells = <0>;
> > >> +
> > >> + pgc_hsiomix: power-domain at 0 {
> > >> + #power-domain-cells = <0>;
> > >> + reg = <IMX8MM_POWER_DOMAIN_HSIOMIX>;
> > >> + clocks = <&clk IMX8MM_CLK_USB_BUS>;
> > >> + };
> > >> +
> > >> + pgc_pcie: power-domain at 1 {
> > >> + #power-domain-cells = <0>;
> > >> + reg = <IMX8MM_POWER_DOMAIN_PCIE>;
> > >> + power-domains = <&pgc_hsiomix>;
> > >> + };
> > >> +
> > >> + pgc_otg1: power-domain at 2 {
> > >> + #power-domain-cells = <0>;
> > >> + reg = <IMX8MM_POWER_DOMAIN_OTG1>;
> > >> + power-domains = <&pgc_hsiomix>;
> > >> + };
> > >> +
> > >> + pgc_otg2: power-domain at 3 {
> > >> + #power-domain-cells = <0>;
> > >> + reg = <IMX8MM_POWER_DOMAIN_OTG2>;
> > >> + power-domains = <&pgc_hsiomix>;
> > >> + };
> > >
> > > I'm currently doing some testing on top of v5.10-rc with GPC, BLK-CTL,
> > > DSIM, etc. I noticed that as soon as I add the nodes above for HSIO/OTG
> > > (even without referencing them elsewhere) my system freezes on
> > > suspend/resume.
> > >
> > > The same problem exists when I remove the power domains for HSIO/USB and
> > > add the ones for DISPMIX and DSI to test Marek's work on BLK-CTL.
> > >
> > > I'm not really sure at what point exactly the system freezes but this is
> > > what I see (no_console_suspend is set) and the system does not wake up
> > > anymore:
> > >
> > > echo mem > /sys/power/state
> > > [ 13.888711] PM: suspend entry (deep)
> > > [ 13.892429] Filesystems sync: 0.000 seconds
> > > [ 13.907231] Freezing user space processes ... (elapsed 0.031 seconds)
> > > done.
> > > [ 13.945407] OOM killer disabled.
> > > [ 13.948642] Freezing remaining freezable tasks ... (elapsed 0.001
> > > seconds) done.
> > > [ 13.957216] printk: Suspending console(s) (use no_console_suspend to
> > > debug)
> >
> > It seems like I failed to set no_console_suspend correctly. Here is a
> > proper log with kernel 5.10.6. The system wakes up, but stalls.
> >
> > Can you reproduce this on your system?
> >
> [snip]
>
> Frieder / Lucas,
>
> I was able to get similar behavior on the Nano. I rebased Lucas'
> patch on the 5.11 kernel, and applied the corresponding patches to my
> Nano board. It works fine until the system sleeps, but after it
> wakes, even the heartbeat LED stops beating. I don't know if there is
> a conflict between TF-A and the gpc driver in there, or if the gpcv2
> driver needs to do something differently to wake the system from
> sleep.
>
> # echo mem > /sys/power/state
> [ 3754.346162] PM: suspend entry (deep)
> [ 3754.349872] Filesystems sync: 0.000 seconds
> [ 3754.387641] Freezing user space processes ... (elapsed 0.001 seconds) done.
> [ 3754.395890] OOM killer disabled.
> [ 3754.399141] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds) done.
> [ 3754.407674] printk: Suspending console(s) (use no_console_suspend to debug)
> [ 3754.992015] Disabling non-boot CPUs ...
> [ 3755.027902] i.mx8mm_thermal 30260000.tmu: failed to register
> thermal zone sensor[0]: -517
> [ 3755.036317] OOM killer enabled.
> [ 3755.039467] Restarting tasks ... done.
> [ 3755.050669] PM: suspend exit
> root at imx8mmevk:~#
>
> Then it hangs.
I did some additional digging on both the Mini and Nano. Both of
their reference manuals have example code which enables and disables
CM_CCGR(69), hsio_bus clock when enabling/disabling the power domains.
It looks like the offset for CCM_CCGR69 is 0x4450. This clock appears
to be enabled by default at boot, however, there doesn't appear to be
a clock entry for this.
I tried to create one based on the 8MP that looks like:
hws[IMX8MN_CLK_HSIO_ROOT] = imx_clk_hw_gate4("hsio_root_clk",
"ipg_root", base + 0x4450, 0);
I then added the hsio clock to the clock table and reference it from
the power-domain node, but at boot it appears to hang at boot, so I am
not sure I did it correctly.
>From what I can tell, neither the NXP kernel nor their ATF show a
reference to CCGR(69), so I also wonder if the TRM for either Mini or
Nano is correct.
adam
>
> adam
More information about the linux-arm-kernel
mailing list