linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Colin Cross <ccross@android.com>, 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: Thu, 22 Dec 2011 15:00:34 +0530	[thread overview]
Message-ID: <CAMQu2gxq26=pNA3L8aXUbLR4ZAT5RqyNawtm2qsPVc5cJCdOLg@mail.gmail.com> (raw)
In-Reply-To: <4EF2F01E.8060307@linux.intel.com>

On Thu, Dec 22, 2011 at 2:23 PM, Arjan van de Ven <arjan@linux.intel.com> wrote:
> On 12/22/2011 9:35 AM, Shilimkar, Santosh wrote:
>
>> Indeed. The SOCs, Arch's which does support low power
>> state independently and doesn't need any co-ordination between CPU's
>> will continue to work same way as before with this series.
>
> btw I think you misunderstand; I don't object to a need for something
> like this,
I did. Thanks for clarification.

> I am just very concerned that this may not be possible to be
> done in a race-free way.
>
I agree to those races but may be they are harmless.
Also the safe state need not be just WFI and can be bit deeper
where the co-ordination between isn't necessary. So that should
still not burn the power that much.

For simplicity let's assume a two CPU scenario.
Ideal scenario:
CPU 1 has entered idle and incremented counter for the
co-ordinated C state. CPU0 also enter and increments the
counter and now the subsystem and interconnect can go
down along with CPU cluster.

Few of the race conditions will possibly lead to void
the above conditions  and in that case the counter would
reflect that and such a C-state won't be attempted and
a safe C-state would be attempted. That should still work
fine.

Some how this hardware/security restriction is bit stupid
and likely going against the existing CPUIDLE design
which expect that a CPUIDLE thread are per CPU and it should
be independent and local to that CPU.

Regards
Santosh

  reply	other threads:[~2011-12-22  9:30 UTC|newest]

Thread overview: 36+ 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 ` [PATCH 1/3] cpuidle: refactor out cpuidle_enter_state Colin Cross
2012-01-04 14:08   ` [linux-pm] " Jean Pihet
2011-12-21  0:09 ` [PATCH 2/3] cpuidle: fix error handling in __cpuidle_register_device Colin Cross
2011-12-21  0:09 ` [PATCH 3/3] cpuidle: add support for states that affect multiple cpus Colin Cross
2011-12-21  9:02 ` [PATCH 0/3] coupled cpuidle state support Arjan van de Ven
2011-12-21  9:40   ` Colin Cross
2011-12-21  9:44     ` Arjan van de Ven
2011-12-21  9:55       ` Colin Cross
2011-12-21 12:12         ` Arjan van de Ven
2011-12-21 19:05           ` Colin Cross
2011-12-21 19:36             ` Arjan van de Ven
2011-12-21 19:42               ` [linux-pm] " Colin Cross
2011-12-22  8:35                 ` Shilimkar, Santosh
2011-12-22  8:53                   ` Arjan van de Ven
2011-12-22  9:30                     ` Shilimkar, Santosh [this message]
2011-12-22 21:20                     ` Colin Cross
2012-03-14  0:39           ` Colin Cross
2012-01-04  0:41 ` Kevin Hilman
2012-01-04 17:27   ` Shilimkar, Santosh
2012-01-20  8:46 ` Daniel Lezcano
2012-01-20 20:40   ` Colin Cross
2012-01-25 14:04     ` Daniel Lezcano
2012-01-31 14:13       ` Daniel Lezcano
2012-01-27  8:54     ` [linux-pm] " Vincent Guittot
2012-01-27 17:32       ` Colin Cross
2012-02-01 12:13         ` Vincent Guittot
2012-02-01 14:59           ` Lorenzo Pieralisi
2012-02-01 17:30             ` Colin Cross
2012-02-01 18:07               ` Lorenzo Pieralisi
2012-02-03  1:19                 ` Colin Cross
     [not found]   ` <8762e8kqi6.fsf@ti.com>
2012-03-14  0:28     ` Colin Cross
2012-03-14  0:47       ` Colin Cross
2012-03-14 14:23         ` [linux-pm] " Kevin Hilman
2012-03-14  2:04     ` Arjan van de Ven
2012-03-14  2:21       ` 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='CAMQu2gxq26=pNA3L8aXUbLR4ZAT5RqyNawtm2qsPVc5cJCdOLg@mail.gmail.com' \
    --to=santosh.shilimkar@ti.com \
    --cc=amit.kucheria@linaro.org \
    --cc=arjan@linux.intel.com \
    --cc=ccross@android.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).