lkml.org 
[lkml]   [2017]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2] PM / Domains: Keep the pd status during system PM phases
[...]

>>
>>
>> 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

\
 
 \ /
  Last update: 2017-02-07 09:19    [W:0.066 / U:1.944 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site