Suspend/resume on A311D

MNT Pocket Reform
7

I’ve actually been working on doing the same thing; I’ve compared your diff to mine and they’re nearly exactly the same, modulo some reordering towards the end and a small difference: mine has

- g12a_eth_core 0       0       0        166666664   0        0        50000     N
+ g12a_eth_core 1       1       0        166666664   0        0        50000     Y

and yours has

- g12a_vpu_intr 1       1        0        166666664   0          0     50000      Y                           ff600000.hdmi-tx                venci                    
+ g12a_vpu_intr 1       1        0        166666664   0          0     50000      N                           ff600000.hdmi-tx                venci

(Maybe your HDMI port was plugged in, maybe there’s a difference between where we dumped the clocks, or maybe we’re on different kernels?)

So the clocks that both of our results have differing pre- and post-suspend are:

  • g12a_ao_saradc_gate (disabled after resume)
  • ts (disabled after resume)
  • gp0_pll_dco (disabled after resume)
  • sys_pll_dco (enabled after resume)
  • ff64c00.mdio-multiplexer#pll (disabled after resume)
  • g12a_mipi_dsi_host (disabled after resume)
  • g12a_ao_saradc (disabled after resume)

I also added some other printk-style debug statements in kernel/power/suspend.c and ascertained that:

  • In suspend_enter, pm_sleep_disable_secondary_cpus() does not return an error.
  • In suspend_enter, syscore_suspend() does not return an error.
  • In suspend_devices_and_enter, the while loop exits when error and wakeup are both zero, so I guess it’s waking up because the result of platform_suspend_again(state) is nonzero.

My suspicion is that the change in some of the clocks related to video are causing the stacktrace in drm and meson I posted above. I’ve started working on a patch to restore all of these clocks to their previous states in meson_drv_pm_resume, that seems like the most natural place for a hack to validate this approach?

1 Like