On Mon, Feb 10, 2025 at 2:24 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > On Fri, 7 Feb 2025 at 16:08, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > Instrumenting all dev->power.completion accesses in > > drivers/base/power/main.c reveals that resume is blocked in dpm_wait() > > in the call to wait_for_completion() for regulator-1p2v, which is > > indeed a dependency for the SN65DSI86 DSI-DP bridge. Comparing > > [...] > > > Looking at /sys/devices/virtual/devlink, the non-working case has the > > following extra entries: > > Note that the SN65DSI86 DSI-DP bridge driver uses the auxiliary bus > to create four subdevices: > - ti_sn65dsi86.aux.0, > - ti_sn65dsi86.bridge.0, > - ti_sn65dsi86.gpio.0, > - ti_sn65dsi86.pwm.0. > None of them have supplier:* symlinks in sysfs, so perhaps that is > the root cause of the issue? Hi Geert, Sorry, I haven't had time to look into this closely. Couple of questions/suggestions that might give you some answers. Is this an issue only happening for s2idle or for s2ram too? I'd guess both, but if not, that might tell you something? The only reason the wait_for_completion() wouldn't work is because the supplier is not "completing"? There's some weird direct_complete logic that I haven't fully understood. You can look at that to see if some of the devices are skipping their resumes and hence the "completes" too? Also, runtime PM and some flag can cause some lazy resume or avoid suspending already suspended devices behavior. Check that too. Hope this helps. -Saravana
