All of lore.kernel.org
 help / color / mirror / Atom feed
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/7] Add common cpuidle code for consolidation.
Date: Tue, 24 Jan 2012 16:41:11 -0800	[thread overview]
Message-ID: <87ehuohavs.fsf@ti.com> (raw)
In-Reply-To: <20120124201749.GC1135@opensource.wolfsonmicro.com> (Mark Brown's message of "Tue, 24 Jan 2012 20:17:49 +0000")

Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> On Tue, Jan 24, 2012 at 12:08:08PM -0800, Kevin Hilman wrote:
>> Robert Lee <rob.lee@linaro.org> writes:
>
>> > Besides just code consolidation, a
>> > default "WFI" state is now used with default parameters that different from your
>> > original paramenters. The assumption is that if you have a WFI only idle state,
>> > the parameters in the new default WFI are more realistic as a true WFI only
>> > hardware state incurs minimal latency(<1us) or power penalty to enter and exit.
>
>> > If your platform actually performs other platform specific functionality upon
>> > entering WFI and the default parameters do not accurately reflect the 
>> > exit_latency and target_residency given in the common default state, please
>> > say so.  
>
>> I'm not sure what you mean by "WFI only".  On OMAP, WFI is the entry
>> point for all the idle states, with varying latencies.  The latencies
>> are then dependent on how the states are programmed for the various
>> power domains.  Upon WFI, the hardware then takes over puts the
>> powerdomains to their programmed states.   
>
> The default state in the patches is set up with parameters for a state
> that literally only does the WFI and has no other hardware actions taken
> adding latencies.  I asked for this because the existing drivers for
> most of the SoCs out there currently only support that basic idle state
> and when doing something more complex (which most of the SoCs actually
> can do in hardware) it's still likely to get used during bringup of the
> feature.
>
> If there's varying levels of idle state then the SoC specific code would
> need to enumerate them and their varying latencies so that the core can
> figure out which one to enter.  This isn't a problem, it's a good thing,
> but most SoCs haven't got so far as to need it yet.

OK, makes sense now.

I see now that that default is easily overridden by platform-specific
drivers, so I don't have any problem with it.

Kevin

  reply	other threads:[~2012-01-25  0:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-24  4:37 [PATCH v3 0/7] Add common cpuidle code for consolidation Robert Lee
2012-01-24  4:37 ` [PATCH v3 1/7] cpuidle: Add common init interface and idle functionality Robert Lee
2012-01-24 14:36   ` Rob Herring
2012-01-24 22:43     ` Rob Lee
2012-01-24 20:16   ` Kevin Hilman
2012-01-24 23:10     ` Rob Lee
2012-01-24 23:46   ` Turquette, Mike
2012-01-25  2:03     ` Rob Lee
2012-01-24 23:49   ` Daniel Lezcano
2012-01-25  2:38     ` Rob Lee
2012-01-25 14:52       ` Daniel Lezcano
2012-01-24  4:37 ` [PATCH v3 2/7] ARM: exynos: Modify to use new common cpuidle code Robert Lee
2012-01-29  4:47   ` Barry Song
2012-01-24  4:37 ` [PATCH v3 3/7] ARM: shmobile: " Robert Lee
2012-01-24  4:37 ` [PATCH v3 4/7] ARM: kirkwood: " Robert Lee
2012-01-24  4:37 ` [PATCH v3 5/7] ARM: davinci: " Robert Lee
2012-01-24  4:37 ` [PATCH v3 6/7] ARM: imx: Init imx5 gpc_dvfs clock for global use Robert Lee
2012-01-24  4:37 ` [PATCH v3 7/7] ARM: imx: Add imx5 cpuidle implementation Robert Lee
2012-01-24 20:08 ` [PATCH v3 0/7] Add common cpuidle code for consolidation Kevin Hilman
2012-01-24 20:17   ` Mark Brown
2012-01-25  0:41     ` Kevin Hilman [this message]
2012-01-25  0:46   ` Rob Lee
2012-01-25 18:58     ` Kevin Hilman
2012-01-29 15:34       ` Russell King - ARM Linux
2012-01-31  3:02         ` Rob Lee
2012-01-31 21:55           ` Kevin Hilman

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=87ehuohavs.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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.