Power management is a tricky thing to understand - and even harder thing to implement properly. The words and states that is used to describe the hardware is not the same as the states used to describe the software. The software/hardware interaction is normally defined by the Advanced Configuration and Power Interface (ACPI). ACPI defines common interfaces for hardware recognition, motherboard and device configuration and power management, and is supported by the Linux kernel natively.

The ACPI specification promotes the concept that systems should manage energy consumption by transitioning unused devices into lower power states including placing the entire system in a low-power state (sleeping state) when possible. A system is broken down into classes:

global states

The ACPI global system states apply to the entire system, and are visible to the user. They are working, sleeping, soft off, and mechanical off.

device states

Device power states are states of particular devices; as such, they are generally not visible to the user. For example, some devices may be in the off state even though the system as a whole is in the working state. Device states apply to any device on any bus.

processor states

This balances processor performance against power consumption and thermal states by manipulating the processor's performance controls. The ACPI specification defines a working state, labeled G0 (S0), in which the processor executes instructions. Processor sleeping states, labeled C1 through C3, are also defined. In the sleeping states, the processor executes no instructions, thus reducing power consumption and, potentially, operating temperatures. The ACPI specification also defines processor performance states, where the processor (while in C0) executes instructions, but with lower performance and (potentially) lower power consumption and operating temperature.

While the Global System is working (on), the processor can be in any number of states, from executing instructions at full rate (G0/C0/P0), to executing instructions at a reduced rate (G0/C0/P4), to waiting for interrupts to occur in a low power mode (G0/C1).

• G0 Working : A state where the system dispatches user mode (application) threads and they execute. In this state, peripheral devices (peripherals) are having their power state changed dynamically. The user can select, through some UI, various performance/power characteristics of the system to have the software optimize for performance or battery life. The system responds to external events in real time.
  • C0 Processor Power State : While the processor is in this state, it executes instructions.
    • P0 Performance State : While a processor is in this state, it uses its maximum performance capability and may consume maximum power.
    • P1 Performance State : In this performance power state, the performance capability of tje processor is limited below its maximum and consumes less than maximum power.
    • Pn Performance State : In this performance state, the performance capability of a device or processor is at its minimum level and consumes minimal power while remaining in an active state. State n is a maximum number and is processor dependent. Processors and devices may define support for an arbitrary number of performance states not to exceed 16.
  • C1 Processor Power State : This processor power state has the lowest latency. The hardware latency in this state must be low enough that the operating software does not consider the latency aspect of the state when deciding whether to use it. Aside from putting the processor in a non-executing power state, this state has no other software-visible effects.
  • C2 Processor Power State : The C2 state offers improved power savings over the C1 state. The worst-case hardware latency for this state is provided via the ACPI system firmware and the operating software can use this information to determine when the C1 state should be used instead of the C2 state. Aside from putting the processor in a non-executing power state, this state has no other software-visible effects.
  • C3 Processor Power State : The C3 state offers improved power savings over the C1 and C2 states. The worst-case hardware latency for this state is provided via the ACPI system firmware and the operating software can use this information to determine when the C2 state should be used instead of the C3 state.
• G1 Sleeping : A computer state where the computer consumes a small amount of power, user mode threads are not being executed, and the system “appears” to be off (from an end user’s perspective, the display is off, and so on). Latency for returning to the Working state varies on the wake environment selected prior to entry of this state (for example, whether the system should answer phone calls). Work can be resumed without rebooting the OS because large elements of system context are saved by the hardware and the rest by system software.Sleeping subdivides into the four states S1 through S4. The time needed to bring the system from here back into G0 Working (wake-latency time) is shortest for S1, short for S2 and S3, and not so short for S4.
  • S1 Sleeping State : The S1 sleeping state is a low wake latency sleeping state. In this state, no system context is lost (CPU or chip set) and hardware maintains all system context.
  • S2 Sleeping State : The S2 sleeping state is a low wake latency sleeping state. This state is similar to the S1 sleeping state except that the CPU and system cache context is lost (the OS is responsible for maintaining the caches and CPU context). Control starts from the processor’s reset vector after the wake event.
  • S3 Sleeping State : The S3 sleeping state is a low wake latency sleeping state where all system context is lost except system memory. CPU, cache, and chip set context are lost in this state. Hardware maintains memory context and restores some CPU and L2 configuration context. Control starts from the processor’s reset vector after the wake event.
  • S4 Sleeping State : The S4 sleeping state is the lowest power, longest wake latency sleeping state supported by ACPI. In order to reduce power to a minimum, it is assumed that the hardware platform has powered off all devices. Platform context is maintained.
