Skip to content

work around system suspend ordering issues

I'd appreciate testing whether this makes suspend/resume more stable:

This reverts all "reverts" and bad workarounds we have wrt. system suspend in our tree, but adds a new one (that I can try to fix or imporove still). results from discussions linked to in #419 (closed) :

imx8mq can't yet resume from suspend when using the bd71839 pmic via i2c. The original report here, just for the background:

https://lore.kernel.org/linux-arm-kernel/2d5d3bbec443742506e39488dbfbf724bb4ca93f.camel@puri.sm/T/#u

But here's what I think is going on: When the (buck3) regulator from bd71839 is the power-supply for a power domain (gpu), the power domain driver can't resume because buck3 can't be enabled when the pmic isn't running yet. I'm still a bit uncertain, but here's the logs when simply printing in the respective suspend/resume callbacks:

    [  452.199600] bd718xx-pmic bd71837-pmic.2.auto: bd718xx_resume_noirq
    [  452.301450] imx-pgc imx-pgc-domain.5: failed to enable regulator: -
    ETIMEDOUT
    [  452.320593] imx-i2c 30a20000.i2c: i2c_imx_resume
    [  452.322152] bd718xx-pmic bd71837-pmic.2.auto: bd718xx_resume
    [  452.323853] imx-i2c 30a30000.i2c: i2c_imx_resume
    [  452.324778] imx-i2c 30a40000.i2c: i2c_imx_resume
    [  452.325017] imx-i2c 30a50000.i2c: i2c_imx_resume
    

and regulator_enable() in imx-pgc is called from genpd_resume_noirq().

So to work around this, call genpd_resume_noirq() during the normal system resume stage (later). By that time, regulators should be controllable again.

For the issue description see also https://lore.kernel.org/linux-pm/573166b75e524517782471c2b7f96e03fd93d175.camel@puri.sm/T/#u

This also brings in the 2 VPUs - one for decoding H264/VP8 and one for H265/VP9.

Fixes #420 (closed) #419 (closed)

Edited by Martin Kepplinger

Merge request reports