[...] >> >> >> Unfortunate, I am still not fully understanding the scenarios. As you >> indicate, the problem seems related to wakeup settings. >> >> Could you please try to answer the below questions, hopefully it helps >> me to better understand. >> >> 1) >> While starting the system suspend sequence, under what circumstances >> are you expecting the vdd_gpu and pd_gpu to be powered on? >> > > I don't want to power on the vdd_gpu and pd_gpu during the system suspend > sequence. > I hope the pd_gpu and vdd_gpu power on/off just by gpu device. Let me rephrase my question. Can the vdd_gpu/pd_gpu ever remain in a powered on state while the system is suspended? If yes, when is that the case? > >> 2) >> While starting the system suspend sequence, under what circumstances >> are you expecting the vdd_gpu and the pd_gpu to be powered off? >> > > I don't want to power off the vdd_gpu and pd_gpu during the system suspend > sequence. > Because before the system suspend,the vdd_gpu and pd_gpu has been power off > by gpu device(pm_ruantime_put). *Exactly*, how do you guarantee that a pm_runtime_put() for the gpu device triggers a runtime suspend - before a system suspend sequence starts? For example, userspace may via sysfs prevent runtime suspend for any device with runtime PM enabled. > >> 3) >> What devices are attached to vdd_gpu? >> > just pd_gpu >> >> 4) >> What devices are attached to pd_gpu? >> > just gpu device(mali driver) > > vdd_gpu > ------- pd_gpu > ----------------devices/platform/ff9a0000.gpu >> >> Thanks for these details, very useful! [...] Kind regards Uffe