• G2/S5 Soft Off : A computer state where the computer consumes a minimal amount of power. No user mode or system mode code is run. This state requires a large latency in order to return to the Working state. The system’s context will not be preserved by the hardware. The system must be restarted to return to the Working state.
• G3 Mechanical Off : A computer state that is entered and left by a mechanical means (for example, turning off the system’s power through the movement of a large red switch). Various government agencies and countries require this operating mode. It is implied by the entry of this off state through a mechanical means that no electrical current is running through the circuitry and that it can be worked on without damaging the hardware or endangering service personnel. The OS must be restarted to return to the Working state. No hardware context is retained. Except for the real-time clock, power consumption is zero.

Device states are independent of the system, and are states of particular devices. Device states apply to any device on any bus.

• D0 Fully-On : This state is assumed to be the highest level of power consumption. The device is completely active and responsive, and is expected to remember all relevant context continuously.
• D1 : The meaning of the D1 Device State is defined by each device class. Many device classes may not define D1. In general, D1 is expected to save less power and preserve more device context than D2.
• D2 : The meaning of the D2 Device State is defined by each device class. Many device classes may not define D2. In general, D2 is expected to save more power and preserve less device context than D1 or D0. Buses in D2 may cause the device to lose some context (for example, by reducing power on the bus, thus forcing the device to turn off some of its functions).
• D3 Off : Power has been fully removed from the device. The device context is lost when this state is entered, so the OS software will reinitialize the device when powering it back on. Since device context and power are lost, devices in this state do not decode their address lines. Devices in this state have the longest restore times. All classes of devices define this state.

The Blackfin processor provides five operating modes, each with different performance/power/latency profiles. In addition to overall clock management and gating clocks to each of the peripherals, the processor provides the control functions to dynamically alter the processor core supply voltage to further reduce power dissipation. The power states available to the hardware are:

• Full On Mode (Maximum Performance) - In the full on mode, the PLL is enabled, not bypassed, providing the maximum operational frequency. This is the normal execution state in which maximum performance can be achieved, and is the normal operation of the Linux kernel and userspace. The processor core and all enabled peripherals run at full speed.
• IDLE Idle state stops all processor activity at the user’s discretion, usually to conserve power during lulls in activity. No processing occurs during the Idle state. The Idle state is invoked by a sequential IDLE instruction. The processor remains in the Idle state until a peripheral or external device, generates an interrupt that requires servicing. The kernel IDLE loop is the IDLE state, as it saves power, but has zero overhead in responding to an interrupt.
• Active Mode (Moderate Power Savings) - In the active mode, the PLL is enabled, but bypassed. Because the PLL is bypassed, the processor’s core clock (CCLK) and system clock (SCLK) run at the input clock (CLKIN) frequency. In this mode, the CLKIN to VCO multiplier ratio can be changed, although the changes are not realized until the full on mode is entered. DMA access is available to appropriately configured L1 memories. In the active mode, it is possible to disable the PLL to save more power.
• Sleep Mode (High Power Savings) - The sleep mode reduces power dissipation by disabling the clock to the processor core (CCLK). The PLL and system clock (SCLK), however, continue to operate in this mode. Typically an external event or RTC activity will wake up the processor. When in the sleep mode, system DMA access to L1 memory is not supported.
• Deep Sleep Mode (Maximum Power Savings) - The deep sleep mode maximizes power savings by disabling the processor core and synchronous system clocks (CCLK and SCLK). Asynchronous systems, such as the RTC, may still be running, but cannot access internal resources or external memory. This powered-down mode can only be exited by assertion of the reset interrupt or by an asynchronous interrupt generated by the RTC.
• Hibernate State - For lowest possible power dissipation, this state allows the internal supply (VDDINT) to be powered down (only if using the internal regulator), while keeping the I/O supply (VDDEXT) running. The internal supply regulator can be woken up by several user-selectable events including a RTC event, assertion of the RESET pin, external GPIO event ¹⁾, or activity on the Ethernet PHY or CAN²⁾, USB³⁾, Rotary⁴⁾, Keypad⁵⁾, etc⁶⁾. where applicable. Since the core is powered down and SCLK is disabled, the state of all core MMRs, system MMRs, and on-chip memory is lost (with the exception of externally powered devices such as the RTC).

