OMAP Power Management - Revision history

Mysli at 19:20, 13 May 2012

2012-05-13T19:20:06Z

Khilman at 21:50, 17 November 2011

2011-11-17T21:50:54Z

Khilman at 21:48, 17 November 2011

2011-11-17T21:48:24Z

Cschalle: Add category

2011-10-27T21:46:35Z

Add category

Girish Ghongdemath: /* Debug info */

2011-06-17T01:26:51Z

‎Debug info

Khilman: /* Using the PM branch */

2011-05-23T14:05:44Z

‎Using the PM branch

Khilman: /* Using the PM branch */

2011-05-23T14:01:01Z

‎Using the PM branch

Khilman at 15:43, 21 March 2011

2011-03-21T15:43:45Z

Show changes

Nmenon: /* Quick verification of suspend-resume functionality */

2010-12-17T16:33:01Z

‎Quick verification of suspend-resume functionality

Nmenon: /* Maemo pm_test */

2010-12-17T16:32:32Z

‎Maemo pm_test

Show changes

← Older revision		Revision as of 19:20, 13 May 2012
Line 461:		Line 461:

	[[Category:OMAP]]		[[Category:OMAP]]
		+	[[Category:Power Management]]

@@ Line 13: / Line 13: @@
 The latest, tested PM branch is available as a branch named [http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=pm 'pm'] from the [http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git linux-omap-pm repository].  This branch is also sync'd daily as the 'pm' branch of the [http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git main linux-omap repository].
+<!--
 [[File:OMAP_PM_today.png|320px|thumb|right]]
 === Current version ===
@@ Line 174: / Line 176: @@
 Debugging problems with the OMAP UART driver wakeup and data transfer when Power Management is enabled can be quite tedious, if one does not have a proper HW setup. An example of a setup (including both HW and SW changes) can be found in the [[OMAP_UART_pm_debugging]] page.
 <!--
@@ Line 200: / Line 201: @@
 <!--
 [[File:OMAP_PM_future.png|320px|thumb|right]]
@@ Line 246: / Line 241: @@
 * Current status
 ** Propsed runtime PM implementation for OMAP available in <tt>pm-wip/runtime</tt> branch of Kevin's [http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git linux-omap-pm repository].
 === Public Power management test framework ===

@@ Line 9: / Line 9: @@
 * full-chip OFF in idle and suspend
 * idle PM via CPUidle
-* [dropped for re-architecture] active PM via DVFS using CPUfreq
+* support for multiple OMAP3/4 boards
 * support for multiple OMAP3 boards
 The latest, tested PM branch is available as a branch named [http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=pm 'pm'] from the [http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git linux-omap-pm repository].  This branch is also sync'd daily as the 'pm' branch of the [http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git main linux-omap repository].
