All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Lina Iyer <lina.iyer@linaro.org>,
	John Stultz <john.stultz@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Rob Herring <robh+dt@kernel.org>,
	Magnus Damm <magnus.damm@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power
Date: Tue, 21 Feb 2017 16:45:13 +0000	[thread overview]
Message-ID: <445b2f49-5d15-30af-a431-1c4edcd049a4@arm.com> (raw)
In-Reply-To: <CAMuHMdWjseO3XSOH2XCbM411Aj12RpdZZbHkpfFUfej58myz5Q@mail.gmail.com>

Hi Geert,

On 21/02/17 16:21, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>> This patch series adds support for using non-PMIC wake-up sources on the
>>> Renesas R-Car Gen3 (H3 or M3-W) Salvator-X development boards.
>>>
>>> Nothing in the PSCI specification requires the SoC to remain powered and
>>> to support wake-up sources when suspended using SYSTEM_SUSPEND.
>>> If the firmware implements the PSCI SYSTEM_SUSPEND operation by cutting
>>> power to the SoC, the only possibly wake-up sources are thus the ones
>>> connected to the PMIC.
>>
>> OK, but I don't see any issue with that. That's exactly how it works on
> 
> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
> 

>From wakeup source configuration/management perspective, s2ram and
s2idle are exactly same.

>> ARM Juno platform. The SoC is powered down.
> 
> Good to hear this is not limited to Renesas platforms, so there's a common
> problem to solve.
> 

No, there's no problem to solve. Firmware should enter deepest sleep
state in the system with SYSTEM_SUSPEND from which it can wakeup of course.

>>> To allow other wake-up sources, this patch series documents and adds
>>> support for an "arm,psci-system-suspend-is-power-down" DT property, so
>>
>> NACK, you don't need any such properties.
> 
> If this is true for all PSCI platforms, there's indeed no need for such a
> property, and drivers/firmware/psci.c should default to this case.
> 

Cool.

>>> Linux uses a different suspend method when other wake-up sources (e.g.
>>> wake on LAN, UART or GPIO) are enabled.  Hence the user no longer has to
>>> manually restrict "mem" suspend to "s2idle" or "shallow" states using:
>>
>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>> what you are doing in this patch set. You also get low latency for free
>> as it just enters the deepest idle state on all CPUs instead of
>> hotplugging out all the secondaries.
> 
> Yes, cfr. "s2idle" above.
> The user can specify to use "s2idle" manually:
> 
>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
> 

This looks like custom file for me.
IIUC, the standard sysfs file for the system PM state is:
	/sys/power/state
1. s2ram:
	$ echo mem > /sys/power/state
2. s2idle
	$ echo freeze > /sys/power/state

> However, how to handle this automatically, e.g. by a distro?

As above

> On most other platforms, userspace can just do e.g.
> 
>     ethtool -s eth0 wol g
> 

That should work.

> to enable wake-on-LAN, and suspend to the deepest supported state using:
> 
>     echo mem > /sys/power/state
> 

This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
can't wakeup if it's powered down, then it should not use that state
to implement SYSTEM_SUSPEND in PSCI firmware or just return the
SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
next available state to enter.

Just botching whatever shallow state you can enter on a particular SoC
into standard "mem" state sounds *horrible* to me.

> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
> make sure to configure to use "s2idle" (or "shallow) instead, else the
> configured wake-up sources won't work.

That's perfect. I was worried that user-space is not doing that. So to
summarize, PSCI firmware either:
1. enters a sane and resumable state in SYSTEM_SUSPEND api
or
2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
   in Linux to enter the deepest idle state.

You literally need no extra work to enter this "freeze" state if the
CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
in this "s2idle" you are referring so far.
Just start with:

	$ cat /sys/power/state

and you should see "freeze" there, if not that's the first thing to
check provided the platform has cpuidle working.

Hope this helps.

-- 
Regards,
Sudeep

WARNING: multiple messages have this Message-ID
From: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
To: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Cc: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>,
	Geert Uytterhoeven
	<geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>,
	Lorenzo Pieralisi
	<lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	"Rafael J . Wysocki"
	<rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
	Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Linux-Renesas
	<linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux PM list <linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power
Date: Tue, 21 Feb 2017 16:45:13 +0000	[thread overview]
Message-ID: <445b2f49-5d15-30af-a431-1c4edcd049a4@arm.com> (raw)
In-Reply-To: <CAMuHMdWjseO3XSOH2XCbM411Aj12RpdZZbHkpfFUfej58myz5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Geert,

On 21/02/17 16:21, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>> This patch series adds support for using non-PMIC wake-up sources on the
>>> Renesas R-Car Gen3 (H3 or M3-W) Salvator-X development boards.
>>>
>>> Nothing in the PSCI specification requires the SoC to remain powered and
>>> to support wake-up sources when suspended using SYSTEM_SUSPEND.
>>> If the firmware implements the PSCI SYSTEM_SUSPEND operation by cutting
>>> power to the SoC, the only possibly wake-up sources are thus the ones
>>> connected to the PMIC.
>>
>> OK, but I don't see any issue with that. That's exactly how it works on
> 
> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
> 

>From wakeup source configuration/management perspective, s2ram and
s2idle are exactly same.

>> ARM Juno platform. The SoC is powered down.
> 
> Good to hear this is not limited to Renesas platforms, so there's a common
> problem to solve.
> 

No, there's no problem to solve. Firmware should enter deepest sleep
state in the system with SYSTEM_SUSPEND from which it can wakeup of course.

>>> To allow other wake-up sources, this patch series documents and adds
>>> support for an "arm,psci-system-suspend-is-power-down" DT property, so
>>
>> NACK, you don't need any such properties.
> 
> If this is true for all PSCI platforms, there's indeed no need for such a
> property, and drivers/firmware/psci.c should default to this case.
> 

Cool.

>>> Linux uses a different suspend method when other wake-up sources (e.g.
>>> wake on LAN, UART or GPIO) are enabled.  Hence the user no longer has to
>>> manually restrict "mem" suspend to "s2idle" or "shallow" states using:
>>
>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>> what you are doing in this patch set. You also get low latency for free
>> as it just enters the deepest idle state on all CPUs instead of
>> hotplugging out all the secondaries.
> 
> Yes, cfr. "s2idle" above.
> The user can specify to use "s2idle" manually:
> 
>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
> 

This looks like custom file for me.
IIUC, the standard sysfs file for the system PM state is:
	/sys/power/state
1. s2ram:
	$ echo mem > /sys/power/state
2. s2idle
	$ echo freeze > /sys/power/state

> However, how to handle this automatically, e.g. by a distro?

As above

> On most other platforms, userspace can just do e.g.
> 
>     ethtool -s eth0 wol g
> 

That should work.

> to enable wake-on-LAN, and suspend to the deepest supported state using:
> 
>     echo mem > /sys/power/state
> 

This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
can't wakeup if it's powered down, then it should not use that state
to implement SYSTEM_SUSPEND in PSCI firmware or just return the
SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
next available state to enter.

Just botching whatever shallow state you can enter on a particular SoC
into standard "mem" state sounds *horrible* to me.

> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
> make sure to configure to use "s2idle" (or "shallow) instead, else the
> configured wake-up sources won't work.

That's perfect. I was worried that user-space is not doing that. So to
summarize, PSCI firmware either:
1. enters a sane and resumable state in SYSTEM_SUSPEND api
or
2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
   in Linux to enter the deepest idle state.

You literally need no extra work to enter this "freeze" state if the
CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
in this "s2idle" you are referring so far.
Just start with:

	$ cat /sys/power/state

and you should see "freeze" there, if not that's the first thing to
check provided the platform has cpuidle working.

Hope this helps.

-- 
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID
From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power
Date: Tue, 21 Feb 2017 16:45:13 +0000	[thread overview]
Message-ID: <445b2f49-5d15-30af-a431-1c4edcd049a4@arm.com> (raw)
In-Reply-To: <CAMuHMdWjseO3XSOH2XCbM411Aj12RpdZZbHkpfFUfej58myz5Q@mail.gmail.com>

Hi Geert,

On 21/02/17 16:21, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 20/02/17 20:33, Geert Uytterhoeven wrote:
>>> This patch series adds support for using non-PMIC wake-up sources on the
>>> Renesas R-Car Gen3 (H3 or M3-W) Salvator-X development boards.
>>>
>>> Nothing in the PSCI specification requires the SoC to remain powered and
>>> to support wake-up sources when suspended using SYSTEM_SUSPEND.
>>> If the firmware implements the PSCI SYSTEM_SUSPEND operation by cutting
>>> power to the SoC, the only possibly wake-up sources are thus the ones
>>> connected to the PMIC.
>>
>> OK, but I don't see any issue with that. That's exactly how it works on
> 
> How do you use other wake-up sources, like wake on LAN, UART or GPIO?
> 

>From wakeup source configuration/management perspective, s2ram and
s2idle are exactly same.

>> ARM Juno platform. The SoC is powered down.
> 
> Good to hear this is not limited to Renesas platforms, so there's a common
> problem to solve.
> 

No, there's no problem to solve. Firmware should enter deepest sleep
state in the system with SYSTEM_SUSPEND from which it can wakeup of course.

>>> To allow other wake-up sources, this patch series documents and adds
>>> support for an "arm,psci-system-suspend-is-power-down" DT property, so
>>
>> NACK, you don't need any such properties.
> 
> If this is true for all PSCI platforms, there's indeed no need for such a
> property, and drivers/firmware/psci.c should default to this case.
> 

Cool.

>>> Linux uses a different suspend method when other wake-up sources (e.g.
>>> wake on LAN, UART or GPIO) are enabled.  Hence the user no longer has to
>>> manually restrict "mem" suspend to "s2idle" or "shallow" states using:
>>
>> Have you explored suspend-to-idle instead ? It looks like thats exactly
>> what you are doing in this patch set. You also get low latency for free
>> as it just enters the deepest idle state on all CPUs instead of
>> hotplugging out all the secondaries.
> 
> Yes, cfr. "s2idle" above.
> The user can specify to use "s2idle" manually:
> 
>     $ echo s2idle > /sys/power/mem_sleep # or "shallow"
> 

This looks like custom file for me.
IIUC, the standard sysfs file for the system PM state is:
	/sys/power/state
1. s2ram:
	$ echo mem > /sys/power/state
2. s2idle
	$ echo freeze > /sys/power/state

> However, how to handle this automatically, e.g. by a distro?

As above

> On most other platforms, userspace can just do e.g.
> 
>     ethtool -s eth0 wol g
> 

That should work.

> to enable wake-on-LAN, and suspend to the deepest supported state using:
> 
>     echo mem > /sys/power/state
> 

This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC
can't wakeup if it's powered down, then it should not use that state
to implement SYSTEM_SUSPEND in PSCI firmware or just return the
SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the
next available state to enter.

Just botching whatever shallow state you can enter on a particular SoC
into standard "mem" state sounds *horrible* to me.

> On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must
> make sure to configure to use "s2idle" (or "shallow) instead, else the
> configured wake-up sources won't work.

That's perfect. I was worried that user-space is not doing that. So to
summarize, PSCI firmware either:
1. enters a sane and resumable state in SYSTEM_SUSPEND api
or
2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework
   in Linux to enter the deepest idle state.

You literally need no extra work to enter this "freeze" state if the
CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter
in this "s2idle" you are referring so far.
Just start with:

	$ cat /sys/power/state

and you should see "freeze" there, if not that's the first thing to
check provided the platform has cpuidle working.

Hope this helps.

-- 
Regards,
Sudeep

  reply	other threads:[~2017-02-21 16:45 UTC|newest]

Thread overview: 145+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 20:33 [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven
2017-02-20 20:33 ` Geert Uytterhoeven
2017-02-20 20:33 ` [PATCH/RFC 1/6] alarmtimer: Postpone wake-up source registration until really available Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-20 20:33 ` [PATCH/RFC 2/6] PM / Wakeup: Add wakeup_source_available() Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-20 20:33 ` [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-21 10:42   ` Sudeep Holla
2017-02-21 10:42     ` Sudeep Holla
2017-02-21 16:23     ` Geert Uytterhoeven
2017-02-21 16:23       ` Geert Uytterhoeven
2017-02-21 16:23       ` Geert Uytterhoeven
2017-02-21 16:51       ` Sudeep Holla
2017-02-21 16:51         ` Sudeep Holla
2017-02-21 16:51         ` Sudeep Holla
2017-02-21 11:07   ` Pavel Machek
2017-02-21 11:07     ` Pavel Machek
2017-02-21 11:07     ` Pavel Machek
2017-02-21 11:14     ` Sudeep Holla
2017-02-21 11:14       ` Sudeep Holla
2017-02-21 11:14       ` Sudeep Holla
2017-02-21 16:32       ` Geert Uytterhoeven
2017-02-21 16:32         ` Geert Uytterhoeven
2017-02-21 16:32         ` Geert Uytterhoeven
2017-02-21 17:20         ` Mark Rutland
2017-02-21 17:20           ` Mark Rutland
2017-02-21 17:20           ` Mark Rutland
2017-02-21 17:20           ` Mark Rutland
2017-02-21 18:06           ` Geert Uytterhoeven
2017-02-21 18:06             ` Geert Uytterhoeven
2017-02-21 18:06             ` Geert Uytterhoeven
2017-02-21 18:06             ` Geert Uytterhoeven
2017-02-21 18:18             ` Mark Rutland
2017-02-21 18:18               ` Mark Rutland
2017-02-21 18:18               ` Mark Rutland
2017-02-21 18:23               ` Geert Uytterhoeven
2017-02-21 18:23                 ` Geert Uytterhoeven
2017-02-21 18:23                 ` Geert Uytterhoeven
2017-02-21 18:23                 ` Geert Uytterhoeven
2017-02-21 17:22         ` Sudeep Holla
2017-02-21 17:22           ` Sudeep Holla
2017-02-21 17:22           ` Sudeep Holla
2017-02-21 17:22           ` Sudeep Holla
2017-02-22 13:47           ` Geert Uytterhoeven
2017-02-22 13:47             ` Geert Uytterhoeven
2017-02-22 13:47             ` Geert Uytterhoeven
2017-02-22 14:35             ` Sudeep Holla
2017-02-22 14:35               ` Sudeep Holla
2017-02-22 14:35               ` Sudeep Holla
2017-02-20 20:33 ` [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-21 10:50   ` Sudeep Holla
2017-02-21 10:50     ` Sudeep Holla
2017-02-21 16:36     ` Geert Uytterhoeven
2017-02-21 16:36       ` Geert Uytterhoeven
2017-02-21 16:36       ` Geert Uytterhoeven
2017-02-21 16:49       ` Sudeep Holla
2017-02-21 16:49         ` Sudeep Holla
2017-02-21 16:49         ` Sudeep Holla
2017-02-21 11:07   ` Pavel Machek
2017-02-21 11:07     ` Pavel Machek
2017-02-21 16:36     ` Geert Uytterhoeven
2017-02-21 16:36       ` Geert Uytterhoeven
2017-02-21 16:36       ` Geert Uytterhoeven
2017-02-21 17:54     ` Mark Rutland
2017-02-21 17:54       ` Mark Rutland
2017-02-21 17:48   ` Mark Rutland
2017-02-21 17:48     ` Mark Rutland
2017-02-22 14:05     ` Geert Uytterhoeven
2017-02-22 14:05       ` Geert Uytterhoeven
2017-02-22 14:05       ` Geert Uytterhoeven
2017-02-22 14:57       ` Rafael J. Wysocki
2017-02-22 14:57         ` Rafael J. Wysocki
2017-02-22 14:57         ` Rafael J. Wysocki
2017-02-22 14:57         ` Rafael J. Wysocki
2017-02-20 20:33 ` [PATCH/RFC 5/6] arm64: dts: r8a7795: Fix non-PMIC wake-up sources Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-20 20:33 ` [PATCH/RFC 6/6] arm64: dts: r8a7796: " Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-21 10:38 ` [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Sudeep Holla
2017-02-21 10:38   ` Sudeep Holla
2017-02-21 16:21   ` Geert Uytterhoeven
2017-02-21 16:21     ` Geert Uytterhoeven
2017-02-21 16:21     ` Geert Uytterhoeven
2017-02-21 16:45     ` Sudeep Holla [this message]
2017-02-21 16:45       ` Sudeep Holla
2017-02-21 16:45       ` Sudeep Holla
2017-02-21 16:45       ` Sudeep Holla
2017-02-21 17:34       ` Geert Uytterhoeven
2017-02-21 17:34         ` Geert Uytterhoeven
2017-02-21 17:34         ` Geert Uytterhoeven
2017-02-21 17:51         ` Sudeep Holla
2017-02-21 17:51           ` Sudeep Holla
2017-02-21 17:51           ` Sudeep Holla
2017-02-21 18:27           ` Sudeep Holla
2017-02-21 18:27             ` Sudeep Holla
2017-02-21 18:27             ` Sudeep Holla
2017-02-21 18:27             ` Sudeep Holla
2017-02-21 18:45             ` Sudeep Holla
2017-02-21 18:45               ` Sudeep Holla
2017-02-21 18:45               ` Sudeep Holla
2017-02-21 18:45               ` Sudeep Holla
2017-02-22  1:14               ` Rafael J. Wysocki
2017-02-22  1:14                 ` Rafael J. Wysocki
2017-02-22  1:14                 ` Rafael J. Wysocki
2017-02-22 11:03                 ` Sudeep Holla
2017-02-22 11:03                   ` Sudeep Holla
2017-02-22 11:03                   ` Sudeep Holla
2017-02-22 13:38                   ` Geert Uytterhoeven
2017-02-22 13:38                     ` Geert Uytterhoeven
2017-02-22 13:38                     ` Geert Uytterhoeven
2017-02-22 14:32                     ` Sudeep Holla
2017-02-22 14:32                       ` Sudeep Holla
2017-02-22 14:32                       ` Sudeep Holla
2017-02-22 14:32                       ` Sudeep Holla
2017-02-22 14:50                       ` Rafael J. Wysocki
2017-02-22 14:50                         ` Rafael J. Wysocki
2017-02-22 14:50                         ` Rafael J. Wysocki
2017-02-22 14:50                         ` Rafael J. Wysocki
2017-02-22 15:24                         ` Sudeep Holla
2017-02-22 15:24                           ` Sudeep Holla
2017-02-22 15:24                           ` Sudeep Holla
2017-02-22 15:24                           ` Sudeep Holla
2017-02-23 15:26                       ` Geert Uytterhoeven
2017-02-23 15:26                         ` Geert Uytterhoeven
2017-02-23 15:26                         ` Geert Uytterhoeven
2017-02-23 15:34                         ` Geert Uytterhoeven
2017-02-23 15:34                           ` Geert Uytterhoeven
2017-02-23 15:34                           ` Geert Uytterhoeven
2017-02-23 15:58                           ` Sudeep Holla
2017-02-23 15:58                             ` Sudeep Holla
2017-02-23 15:58                             ` Sudeep Holla
2017-02-23 15:53                         ` Sudeep Holla
2017-02-23 15:53                           ` Sudeep Holla
2017-02-23 15:53                           ` Sudeep Holla
2017-02-23 15:53                           ` Sudeep Holla
2017-02-22 13:14                 ` Geert Uytterhoeven
2017-02-22 13:14                   ` Geert Uytterhoeven
2017-02-22 13:14                   ` Geert Uytterhoeven
2017-02-22 14:31                   ` Rafael J. Wysocki
2017-02-22 14:31                     ` Rafael J. Wysocki
2017-02-22 14:31                     ` Rafael J. Wysocki
2017-02-22 14:31                     ` Rafael J. Wysocki

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=445b2f49-5d15-30af-a431-1c4edcd049a4@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=john.stultz@linaro.org \
    --cc=len.brown@intel.com \
    --cc=lina.iyer@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=magnus.damm@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    /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.