public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 09:41:11 +0800	[thread overview]
Message-ID: <589925B7.4020009@rock-chips.com> (raw)
In-Reply-To: <CAPDyKFpXXL+zpGZCYSEqtJ6_1=tH+FCths7HuuO5OdRcALoRRA@mail.gmail.com>



On 02/06/2017 08:46 PM, Ulf Hansson wrote:
> On 5 February 2017 at 10:34, Elaine Zhang <zhangqing@rock-chips.com> wrote:
>>
>>
>> On 01/26/2017 05:30 AM, Ulf Hansson wrote:
>>>
>>> On 22 January 2017 at 04:34, Elaine Zhang <zhangqing@rock-chips.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 01/20/2017 09:16 PM, Ulf Hansson wrote:
>>>>>
>>>>>
>>>>> On 20 January 2017 at 03:21, Elaine Zhang <zhangqing@rock-chips.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> If a PM domain is powered off before system suspend,
>>>>>> we hope do nothing in system runtime suspend noirq phase
>>>>>> and system runtime resume noirq phase.
>>>>>
>>>>>
>>>>>
>>>>> One can hope, but that isn't good enough. :-)
>>>>>
>>>>>
>>>>>>
>>>>>> This modify is to slove system resume issue for RK3399.
>>>>>> RK3399 SOC pd_gpu have voltage domain vdd_gpu,
>>>>>> so we must follow open vdd_gpu and power on pd_gpu,
>>>>>> power off pd_gpu and disable vdd_gpu.
>>>>>> Fix up in runtime resume noirq phase power on all PDs.
>>>>>
>>>>>
>>>>>
>>>>> This doesn't make any sense to me. Can please try to explain this is
>>>>> in great more detail, then I can try to help.
>>>>>
>>>> For example:
>>>> -->device suspend
>>>>      (mali gpu driver set pd_gpu off by pm_runtime_put_sync(),
>>>
>>>
>>> This is the wrong approach, as runtime suspend is prevented by the PM
>>> core in this phase. More precisely, it does a
>>> pm_runtime_get_noresume() in the device prepare phase.
>>>
>>> I think it seems like you would benefit from using the so called the
>>> runtime PM centric approach, which gives you system PM support for
>>> "free". Please have a look at the pm_runtime_force_suspend|resume()
>>> helpers.
>>>
>>>>       and then disabled the vdd_gpu by regulator_disable().)
>>>>           --> system suspend
>>>>                   -->prepare
>>>>                           -->suspend_noirq():
>>>>                           (power off all pds)
>>>>           -->system resume
>>>>                   -->resume_noirq():
>>>>                   (power up all pds)
>>>>                   (in this case the vdd_gpu is still disabled,
>>>>                    if power on the pd_gpu maybe make the system crash)
>>>>           -->complete : power off the not used pd
>>>> -->device resuem
>>>>      (mali gpu driver enable vdd_gpu by regulator_enable(),
>>>>       and then power up the pd_gpu by pm_runtime_get_sync())
>>>
>>>
>>> Seems like there is also a missing configuration of the relationship
>>> between the PM domains. In the genpd terminology, you probably want to
>>> set pd_gpu as a subdomain of the vdd_gpu.
>>>
>>> In that way, the vdd_gpu is always powered on before pd_gpu is powered
>>> on. And vice verse when powering off.
>>>
>> I thought about this project, but can't slove the problem of sleep and wakp
>> up issue.
>> Because
>>          -->system resume
>>                   -->resume_noirq():
>>                    (power up all pds)
>> In this case, we set pd_gpu as a subdomain of the vdd_gpu.
>> And then to enable the vdd_gpu,but the system resume is not complete yet,
>> the regulator and i2c can't work.So the vdd_gpu enable will failed.
>
> Okay, I see.
>
>>
>> So I think the more appropriate solution is keep the pd status during system
>> PM phases.
>> If a PM domain is powered off before system suspend,
>> we hope do nothing in system runtime suspend noirq phase
>> and system runtime resume noirq phase.
>
> 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.

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

> 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
>
>>
>>>>
>>>> So for RK3399 soc, if to set pd_gpu the vdd_gpu must be enabled, or else
>>>> will can't get the ack back.
>>>> I hope the pd_gpu power up/off by the driver itself.
>>>>
>
> [...]
>
> Kind regards
> Uffe
>
>
>

  reply	other threads:[~2017-02-07  1:44 UTC|newest]

Thread overview: 10+ 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 [this message]
2017-02-07  8:19             ` Ulf Hansson
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=589925B7.4020009@rock-chips.com \
    --to=zhangqing@rock-chips.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko@sntech.de \
    --cc=huangtao@rock-chips.com \
    --cc=khilman@kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=ulf.hansson@linaro.org \
    --cc=wxt@rock-chips.com \
    --cc=xf@rock-chips.com \
    --cc=xxx@rock-chips.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox