Re: soc: imx: gpcv2: regulator issue with system suspend on imx8mq

From: Martin Kepplinger
Date: Thu Jun 09 2022 - 08:57:46 EST


Am Donnerstag, dem 09.06.2022 um 11:41 +0200 schrieb Martin Kepplinger:
> hi Lucas and all interested in suspend to ram on imx8mq,
>
> This is slighly repeating my previous observations that still apply,
> but summarizing the situation:
>
> s2idle should work on mainline when looking at the implementations of
> platform drivers. With the missing bits
> https://source.codeaurora.org/external/imx/linux-imx/commit/?h=imx_5.10.35_2.0.0_imx8ulp_er&id=ab850d655c22df562c27c9d6775a26b6df6865b5
> and
> https://lore.kernel.org/linux-arm-kernel/1631554694-9599-7-git-send-email-abel.vesa@xxxxxxx/
> suspend to ram should work too,
> and it does for me, except when a power domain is using a board-
> regulator as power-supply that is not always-on, but controlled by a
> driver. (when I describe these as "always-on", things are fine
> (except
> for unrelated edgecases)) here's the example I'm running where I
> don't
> describe "buck3" as always-on, but etnaviv runtime pm is controlling
> it:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi#n1161
> When starting to resume, the following happens:
>
> [  139.985440] Enabling non-boot CPUs ...
> [  139.990363] Detected VIPT I-cache on CPU1
> [  139.990413] GICv3: CPU1: found redistributor 1 region
> 0:0x00000000388a0000
> [  139.990487] CPU1: Booted secondary processor 0x0000000001
> [0x410fd034]
> [  139.991445] CPU1 is up
> [  140.011836] Detected VIPT I-cache on CPU2
> [  140.011852] GICv3: CPU2: found redistributor 2 region
> 0:0x00000000388c0000
> [  140.011876] CPU2: Booted secondary processor 0x0000000002
> [0x410fd034]
> [  140.012284] CPU2 is up
> [  140.032739] Detected VIPT I-cache on CPU3
> [  140.032756] GICv3: CPU3: found redistributor 3 region
> 0:0x00000000388e0000
> [  140.032780] CPU3: Booted secondary processor 0x0000000003
> [0x410fd034]
> [  140.033310] CPU3 is up
> [  140.158791] imx-pgc imx-pgc-domain.5: failed to enable regulator:
> -
> 110

the call trace here is

[ 901.637677] imx_pgc_power_up+0x2e0/0x330
[ 901.641696] _genpd_power_on+0x80/0x16c
[ 901.645540] genpd_sync_power_on.part.0+0xac/0xe0
[ 901.650248] genpd_resume_noirq+0x70/0x120
[ 901.654347] dpm_run_callback+0x60/0x1f0
[ 901.658271] device_resume_noirq+0x108/0x230
[ 901.662542] dpm_noirq_resume_devices+0x12c/0x334
[ 901.667248] dpm_resume_noirq+0x1c/0x30
[ 901.671085] suspend_devices_and_enter+0x31c/0x894
[ 901.675884] pm_suspend+0x3a0/0x41c
[ 901.679374] state_store+0x98/0x120
[ 901.682864] kobj_attr_store+0x1c/0x30
[ 901.686621] sysfs_kf_write+0x50/0x60

>
> trying runtime-resume in system-suspend for i2c busses didn't help me
> here for example. What's your idea for solving this? (regulator
> always-
> on is not an acceptable workaround :) I'm always happy to test
> concrete
> ideas and would like to know from anyone who uses system suspend on
> imx8mq.
>
> history
> -------
> last time this came to my attention via the mainling lists was the
> VPU
> addition:
> https://lore.kernel.org/linux-arm-kernel/8ed3a28d59b442b531e68e95d83b187bb3392940.camel@xxxxxxx/
> but for the above logs and all current tests, I ignore the VPU (set
> the
> power-supply always-on) simply because the the driver is in staging
> and
> seems to create a different problem when suspending, and the GPU
> power-
> supply example is very well suited to highlight the problem.
>
> but before that, "gpcv2: support systemd suspend/resume"
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da4112230f86
> ) didn't work for me, see:
> https://lore.kernel.org/all/a20ecd639f8e8b7fa4a9bed7a8e9590225262784.camel@xxxxxxx/
>
> thanks a lot,
>
>                                martin
>
>