Not all hardware states are available in the Linux kernel.

The kernel supports three power management states generically, though each is dependent on platform support code to implement the low-level details for each state. Blackfin Linux currently offers Standby.

• State Standby - Power-On Suspend
  • String : “standby”

This state offers high power savings, while providing a very low-latency transition back to a working system. No operating state is lost (the CPU retains power), so the system easily starts up again where it left off. From a Blackfin hardware perspective - the processor is in Full On, but the Clocks are slowed down to consume almost no power.

We try to put devices in a low-power state equivalent to D1, which also offers low power savings, but low resume latency. Not all devices support D1, and those that don't are left on.

A transition from Standby to the On state should take only a few milliseconds.

Linux Kernel Configuration ->
    Power management options  ->

 [*] Power Management support
 [ ]   Legacy Power Management API (DEPRECATED)
 [ ]   Power Management Debug Support
 [*] Suspend to RAM and standby
     Standby Power Saving Mode (Sleep Deeper)  --->
 [*] Allow Wakeup from Standby by GPIO
 (2)   GPIO number
       GPIO Polarity (Active High)  --->
 --- Possible Suspend Mem / Hibernate Wake-Up Sources
 [ ] Allow Wake-Up from on-chip PHY or PH6 GP

There are two different options controlling the Wakeup

Wakeup Events:

For dynamic power management, any of the peripherals can be configured to wake up the core from its idled state to process the interrupt and resume form standby, simply by enabling the appropriate bit in the system interrupt wakeup-enable register (refer to Hardware Reference Manual SIC_IWR).

If a peripheral interrupt source is enabled in SIC_IWR and the core is idled, the interrupt causes the DPMC to initiate the core wakeup sequence in order to process the interrupt.

The linux kernel API provides these three functions to enable or disable wakeup capabilities of interrupts:

int set_irq_wake(irq, state);

int disable_irq_wake(unsigned int irq)

static inline int disable_irq_wake(unsigned int irq)
{
	return set_irq_wake(irq, 0);
}

int enable_irq_wake(unsigned int irq)

static inline int enable_irq_wake(unsigned int irq)
{
	return set_irq_wake(irq, 1);
}

Example:

Following patch enables irq wake for all gpio-keys push buttons.

Index: drivers/input/keyboard/gpio_keys.c
===================================================================
--- drivers/input/keyboard/gpio_keys.c  (revision 4154)
+++ drivers/input/keyboard/gpio_keys.c  (working copy)
@@ -100,7 +100,7 @@
                                irq, error);
                        goto fail;
                }
-
+               enable_irq_wake(irq);
                input_set_capability(input, type, button->code);
        }

In current kernel versions this feature has been added to the gpio-keys driver

This feature can be enabled by:

root:/sys/devices/platform/gpio-keys.0/power> echo enabled > wakeup

This option adds some extra code that allows specifying any Blackfin GPIO to be configured as Wakeup Strobe.

There is an alternative Blackfin specific API for GPIO wakeups:

