From: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
To: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Tao Huang <huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
"linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Feng Xiao <xf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
"Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>,
xxx-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Subject: Re: [PATCH v2] PM / Domains: Keep the pd status during system PM phases
Date: Tue, 07 Feb 2017 17:22:51 +0800 [thread overview]
Message-ID: <589991EB.9090501@rock-chips.com> (raw)
In-Reply-To: <CAPDyKFojbX1uiS00EsyxxkM5uLUbHkbu3xAN4R5=PKo4iFOcCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 02/07/2017 04:19 PM, Ulf Hansson wrote:
> [...]
>
>>>
>>>
>>> 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?
>
NO, the vdd_gpu/pd_gpu ever remain in a powered off 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.
>
Yes, you are right.I did't consider this.
Whether on or off pd_gpu, the vdd_gpu is must be enabled.How to deal
with the enable/disable the vdd_gpu?
our process in devices/platform/ff9a0000.gpu:
device init
pm_runtime_enable()
gpu_power_on
regulator_enable(vdd_gpu)
pm_runtime_get_sync(pd_gpu)
gpu_power_off
pm_runtime_put_sync(pd_gpu)
regulator_disable(vdd_gpu)
device remove
pm_runtime_disable()
>>
>>> 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
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Elaine Zhang <zhangqing@rock-chips.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Feng Xiao <xf@rock-chips.com>, Heiko Stuebner <heiko@sntech.de>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Kevin Hilman <khilman@kernel.org>, Pavel Machek <pavel@ucw.cz>,
Len Brown <len.brown@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Tao Huang <huangtao@rock-chips.com>,
xxx@rock-chips.com, Caesar Wang <wxt@rock-chips.com>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] PM / Domains: Keep the pd status during system PM phases
Date: Tue, 07 Feb 2017 17:22:51 +0800 [thread overview]
Message-ID: <589991EB.9090501@rock-chips.com> (raw)
In-Reply-To: <CAPDyKFojbX1uiS00EsyxxkM5uLUbHkbu3xAN4R5=PKo4iFOcCA@mail.gmail.com>
On 02/07/2017 04:19 PM, Ulf Hansson wrote:
> [...]
>
>>>
>>>
>>> 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?
>
NO, the vdd_gpu/pd_gpu ever remain in a powered off 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.
>
Yes, you are right.I did't consider this.
Whether on or off pd_gpu, the vdd_gpu is must be enabled.How to deal
with the enable/disable the vdd_gpu?
our process in devices/platform/ff9a0000.gpu:
device init
pm_runtime_enable()
gpu_power_on
regulator_enable(vdd_gpu)
pm_runtime_get_sync(pd_gpu)
gpu_power_off
pm_runtime_put_sync(pd_gpu)
regulator_disable(vdd_gpu)
device remove
pm_runtime_disable()
>>
>>> 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
>
>
>
next prev parent reply other threads:[~2017-02-07 9:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 2:21 [PATCH v2] PM / Domains: Keep the pd status during system PM phases Elaine Zhang
2017-01-20 8:38 ` Greg KH
2017-01-20 13:16 ` Ulf Hansson
2017-01-22 3:34 ` Elaine Zhang
2017-01-25 21:30 ` Ulf Hansson
2017-02-05 9:34 ` Elaine Zhang
2017-02-06 12:46 ` Ulf Hansson
2017-02-07 1:41 ` Elaine Zhang
2017-02-07 8:19 ` Ulf Hansson
[not found] ` <CAPDyKFojbX1uiS00EsyxxkM5uLUbHkbu3xAN4R5=PKo4iFOcCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-07 9:22 ` Elaine Zhang [this message]
2017-02-07 9:22 ` Elaine Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=589991EB.9090501@rock-chips.com \
--to=zhangqing-tnx95d0mmh7dzftrwevzcw@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
--cc=huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=pavel-+ZI9xUNit7I@public.gmane.org \
--cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
--cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=xf-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=xxx-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.