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].

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]]

[[File:OMAP_PM_today.png|320px|thumb|right]]

+

-->

+

=== Current version ===

=== Current version ===

Line 29:

Line 30:

* [http://www.kwikbyte.com/KBOC.html KwikByte KBOC]

* [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.

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

Line 158:

Line 160:

# cat /debug/pm_debug/registers/2

# cat /debug/pm_debug/registers/2

+

-->

==== UART wakeup and timeout options ====

==== UART wakeup and timeout options ====

Line 173:

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.

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.

−

==== Misc. options ====

<!--

<!--

Line 199:

Line 201:

<!--

<!--

−

=== PM code in Mainline ===

−

−

Here's a very crude outline of my plans for getting PM branch code to mainline. Unless otherwise stated, this has only been tested on OMAP3, although some care has been taken to not break OMAP2 in the process.

NOTE: It is very important that an interrupt handler be configured for the GPIO IRQ, even if it does nothing but return IRQ_HANDLED. This is because without an interrupt handler, the GPIO IRQ event will never be properly cleared and this can prevent the GPIO module from hitting retention or off on the next idle request (c.f. omap34xx TRM Sec. 25.5.3.1).

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.

UART wakeup and timeout options

By default, each of the on-chip OMAP UARTs are enabled as wakeup sources. In addition, they are configured with a configurable inactivity timer (default 5 seconds) after which the UART clocks are allowed to be gated during idle or suspend.

For example, to disable the wakeup capability of a UART1 (a.k.a ttyO0)

And to change the inactivity timer to 10 seconds, instead of the default 5:

# echo 10 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout

Note that you can cat these files under /sys as well to see the current values.

UART PM Debugging Techniques

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.

Public Power management test framework

Some commonly used power management utilities are listed here which make sense from an OMAP perspective