This API allows GPIO wakeups without using the Linux interrupt API. It also allows configuring a Wakeup as EDGE or Both EDGE sensitive while the Linux kernel interrupt is configured level sensitive.

#define PM_WAKE_RISING	0x1
#define PM_WAKE_FALLING	0x2
#define PM_WAKE_HIGH	0x4
#define PM_WAKE_LOW	0x8
#define PM_WAKE_BOTH_EDGES	(PM_WAKE_RISING | PM_WAKE_FALLING)
#define PM_WAKE_IGNORE	0xF0
 
int gpio_pm_wakeup_request(unsigned gpio, unsigned char type);
void gpio_pm_wakeup_free(unsigned gpio);

The power management subsystem provides a unified sysfs interface to userspace, regardless of what architecture or platform one is running. The interface exists in /sys/power/ directory (assuming sysfs is mounted at /sys).

/sys/power/state controls system power state. Reading from this file returns what states are supported, which is hard-coded to 'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk' (Suspend-to-Disk).

Blackfin Linux supports:

Writing to this file one of those strings causes the system to transition into that state. Please see the file Documentation/power/states.txt for a description of each of those states.

root:~> echo standby > /sys/power/state
Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s)

* Wakeup Event *

Restarting tasks ... done.
root:~>

RTC Wakeup in 10 Seconds

root:/> rtcwake -s 10 -m standby
wakeup from "standby" at Thu Jan  1 01:45:31 1970
Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s)
Restarting tasks ... done.
root:/>

root:~> echo mem > /sys/power/state
Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s)

* Wakeup Event *

Restarting tasks ... done.
root:~>

RTC Wakeup in 10 Seconds

root:/> rtcwake -s 10 -m mem
wakeup from "mem" at Thu Jan  1 01:45:31 1970
Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s)
Restarting tasks ... done.
root:/>

#include <stdio.h>
#include <getopt.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
 
static void suspend_system(const char *suspend)
{
	char	buf[20];
	int	f = open("/sys/power/state", O_WRONLY);
	int	len;
	ssize_t	n;
	if (f < 0) {
		perror("open /sys/power/state");
		return;
	}
	len = sprintf(buf, "%s\n", suspend) - 1;
	len = strlen(buf);
	n = write(f, buf, len);
 
	/* this executes after wake from suspend */
	if (n < 0)
		perror("write /sys/power/state");
	else if (n != len)
		fprintf(stderr, "short write to %s\n", "/sys/power/state");
	close(f);
}
 
int main(int argc, char **argv)
{
  static char		*suspend = "standby";
 
  printf("Going into %s ...\n",suspend);
 
	  suspend_system(suspend);
 
  printf("Awakeing from %s ...\n",suspend);
 
 return 0;
}

Many operating conditions can affect power dissipation/consumption. System designers should refer to Estimating Power for ADSP-BF531/BF532/BF533 Blackfin Processors (EE-229) on the Analog Devices website (www.analog.com)

EE229 This document provides detailed information

In general:

Derived Power Consumption (PDDTOT)

* PDDTOT = PDDINT + PDDEXT + PDDRTC

Internal Power Consumption (PDDINT)

• Static and Dynamic Components
  • Static (Leakage) Is A Function Of Voltage and Operating Temperature
  • Dynamic Is A Function Of Voltage and Frequency

External Power Consumption (PDDEXT, PDDRTC)

• PDDEXT Factors Several Components
  • Voltage, Frequency, Output Pins Toggling, and Usage
  • Largely An Estimation Based On Application Run-Time Averages
  • PDDRTC Is Specified

The Standby/sleep mode reduces dynamic power dissipation by disabling the clock to the processor core (CCLK).

Furthermore, Standby/sleep_deeper sets the internal power supply voltage (VDDINT) to 0.85 V to provide the greatest power savings, while preserving the processor state.

The PLL and system clock (SCLK) continue to operate at a very low frequency of about 3.3 MHz. To preserve data integrity in the SDRAM, the SDRAM is put into Self Refresh Mode. Typically an external event such as GPIO interrupt or RTC activity wakes up the processor.