Difference between revisions of "Power management (Axel)"

From DAVE Developer's Wiki
Jump to: navigation, search
(Interrupt latency)
(Measuring power consumption)
(14 intermediate revisions by 3 users not shown)
Line 2: Line 2:
 
{{AppliesToAxel}}
 
{{AppliesToAxel}}
 
{{AppliesToAxelLite}}
 
{{AppliesToAxelLite}}
 +
{{AppliesToAxelEsatta}}
 
{{InfoBoxBottom}}
 
{{InfoBoxBottom}}
  
Line 18: Line 19:
 
</pre>
 
</pre>
 
When dynamic processor's voltage/frequency scaling is enabled, Linux kernel performs a lot of transactions between different [[FAQs_(Axel)#Q:_How_can_I_change_the_CPU_clock_frequency.3F|OPPs]]. Two approaches are available to implement such transactions:
 
When dynamic processor's voltage/frequency scaling is enabled, Linux kernel performs a lot of transactions between different [[FAQs_(Axel)#Q:_How_can_I_change_the_CPU_clock_frequency.3F|OPPs]]. Two approaches are available to implement such transactions:
* PMIC-based: in this case an external Power Management Integrated Circuit (PMIC) is used to change the processor's voltages
+
* PMIC-based: in this case an external Power Management Integrated Circuit (PMIC) is used to change processor's voltages
 
* internal LDOs-based: in this case processor's internal linear regulators are used to change such voltages.
 
* internal LDOs-based: in this case processor's internal linear regulators are used to change such voltages.
PMIC is connected to the processor via I2C bus. As such, every time a transaction is needed, several I2C packets need to be trasnmitted over I2C bus, resulting in a relatively slow overall transaction time. In case LDOs-based approach is adopted instead, transaction are quicker because LDOs configuration registers are directly accessible in the processor's address space. On the other hand, the use of LDOs has significant drawback as explained in the following section.
+
PMIC is connected to the processor via I2C bus. As such, every time a transaction is needed, several packets need to be transmitted over I2C bus, resulting in a relatively slow overall transaction time. This may lead to an increase of maximum interrupt latency. In case LDOs-based approach is adopted instead, transactions are quicker because LDOs configuration registers are directly accessible in the processor's address space. On the other hand, the use of LDOs has a significant drawback as explained in the following section.
 +
 
 +
Please note that OPP transactions may be prevented at all by manually configuring the governor in order to use a fixed OPP.
 +
 
 +
For more details please refer to [[Linux_and_interrupt_latency_(Axel)|this page]].
  
 
==Processor heating and lifetime==
 
==Processor heating and lifetime==
Use of internal LDOs increases the power dissipation on processor side significantly. As a consequence, operating junction temperature increases as well. This fact has to be taken into consideration at system integration level, as it affects directly expected processor lifetime. For more details please refer to  
+
Use of internal LDOs increases the power dissipation on processor side significantly. As a consequence, operating junction temperature increases as well. This fact has to be taken into consideration at system integration level, as it is strictly related to expected processor lifetime. For more details please refer to  
 
<ref name="AN4724">Freescale Semiconductor, Inc., ''AN4724 i.MX 6Dual/6Quad Product Lifetime Usage Estimates''</ref>
 
<ref name="AN4724">Freescale Semiconductor, Inc., ''AN4724 i.MX 6Dual/6Quad Product Lifetime Usage Estimates''</ref>
 
and
 
and
 
<ref name="AN4725">Freescale Semiconductor, Inc., ''AN4725 i.MX 6Solo/6DualLite Product Lifetime Usage Estimates''</ref>.
 
<ref name="AN4725">Freescale Semiconductor, Inc., ''AN4725 i.MX 6Solo/6DualLite Product Lifetime Usage Estimates''</ref>.
 +
 +
==Measuring power consumption==
 +
[[AxelEVB-Lite|AxelEVB]] integrates a chip (Texas Instruments INA226) that allows to measure the power consumption of the Axel SOM. Following are the instructions to perform basic measurements (tested with the Linux kernel released with [[Axel_Embedded_Linux_Kit_(XELK)|XELK 2.3.0]]).
 +
 +
SOM power consumption measurements are available to be read from userspace via <code>sysfs</code> entries. Following are the entries for:
 +
* Voltage expressed in mV:
 +
<pre>
 +
root@axel-lite:~# cat /sys/class/hwmon/hwmon0/device/in0_input
 +
5
 +
root@axel-lite:~# cat /sys/class/hwmon/hwmon0/device/in1_input
 +
3286
 +
</pre>
 +
