linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jean.pihet@newoldbits.com (Jean Pihet)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/8] ARM: OMAP3: update cpuidle latency and threshold figures
Date: Tue, 18 Sep 2012 10:52:09 +0200	[thread overview]
Message-ID: <1347958332-2205-6-git-send-email-j-pihet@ti.com> (raw)
In-Reply-To: <1347958332-2205-1-git-send-email-j-pihet@ti.com>

Update the data from the measurements performed at HW and SW levels.

Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers coming from.

ToDo:
- Measure the wake-up latencies for all power domains for OMAP3
- Correct some numbers when sys_clkreq and sys_offmode are supported

Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
---
 arch/arm/mach-omap2/cpuidle34xx.c |   54 ++++++++++++++++++++++++++----------
 1 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index ca6cb71..c086374 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -280,63 +280,87 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
  *
  * - target_residency: required amount of time in the C state
  *  to break even on energy cost
+ *
+ * The MPU latency and threshold values for the C-states are the worst case
+ * values from the HW and SW, as described in details at
+ * http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#cpuidle_results
+ *
+ * Measurements conditions and remarks:
+ *  . the measurements have been performed at OPP50
+ *  . the sys_offmode signal is not supported and so not used for the
+ *    measurements. Instead the latency and threshold values for C9 are
+ *    corrected with the value for Triton 2, which is 11.5ms
+ *  . the sys_clkreq signal is not used and so a correction is needed - TBD
+ *  . the sys_clkoff signal is supported, this value need to be corrected with
+ *    the correct value of SYSCLK on/off timings (1ms for sysclk on, 2.5ms
+ *    for sysclk off)
+ *  . the setup time of DPLLs is included in the measured values. However
+ *    this is only valid for DPLLs that are enabled to auto-idle at
+ *    measurement time. There currently is no provision for the dynamic
+ *    nature of the auto-idle setting
+ *  . in order to force the cpuidle algorithm to chose the power efficient
+ *    C-states (C1, C3, C5, C7) in preference, the other C-states have a
+ *    threshold value equal to the next power efficient C-state
+ *
+ * The latency and threshold values can be overriden by data from the board
+ * files, using omap3_pm_init_cpuidle.
  */
 struct cpuidle_driver omap3_idle_driver = {
 	.name = 	"omap3_idle",
 	.owner = 	THIS_MODULE,
 	.states = {
 		{
-			.enter		  = omap3_enter_idle_bm,
-			.exit_latency	  = 2 + 2,
-			.target_residency = 5,
+			.enter		  = omap3_enter_idle,
+			.exit_latency	  = 73 + 78,
+			.target_residency = 152,
 			.flags		  = CPUIDLE_FLAG_TIME_VALID,
 			.name		  = "C1",
 			.desc		  = "MPU ON + CORE ON",
 		},
 		{
 			.enter		  = omap3_enter_idle_bm,
-			.exit_latency	  = 10 + 10,
-			.target_residency = 30,
+			.exit_latency	  = 165 + 88,
+			.target_residency = 345,
 			.flags		  = CPUIDLE_FLAG_TIME_VALID,
 			.name		  = "C2",
 			.desc		  = "MPU ON + CORE ON",
 		},
 		{
 			.enter		  = omap3_enter_idle_bm,
-			.exit_latency	  = 50 + 50,
-			.target_residency = 300,
+			.exit_latency	  = 163 + 182,
+			.target_residency = 345,
 			.flags		  = CPUIDLE_FLAG_TIME_VALID,
 			.name		  = "C3",
 			.desc		  = "MPU RET + CORE ON",
 		},
 		{
 			.enter		  = omap3_enter_idle_bm,
-			.exit_latency	  = 1500 + 1800,
-			.target_residency = 4000,
+			.exit_latency	  = 2852 + 605,
+			.target_residency = 150000,
 			.flags		  = CPUIDLE_FLAG_TIME_VALID,
 			.name		  = "C4",
 			.desc		  = "MPU OFF + CORE ON",
 		},
 		{
 			.enter		  = omap3_enter_idle_bm,
-			.exit_latency	  = 2500 + 7500,
-			.target_residency = 12000,
+			.exit_latency	  = 800 + 366,
+			.target_residency = 2120,
 			.flags		  = CPUIDLE_FLAG_TIME_VALID,
 			.name		  = "C5",
 			.desc		  = "MPU RET + CORE RET",
 		},
 		{
 			.enter		  = omap3_enter_idle_bm,
-			.exit_latency	  = 3000 + 8500,
-			.target_residency = 15000,
+			.exit_latency	  = 4080 + 801,
+			.target_residency = 215000,
 			.flags		  = CPUIDLE_FLAG_TIME_VALID,
 			.name		  = "C6",
 			.desc		  = "MPU OFF + CORE RET",
 		},
 		{
 			.enter		  = omap3_enter_idle_bm,
-			.exit_latency	  = 10000 + 30000,
-			.target_residency = 30000,
+			.exit_latency	  = 4300 + 13000,
+			.target_residency = 215000,
 			.flags		  = CPUIDLE_FLAG_TIME_VALID,
 			.name		  = "C7",
 			.desc		  = "MPU OFF + CORE OFF",
-- 
1.7.7.6

  parent reply	other threads:[~2012-09-18  8:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-18  8:52 [PATCH v9 0/8] PM QoS: implement the OMAP low level constraints management code Jean Pihet
2012-09-18  8:52 ` [PATCH 1/8] ARM: OMAP2+: PM QoS: control the power domains next state from the constraints Jean Pihet
2012-12-11  0:05   ` Paul Walmsley
2012-12-14 15:50     ` Jean Pihet
2012-09-18  8:52 ` [PATCH 2/8] ARM: OMAP2+: hwmod: manage the wake-up latency constraints Jean Pihet
2012-09-18  8:52 ` [PATCH 3/8] ARM: OMAP: omap_device: register to the per-device PM QoS framework Jean Pihet
2012-09-18  8:52 ` [PATCH 4/8] ARM: OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints Jean Pihet
2012-09-18  8:52 ` Jean Pihet [this message]
2012-09-18  8:52 ` [PATCH 6/8] ARM: OMAP3: powerdomain data: add wake-up latency figures Jean Pihet
2012-09-18  8:52 ` [PATCH 7/8] ARM: OMAP: convert I2C driver to PM QoS for latency constraints Jean Pihet
2012-09-18  8:53   ` Felipe Balbi
2012-09-19 18:11   ` Shubhrajyoti
2012-09-19 18:34     ` Jean Pihet
2012-09-18  8:52 ` [PATCH 8/8] ARM: OMAP: PM: remove the latency related functions from the API Jean Pihet

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=1347958332-2205-6-git-send-email-j-pihet@ti.com \
    --to=jean.pihet@newoldbits.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 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).