From: Colin Cross <ccross@android.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Kevin Hilman <khilman@ti.com>, Len Brown <len.brown@intel.com>,
linux-kernel@vger.kernel.org,
Amit Kucheria <amit.kucheria@linaro.org>,
linux-tegra@vger.kernel.org, linux-pm@lists.linux-foundation.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/3] coupled cpuidle state support
Date: Wed, 21 Dec 2011 11:42:28 -0800 [thread overview]
Message-ID: <CAMbhsRSPCo9MSGp57Fv0sRdYUFcdwx8jEz1-CfX8LdKf8X4MVg@mail.gmail.com> (raw)
In-Reply-To: <4EF2352C.3060102@linux.intel.com>
On Wed, Dec 21, 2011 at 11:36 AM, Arjan van de Ven
<arjan@linux.intel.com> wrote:
>>>
>>> .. or it enters WFI, and a physical device sends it an interrupt,
>>> at which point it exits.
>>
>> None of the cpus will return to the idle loop until all cpus have
>> decremented the ready counter back to 0, so they can't wrap around
>> again.
>
>
> yikes, so you IPI all the cpus on the first exit.
> that must burn power ;-(
No, you're not understanding the point of this series.
If your cpus can go in and out of idle independently, you don't use
this code at all. Each cpu can call WFI and come back out without
talking to the other cpu.
However, if you have two cpus that share some part of the SoC that can
be turned off in idle, like the L2 cache controller or the system bus,
the two cpus need to go to idle together, and they will both boot
together when either one receives an interrupt (although one will
likely immediately go back to a shallower state that doesn't require
coordination with the other cpu). There is no way around this, it's
how the hardware works on some ARM platforms.
WARNING: multiple messages have this Message-ID (diff)
From: Colin Cross <ccross@android.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Kevin Hilman <khilman@ti.com>, Len Brown <len.brown@intel.com>,
linux-kernel@vger.kernel.org,
Amit Kucheria <amit.kucheria@linaro.org>,
linux-tegra@vger.kernel.org, linux-pm@lists.linux-foundation.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [linux-pm] [PATCH 0/3] coupled cpuidle state support
Date: Wed, 21 Dec 2011 11:42:28 -0800 [thread overview]
Message-ID: <CAMbhsRSPCo9MSGp57Fv0sRdYUFcdwx8jEz1-CfX8LdKf8X4MVg@mail.gmail.com> (raw)
In-Reply-To: <4EF2352C.3060102@linux.intel.com>
On Wed, Dec 21, 2011 at 11:36 AM, Arjan van de Ven
<arjan@linux.intel.com> wrote:
>>>
>>> .. or it enters WFI, and a physical device sends it an interrupt,
>>> at which point it exits.
>>
>> None of the cpus will return to the idle loop until all cpus have
>> decremented the ready counter back to 0, so they can't wrap around
>> again.
>
>
> yikes, so you IPI all the cpus on the first exit.
> that must burn power ;-(
No, you're not understanding the point of this series.
If your cpus can go in and out of idle independently, you don't use
this code at all. Each cpu can call WFI and come back out without
talking to the other cpu.
However, if you have two cpus that share some part of the SoC that can
be turned off in idle, like the L2 cache controller or the system bus,
the two cpus need to go to idle together, and they will both boot
together when either one receives an interrupt (although one will
likely immediately go back to a shallower state that doesn't require
coordination with the other cpu). There is no way around this, it's
how the hardware works on some ARM platforms.
WARNING: multiple messages have this Message-ID (diff)
From: ccross@android.com (Colin Cross)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-pm] [PATCH 0/3] coupled cpuidle state support
Date: Wed, 21 Dec 2011 11:42:28 -0800 [thread overview]
Message-ID: <CAMbhsRSPCo9MSGp57Fv0sRdYUFcdwx8jEz1-CfX8LdKf8X4MVg@mail.gmail.com> (raw)
In-Reply-To: <4EF2352C.3060102@linux.intel.com>
On Wed, Dec 21, 2011 at 11:36 AM, Arjan van de Ven
<arjan@linux.intel.com> wrote:
>>>
>>> .. or it enters WFI, and a physical device sends it an interrupt,
>>> at which point it exits.
>>
>> None of the cpus will return to the idle loop until all cpus have
>> decremented the ready counter back to 0, so they can't wrap around
>> again.
>
>
> yikes, so you IPI all the cpus on the first exit.
> that must burn power ;-(
No, you're not understanding the point of this series.
If your cpus can go in and out of idle independently, you don't use
this code at all. Each cpu can call WFI and come back out without
talking to the other cpu.
However, if you have two cpus that share some part of the SoC that can
be turned off in idle, like the L2 cache controller or the system bus,
the two cpus need to go to idle together, and they will both boot
together when either one receives an interrupt (although one will
likely immediately go back to a shallower state that doesn't require
coordination with the other cpu). There is no way around this, it's
how the hardware works on some ARM platforms.
next prev parent reply other threads:[~2011-12-21 19:42 UTC|newest]
Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-21 0:09 [PATCH 0/3] coupled cpuidle state support Colin Cross
2011-12-21 0:09 ` Colin Cross
2011-12-21 0:09 ` Colin Cross
2011-12-21 0:09 ` [PATCH 1/3] cpuidle: refactor out cpuidle_enter_state Colin Cross
2011-12-21 0:09 ` Colin Cross
2011-12-21 0:09 ` Colin Cross
2012-01-04 14:08 ` Jean Pihet
2012-01-04 14:08 ` [linux-pm] " Jean Pihet
2012-01-04 14:08 ` Jean Pihet
[not found] ` <1324426147-16735-1-git-send-email-ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>
2011-12-21 0:09 ` [PATCH 2/3] cpuidle: fix error handling in __cpuidle_register_device Colin Cross
2011-12-21 0:09 ` Colin Cross
2011-12-21 0:09 ` Colin Cross
2011-12-21 0:09 ` Colin Cross
2011-12-21 0:09 ` [PATCH 3/3] cpuidle: add support for states that affect multiple cpus Colin Cross
2011-12-21 0:09 ` Colin Cross
2011-12-21 0:09 ` Colin Cross
2011-12-21 9:02 ` [PATCH 0/3] coupled cpuidle state support Arjan van de Ven
2011-12-21 9:02 ` Arjan van de Ven
2011-12-21 9:02 ` Arjan van de Ven
[not found] ` <4EF1A0B4.5080307-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2011-12-21 9:40 ` Colin Cross
2011-12-21 9:40 ` Colin Cross
2011-12-21 9:40 ` Colin Cross
2011-12-21 9:44 ` Arjan van de Ven
2011-12-21 9:44 ` Arjan van de Ven
2011-12-21 9:44 ` Arjan van de Ven
[not found] ` <4EF1AA8A.8060304-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2011-12-21 9:55 ` Colin Cross
2011-12-21 9:55 ` Colin Cross
2011-12-21 9:55 ` Colin Cross
2011-12-21 12:12 ` Arjan van de Ven
2011-12-21 12:12 ` Arjan van de Ven
2011-12-21 12:12 ` Arjan van de Ven
2011-12-21 19:05 ` Colin Cross
2011-12-21 19:05 ` Colin Cross
2011-12-21 19:05 ` Colin Cross
[not found] ` <CAMbhsRRnKoR3YPWrZzVynVe+dcuU5v0siYvmp2vbBcS1hquC7Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-12-21 19:36 ` Arjan van de Ven
2011-12-21 19:36 ` Arjan van de Ven
2011-12-21 19:36 ` Arjan van de Ven
2011-12-21 19:42 ` Colin Cross [this message]
2011-12-21 19:42 ` [linux-pm] " Colin Cross
2011-12-21 19:42 ` Colin Cross
[not found] ` <CAMbhsRSPCo9MSGp57Fv0sRdYUFcdwx8jEz1-CfX8LdKf8X4MVg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-12-22 8:35 ` Shilimkar, Santosh
2011-12-22 8:35 ` Shilimkar, Santosh
2011-12-22 8:35 ` Shilimkar, Santosh
2011-12-22 8:53 ` Arjan van de Ven
2011-12-22 8:53 ` [linux-pm] " Arjan van de Ven
2011-12-22 8:53 ` Arjan van de Ven
2011-12-22 9:30 ` Shilimkar, Santosh
2011-12-22 9:30 ` [linux-pm] " Shilimkar, Santosh
2011-12-22 9:30 ` Shilimkar, Santosh
2011-12-22 21:20 ` Colin Cross
[not found] ` <4EF2F01E.8060307-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2011-12-22 21:20 ` [linux-pm] " Colin Cross
2011-12-22 21:20 ` Colin Cross
2011-12-22 21:20 ` Colin Cross
2011-12-22 8:35 ` Shilimkar, Santosh
2011-12-21 19:36 ` Arjan van de Ven
[not found] ` <4EF1CD49.9020800-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2012-03-14 0:39 ` Colin Cross
2012-03-14 0:39 ` Colin Cross
2012-03-14 0:39 ` Colin Cross
2011-12-21 9:55 ` Colin Cross
2011-12-21 9:40 ` Colin Cross
2012-01-04 0:41 ` Kevin Hilman
2012-01-04 0:41 ` Kevin Hilman
2012-01-04 0:41 ` Kevin Hilman
2012-01-04 17:27 ` Shilimkar, Santosh
2012-01-04 17:27 ` Shilimkar, Santosh
2012-01-04 17:27 ` Shilimkar, Santosh
2012-01-20 8:46 ` Daniel Lezcano
2012-01-20 8:46 ` Daniel Lezcano
2012-01-20 8:46 ` Daniel Lezcano
2012-01-20 20:40 ` Colin Cross
2012-01-20 20:40 ` Colin Cross
2012-01-20 20:40 ` Colin Cross
2012-01-25 14:04 ` Daniel Lezcano
2012-01-25 14:04 ` Daniel Lezcano
2012-01-31 14:13 ` Daniel Lezcano
2012-01-31 14:13 ` Daniel Lezcano
[not found] ` <CAMbhsRTbVqV6p0py9NGZrpFPf2yvp-B0dr+o-m7qbdja_-Lfzw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-27 8:54 ` [linux-pm] " Vincent Guittot
2012-01-27 8:54 ` Vincent Guittot
2012-01-27 8:54 ` Vincent Guittot
2012-01-27 17:32 ` Colin Cross
2012-01-27 17:32 ` Colin Cross
2012-01-27 17:32 ` Colin Cross
[not found] ` <CAMbhsRQYVXTZ2pX4mBrM6=SyGTqn_GY8xsW4rt_e21zerEzctA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-02-01 12:13 ` Vincent Guittot
2012-02-01 12:13 ` Vincent Guittot
2012-02-01 12:13 ` Vincent Guittot
2012-02-01 14:59 ` Lorenzo Pieralisi
2012-02-01 14:59 ` [linux-pm] " Lorenzo Pieralisi
2012-02-01 14:59 ` Lorenzo Pieralisi
2012-02-01 17:30 ` Colin Cross
2012-02-01 17:30 ` Colin Cross
2012-02-01 17:30 ` Colin Cross
2012-02-01 18:07 ` Lorenzo Pieralisi
2012-02-01 18:07 ` [linux-pm] " Lorenzo Pieralisi
2012-02-01 18:07 ` Lorenzo Pieralisi
2012-02-03 1:19 ` Colin Cross
2012-02-03 1:19 ` [linux-pm] " Colin Cross
2012-02-03 1:19 ` Colin Cross
2012-03-13 23:52 ` Kevin Hilman
2012-03-13 23:52 ` Kevin Hilman
[not found] ` <8762e8kqi6.fsf-l0cyMroinI0@public.gmane.org>
2012-03-14 0:28 ` Colin Cross
2012-03-14 0:28 ` Colin Cross
2012-03-14 0:28 ` Colin Cross
2012-03-14 0:47 ` Colin Cross
2012-03-14 0:47 ` Colin Cross
2012-03-14 0:47 ` Colin Cross
[not found] ` <CAMbhsRRD2bdkcUZvScb-cF05e=R3h69bNVaTPFX4jBKBBOjuMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-14 14:23 ` [linux-pm] " Kevin Hilman
2012-03-14 14:23 ` Kevin Hilman
2012-03-14 14:23 ` Kevin Hilman
2012-03-14 2:04 ` Arjan van de Ven
2012-03-14 2:04 ` Arjan van de Ven
2012-03-14 2:04 ` Arjan van de Ven
2012-03-14 2:21 ` Colin Cross
2012-03-14 2:21 ` Colin Cross
2012-03-14 2:21 ` Colin Cross
2011-12-21 0:09 Colin Cross
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=CAMbhsRSPCo9MSGp57Fv0sRdYUFcdwx8jEz1-CfX8LdKf8X4MVg@mail.gmail.com \
--to=ccross@android.com \
--cc=amit.kucheria@linaro.org \
--cc=arjan@linux.intel.com \
--cc=khilman@ti.com \
--cc=len.brown@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linux-tegra@vger.kernel.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.