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
next prev parent 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$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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