Jean Pihet | 4b95f13 | 2011-01-05 19:49:02 +0100 | [diff] [blame] | 1 | |
| 2 | Subsystem Trace Points: power |
| 3 | |
| 4 | The power tracing system captures events related to power transitions |
| 5 | within the kernel. Broadly speaking there are three major subheadings: |
| 6 | |
| 7 | o Power state switch which reports events related to suspend (S-states), |
| 8 | cpuidle (C-states) and cpufreq (P-states) |
| 9 | o System clock related changes |
| 10 | o Power domains related changes and transitions |
| 11 | |
| 12 | This document describes what each of the tracepoints is and why they |
| 13 | might be useful. |
| 14 | |
| 15 | Cf. include/trace/events/power.h for the events definitions. |
| 16 | |
| 17 | 1. Power state switch events |
| 18 | ============================ |
| 19 | |
Paul Gortmaker | 43720bd | 2013-01-11 13:43:45 +0100 | [diff] [blame] | 20 | 1.1 Trace API |
Jean Pihet | 4b95f13 | 2011-01-05 19:49:02 +0100 | [diff] [blame] | 21 | ----------------- |
| 22 | |
| 23 | A 'cpu' event class gathers the CPU-related events: cpuidle and |
| 24 | cpufreq. |
| 25 | |
| 26 | cpu_idle "state=%lu cpu_id=%lu" |
| 27 | cpu_frequency "state=%lu cpu_id=%lu" |
| 28 | |
| 29 | A suspend event is used to indicate the system going in and out of the |
| 30 | suspend mode: |
| 31 | |
| 32 | machine_suspend "state=%lu" |
| 33 | |
| 34 | |
| 35 | Note: the value of '-1' or '4294967295' for state means an exit from the current state, |
| 36 | i.e. trace_cpu_idle(4, smp_processor_id()) means that the system |
| 37 | enters the idle state 4, while trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id()) |
| 38 | means that the system exits the previous idle state. |
| 39 | |
| 40 | The event which has 'state=4294967295' in the trace is very important to the user |
| 41 | space tools which are using it to detect the end of the current state, and so to |
| 42 | correctly draw the states diagrams and to calculate accurate statistics etc. |
| 43 | |
Jean Pihet | 4b95f13 | 2011-01-05 19:49:02 +0100 | [diff] [blame] | 44 | 2. Clocks events |
| 45 | ================ |
| 46 | The clock events are used for clock enable/disable and for |
| 47 | clock rate change. |
| 48 | |
| 49 | clock_enable "%s state=%lu cpu_id=%lu" |
| 50 | clock_disable "%s state=%lu cpu_id=%lu" |
| 51 | clock_set_rate "%s state=%lu cpu_id=%lu" |
| 52 | |
| 53 | The first parameter gives the clock name (e.g. "gpio1_iclk"). |
| 54 | The second parameter is '1' for enable, '0' for disable, the target |
| 55 | clock rate for set_rate. |
| 56 | |
| 57 | 3. Power domains events |
| 58 | ======================= |
| 59 | The power domain events are used for power domains transitions |
| 60 | |
| 61 | power_domain_target "%s state=%lu cpu_id=%lu" |
| 62 | |
| 63 | The first parameter gives the power domain name (e.g. "mpu_pwrdm"). |
| 64 | The second parameter is the power domain target state. |
| 65 | |
Sahara | f5ce157 | 2013-06-21 11:12:31 +0900 | [diff] [blame] | 66 | 4. PM QoS events |
| 67 | ================ |
| 68 | The PM QoS events are used for QoS add/update/remove request and for |
| 69 | target/flags update. |
| 70 | |
| 71 | pm_qos_add_request "pm_qos_class=%s value=%d" |
| 72 | pm_qos_update_request "pm_qos_class=%s value=%d" |
| 73 | pm_qos_remove_request "pm_qos_class=%s value=%d" |
| 74 | pm_qos_update_request_timeout "pm_qos_class=%s value=%d, timeout_us=%ld" |
| 75 | |
| 76 | The first parameter gives the QoS class name (e.g. "CPU_DMA_LATENCY"). |
| 77 | The second parameter is value to be added/updated/removed. |
| 78 | The third parameter is timeout value in usec. |
| 79 | |
| 80 | pm_qos_update_target "action=%s prev_value=%d curr_value=%d" |
| 81 | pm_qos_update_flags "action=%s prev_value=0x%x curr_value=0x%x" |
| 82 | |
| 83 | The first parameter gives the QoS action name (e.g. "ADD_REQ"). |
| 84 | The second parameter is the previous QoS value. |
| 85 | The third parameter is the current QoS value to update. |
| 86 | |
| 87 | And, there are also events used for device PM QoS add/update/remove request. |
| 88 | |
| 89 | dev_pm_qos_add_request "device=%s type=%s new_value=%d" |
| 90 | dev_pm_qos_update_request "device=%s type=%s new_value=%d" |
| 91 | dev_pm_qos_remove_request "device=%s type=%s new_value=%d" |
| 92 | |
| 93 | The first parameter gives the device name which tries to add/update/remove |
| 94 | QoS requests. |
| 95 | The second parameter gives the request type (e.g. "DEV_PM_QOS_LATENCY"). |
| 96 | The third parameter is value to be added/updated/removed. |