@@ Line 29: / Line 28: @@
 * [http://www.kwikbyte.com/KBOC.html KwikByte KBOC]
-=== What makes up the PM branch? ===
+=== Using OMAP PM ===
-−
-The PM branch is actually a collection of sub branches for the various features that are being worked on.
-−
-==== pm-core ====
-−
-The <tt>pm-core</tt> branch contains features/patches that are "ready", meaning they have been either already merged, awaiting merge, or basically done, but awaiting final approval.
-−
-* <tt>pm-backports</tt>: backports from already merged or queued upstream development needed for PM (Kevin)
-* <tt>pm-fixes</tt>: PM relates fixes queued for the next -rc series;  (Kevin: queued for Tony)
-* <tt>pm-misc</tt>: misc. PM patches being queued for next merge window (Kevin: queued for Tony)
-−
-==== Work-in-Progress (WIP) ====
-* <tt>pm-cpufreq</tt>: base CPUfreq driver for OMAP (Kevin)
-* <tt>pm-gpio</tt>: GPIO off-mode support: needs rework on top of GPIO hwmod conversion (Kevin, obsoleted)
-* <tt>pm-t2</tt>: T2/PMIC board support: needs rework after voltage layter (Kevin, obsoleted)
-* <tt>pm-debug</tt>: misc. PM debug patches (Kevin)
-−
-=== Using the PM branch ===
 ==== Features ====
@@ Line 58: / Line 39: @@
 Serial console activity or other configured wakeup sources (keypad, touchscreen) will trigger resume.
 Upon resume, you can use the powerdomain state statistics to check whether all states hit the desired state, cf. 'Debug info'
@@ Line 66: / Line 44: @@
   # cat /debug/pm_debug/count
-In addition, if any powerdomains did not hit the desired state, you will see a message on the console.
+In addition, if any power domains did not hit the desired state, you will see a message on the console.
 ===== Enabling system for hitting retention during idle =====
-By default, the kernel will not try to hit retention or off while idle.  To enable idle path to attempt
+By default, the UARTs will not automatically idle when unused so they will prevent low-power states during idle.  To enable UART idle timeouts with a 5 second timeout:
-deeper sleep states:
-  # echo 1 > /debug/pm_debug/sleep_while_idle
+  # echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
 Then, wait for any inactivity timers to expire (such as the 5 second UART timer) and check the powerdomain transition statistics
@@ Line 82: / Line 64: @@
 ===== Enabling system for hitting OFF =====
-By default, retention is the deepest sleep state attempted.  To enable powerdomain transitions to off mode
+By default, retention is the deepest sleep state attempted.  To enable power domain transitions to off mode
   # echo 1 > /debug/pm_debug/enable_off_mode
-Once again, after a suspend or after some idle time, use the powerdomain transition stats to check that
+Once again, after a suspend or after some idle time, use the power domain transition stats to check that
 transitions to off-mode are happening
@@ Line 118: / Line 100: @@
 ** Fix: enable the wakeup feature for the tty used as console:
    # echo enabled > /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup
-* Root filesystem on MMC leads to crash when using off-mode.
-** There is currently no support for off-mode in the MMC driver.
-−
 * GPIO module-level wakeups not always working
 ** Background: GPIO wakeups can happen either via the GPIO module itself (module-level wakeups) or via IO pad wakeups if the CORE powerdomain is inactive, in retention or off.
@@ Line 145: / Line 125: @@
   # cat /debug/pm_debug/count
-This will look something like this:
+This will look something like this on OMAP3:
    # cat /debug/pm_debug/count
@@ Line 166: / Line 146: @@
 it hits low power state. In the above example, cam_pwrdm (camera power domain) has hit OFF state once. GFX power domain has hit OFF state twice and like wise.
 Dump current PRCM registers
@@ Line 177: / Line 158: @@
   # cat /debug/pm_debug/registers/2
 ==== UART wakeup and timeout options ====

← Older revision		Revision as of 21:46, 27 October 2011
Line 481:		Line 481:
	# Print test summary		# Print test summary
	echo -e "$NR"		echo -e "$NR"
		+
		+	[[Category:OMAP]]

← Older revision		Revision as of 01:26, 17 June 2011
Line 144:		Line 144:

	# cat /debug/pm_debug/count		# cat /debug/pm_debug/count
		+
		+	This will look something like this:
		+
		+	# cat /debug/pm_debug/count
		+	cefuse_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0
		+	always_on_core_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0
		+	l4per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
		+	l3init_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
		+	cam_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
		+	ivahd_pwrdm (RET),OFF:1,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
		+	mpu_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
		+	cpu1_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
		+	cpu0_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
		+	tesla_pwrdm (RET),OFF:1,RET:1,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0
		+	dss_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
		+	abe_pwrdm (ON),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
		+	gfx_pwrdm (OFF),OFF:2,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
		+	core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0,RET-MEMBANK5-OFF:0
		+
		+	If you see each power domain has counters specified. OFF, RET, INA and so on...The count basically keeps incrementing every time
		+	it hits low power state. In the above example, cam_pwrdm (camera power domain) has hit OFF state once. GFX power domain has hit OFF state twice and like wise.

	Dump current PRCM registers		Dump current PRCM registers

← Older revision		Revision as of 14:05, 23 May 2011
Line 48:		Line 48:

	=== Using the PM branch ===		=== Using the PM branch ===
−
−	~~[[File:LDS-O-khilman-Runtime-PM.pdf]]~~

	==== Features ====		==== Features ====

← Older revision		Revision as of 14:01, 23 May 2011
Line 48:		Line 48:

	=== Using the PM branch ===		=== Using the PM branch ===
		+
		+	[[File:LDS-O-khilman-Runtime-PM.pdf]]

	==== Features ====		==== Features ====

@@ Line 329: / Line 329: @@
    utility which tests that kernel and kernel modules works power management wise
 This utility could be used to sanity test the powermanagement impact to a system for suspend/restore and basic power features.
-==== Quick verification of suspend-resume functionality ====
+==== Quick verification of suspend-idle functionality ====
 the following script may be used with userspace supporting something simple as busybox:
   #!/bin/ash