* Current expressed in mA:
 +
<pre>
 +
root@axel-lite:~# cat /sys/class/hwmon/hwmon0/device/curr1_input
 +
425
 +
</pre>
 +
* Power expressed in uW:
 +
<pre>
 +
root@axel-lite:~# cat /sys/class/hwmon/hwmon0/device/power1_input
 +
1500000
 +
</pre>
 +
 +
INA225 - referenced as U25 on AxelEVB - is very flexible. For more details about possible please refer to its data sheet (http://www.ti.com/product/INA226).
 +
 +
==Useful links==
 +
*[[FAQs (Axel)]]
 +
*[[Thermal management (Axel)]]
 +
*[[Power consumption (AxelLite)]]
 
==References==
 
==References==
 
{{reflist}}
 
{{reflist}}

Revision as of 16:36, 10 October 2016

Info Box
Axel-04.png Applies to Axel Ultra
Axel-lite 02.png Applies to Axel Lite
Axel-02.png Applies to AXEL ESATTA

Introduction[edit | edit source]

Default power management scheme provided by Axel Embedded Linux Kit makes use:

  • of the external PMIC for voltage scaling
  • of the interactive governor.

This scheme may affect system behavior significantly and may be not suited for specific applications. Therefore it should be understood and analyzed by system integrator in order to modify it - if necessary - before product final qualification and validation tests.

Following sections show some examples of the effects of such scheme.

Interrupt latency[edit | edit source]

In some cases, high interrupt latencies can cause "visible" effects that may be hard to explain at first sight. Typical example refers to the RX channel of UART ports. When receiving data stream rate is relatively high with respect to the RX FIFO size, it is strongly recommended to implement hardware flow control signals (RTS/CTS) in order to prevent well-known FIFO overrun condition (see also this page). In case hardware flow control is not available, FIFO overrun may be experienced. The probability of this event is proportional to the UART interrupt latency: the greater the latency, the more probable is the occurrence of FIFO overrun and thus the loss of received data. FIFO overrun event is usually reported by kernel by printing this message on console:

[  483.380456] imx-uart 21f0000.serial: Rx FIFO overrun

When dynamic processor's voltage/frequency scaling is enabled, Linux kernel performs a lot of transactions between different OPPs. Two approaches are available to implement such transactions:

  • PMIC-based: in this case an external Power Management Integrated Circuit (PMIC) is used to change processor's voltages
  • internal LDOs-based: in this case processor's internal linear regulators are used to change such voltages.

PMIC is connected to the processor via I2C bus. As such, every time a transaction is needed, several packets need to be transmitted over I2C bus, resulting in a relatively slow overall transaction time. This may lead to an increase of maximum interrupt latency. In case LDOs-based approach is adopted instead, transactions are quicker because LDOs configuration registers are directly accessible in the processor's address space. On the other hand, the use of LDOs has a significant drawback as explained in the following section.

Please note that OPP transactions may be prevented at all by manually configuring the governor in order to use a fixed OPP.

For more details please refer to this page.

Processor heating and lifetime[edit | edit source]

Use of internal LDOs increases the power dissipation on processor side significantly. As a consequence, operating junction temperature increases as well. This fact has to be taken into consideration at system integration level, as it is strictly related to expected processor lifetime. For more details please refer to [1] and [2].

Measuring power consumption[edit | edit source]

AxelEVB integrates a chip (Texas Instruments INA226) that allows to measure the power consumption of the Axel SOM. Following are the instructions to perform basic measurements (tested with the Linux kernel released with XELK 2.3.0).

SOM power consumption measurements are available to be read from userspace via sysfs entries. Following are the entries for:

  • Voltage expressed in mV:
root@axel-lite:~# cat /sys/class/hwmon/hwmon0/device/in0_input
5
root@axel-lite:~# cat /sys/class/hwmon/hwmon0/device/in1_input
3286
  • Current expressed in mA:
root@axel-lite:~# cat /sys/class/hwmon/hwmon0/device/curr1_input
425
  • Power expressed in uW:
root@axel-lite:~# cat /sys/class/hwmon/hwmon0/device/power1_input
1500000

INA225 - referenced as U25 on AxelEVB - is very flexible. For more details about possible please refer to its data sheet (http://www.ti.com/product/INA226).

Useful links[edit | edit source]

References[edit | edit source]

  1. Freescale Semiconductor, Inc., AN4724 i.MX 6Dual/6Quad Product Lifetime Usage Estimates
  2. Freescale Semiconductor, Inc., AN4725 i.MX 6Solo/6DualLite Product Lifetime Usage Estimates