Power Management 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. ACPI Information 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. ACPI States 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 (Operating System) 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 (Operating System) 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 (Operating System) 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 (Operating System) 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. Hardware support The Blackfin processor provides several 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: RESET Mode (INITIAL state, BF60x only) - RESET is the initial state of the processor and is the result of a hardware or software triggered event. Entering RESET is not triggered by the DPM itself, but by the external SYS_HWRST pin or by the RCU. Full On Mode (Maximum Performance) - In the full on mode, the PLL (Phase Locked Loop) 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 (Phase Locked Loop) is enabled, but bypassed. Because the PLL (Phase Locked Loop) is bypassed, the processor’s core clock (CCLK (Core Clock)) and system clock (SCLK (System Clock)) 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 (Direct Memory Access) access is available to appropriately configured L1 memories. In the active mode, it is possible to disable the PLL (Phase Locked Loop) to save more power. ACTIVE with PLL (Phase Locked Loop) Disabled (DISALBE PLL (Phase Locked Loop), BF60x only) - In ACTIVE with PLL (Phase Locked Loop) Disabled power is reduced on the VDD_INT domain (compared to ACTIVE) by disabling the PLL (Phase Locked Loop) in addition to running all units at the at the SYS_CLKIN frequency. The processor is fully functional. Sleep Mode (High Power Savings, BF5xx only) - The sleep mode reduces power dissipation by disabling the clock to the processor core (CCLK (Core Clock)). The PLL (Phase Locked Loop) and system clock (SCLK (System Clock)), however, continue to operate in this mode. Typically an external event or RTC (Real Time Clock) activity will wake up the processor. When in the sleep mode, system DMA (Direct Memory Access) 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 (Core Clock) and SCLK (System Clock)). Asynchronous systems, such as the RTC (Real Time Clock), 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 (Real Time Clock). 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 (Real Time Clock) event, assertion of the RESET pin, external GPIO (General Purpose Input/Output) event 1), or activity on the Ethernet PHY (Ethernet PHYceiver) or CAN (Controller Area Network - common automotive serial bus) 2), USB (Universal Serial Bus) 3), Rotary 4), Keypad 5), etc 6). where applicable. Since the core is powered down and SCLK (System Clock) 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 (Real Time Clock)). Not all hardware states are available in the Linux kernel. Besides the Power Management States there is also Support for CPU frequency and Voltage Scaling While adding Suspend-MEM support we found that a fewBlackfin EZKIT/STAMP development boardslostSDRAM (synchronous dynamic random access memory (system memory))data integrity after entering Hibernate Mode. We found some heavy Over- and Undershoot on theSDRAM (synchronous dynamic random access memory (system memory))SCKE Strobepreventing the SDRAM (synchronous dynamic random access memory (system memory)) to enter Self Refresh properly. Failing Boards: Board, Status BF537-EZKit Rev 1.3 Silicon Rev. 0.2 (Ser# 557684) , Failed BF537-EZKit Rev 2.2 Silicon Rev. 0.3 (Ser# 570385) , Failed BF537-EZKit Rev 2.2 Silicon Rev. 0.3 (Ser# 570380) , Failed BF537-STAMP Rev 1.3 Silicon Rev. 0.2 (Ser# 556262) , Failed A simple hardware workaround on the SCKE Strobe made the issue go away: Add a 6.8k Ohm resistor between SCKE (J2-81) and GND (J2-87). Supported Power Management States 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. Enabling Power Management Support 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 Wakeup Source BF5xx wake up setting There are two different options controlling the Wakeup Cause Wakeup Event by Interrupt 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 (System Interrupt Controller)_IWR). If a peripheral interrupt source is enabled in SIC (System Interrupt Controller)_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 (Application Programming Interface) 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) int enable_irq_wake(unsigned int irq) 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 Cause Wakeup Event by GPIO This option adds some extra code that allows specifying any Blackfin GPIO (General Purpose Input/Output) to be configured as Wakeup Strobe. There is an alternative Blackfin specific API (Application Programming Interface) for GPIO (General Purpose Input/Output) wakeups: This API (Application Programming Interface) allows GPIO (General Purpose Input/Output) wakeups without using the Linux interrupt API (Application Programming Interface). 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); ThisAPI (Application Programming Interface)was removed before the Blackfin Linux:2010R1 Release BF60x wake up setting The table below shows the HIBERNATE and DEEP SLEEP wake-up sources for the BF60x. DPM_WAKE_EN,DPM_WAKE_POL,&DPM_WAKE_STAT Bit, Assigned Source, DEEP SLEEP?, HIBERNATE? WS0 , PA_15 , Yes , Yes WS1 , PB_15 , Yes , Yes WS2 , PC_15 , Yes , Yes WS3 , PD_06 (ETH0_PHYINT) , Yes , Yes WS4 , PE_12 (ETH1_PHYINT) , Yes , Yes WS5 , PG_04 (CAN0_RX) , Yes , Yes WS6 , PG_13 , Yes , Yes WS7 , USB (Universal Serial Bus) , No , Yes WS30:WS8 , RESERVED , NA , NA Enable BF60x wakeup source & configure wakeup polarity [*] Suspend to RAM and standby │ │ │ │ [ ] Run-time PM core functionality │ │ │ │ [ ] Power Management Debug Support │ │ │ │ *** Possible Suspend Mem / Hibernate Wake-Up Sources *** │ │ │ │ [ ] Allow Wake-Up from PA15 │ │ │ │ [ ] Allow Wake-Up from PB15 │ │ │ │ [ ] Allow Wake-Up from PC15 │ │ │ │ [ ] Allow Wake-Up from PD06(ETH0_PHYINT) │ │ │ │ [*] Allow Wake-Up from PE12(ETH1_PHYINT, PUSH BUTTON) │ │ │ │ (1) Wake-up priority │ │ │ │ [ ] Allow Wake-Up from PG04(CAN0_RX) │ │ │ │ [ ] Allow Wake-Up from PG13 │ │ │ │ [ ] Allow Wake-Up from (USB) │ │ Power Management Interface 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: Mode , Description standby , Blackfin sleep or sleep_deeper mem , Blackfin Hibernate Suspend-to-Mem disk , NOT AVAILABLE 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. Putting the system into Standby from Command Line root:~>echo standby > /sys/power/stateSyncing 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:~> Putting the system into Standby using Busybox rtcwake tool The RTC (Real Time Clock) wake up tool applies only to BF5xx chips that have the RTC (Real Time Clock) peripheral. RTC Wakeup in 10 Seconds root:/>rtcwake -s 10 -m standbywakeup 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:/> Putting the system into Suspend Mem from Command Line root:~>echo mem > /sys/power/stateSyncing 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:~> Putting the system into Suspend Mem using Busybox rtcwake tool The RTC (Real Time Clock) wake up tool applies only to BF5xx chips that have the RTC (Real Time Clock) peripheral. RTC Wakeup in 10 Seconds root:/>rtcwake -s 10 -m memwakeup 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:/> Writing to /sys/power/state from User Applications #include #include #include #include #include #include #include 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; } POWER Wake up times The power wake up times are different among Linux system core driver, Linux generic peripheral driver and Linux application. In 2012R1 Linux distribution for BF60X: Component , hibernate to memory , standby(sleep) Linux system core driver , < 3ms , < 1ms Linux peripheral driver , 3ms ~ 14ms , 1ms ~ 12ms Linux application , > 51ms , > 49ms POWER DISSIPATION/CONSUMPTION Many operating conditions can affect power dissipation/consumption. System designers should refer to Estimating Power for ADSP (Analog Digital Signal Processor)-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 Power Management Operating Modes The Standby/sleep mode reduces dynamic power dissipation by disabling the clock to the processor core (CCLK (Core Clock)). 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 (Phase Locked Loop) and system clock (SCLK (System Clock)) continue to operate at a very low frequency of about 3.3 MHz (Megahertz). To preserve data integrity in the SDRAM (synchronous dynamic random access memory (system memory)), the SDRAM (synchronous dynamic random access memory (system memory)) is put into Self Refresh Mode. Typically an external event such as GPIO (General Purpose Input/Output) interrupt or RTC (Real Time Clock) activity wakes up the processor. Measurements shown in the chart are typical values and may vary. Test platform was a BF537-STAMP running linux-2.6.24.7-ADI (Analog Devices, Inc.)-2008R2-pre-svn5073 IO (External) Current and Voltage has been measured across R148. Core (Internal) Current and Voltage has been measured across R61. Many operating conditions can affect power dissipation. System designers should refer to EE-297: Estimating Power for theADSP (Analog Digital Signal Processor)-BF534/BF536/BF537 Blackfin Processors.” This document will provide detailed information for optimizing your design for lowest power. 1) 2) 3) 4) 5) 6) depends on the Blackfin - check your HRM ((Blackfin) Hardware Reference Manual)