| Linux power supply class |
| ======================== |
| |
| Synopsis |
| ~~~~~~~~ |
| Power supply class used to represent battery, UPS, AC or DC power supply |
| properties to user-space. |
| |
| It defines core set of attributes, which should be applicable to (almost) |
| every power supply out there. Attributes are available via sysfs and uevent |
| interfaces. |
| |
| Each attribute has well defined meaning, up to unit of measure used. While |
| the attributes provided are believed to be universally applicable to any |
| power supply, specific monitoring hardware may not be able to provide them |
| all, so any of them may be skipped. |
| |
| Power supply class is extensible, and allows to define drivers own attributes. |
| The core attribute set is subject to the standard Linux evolution (i.e. |
| if it will be found that some attribute is applicable to many power supply |
| types or their drivers, it can be added to the core set). |
| |
| It also integrates with LED framework, for the purpose of providing |
| typically expected feedback of battery charging/fully charged status and |
| AC/USB power supply online status. (Note that specific details of the |
| indication (including whether to use it at all) are fully controllable by |
| user and/or specific machine defaults, per design principles of LED |
| framework). |
| |
| |
| Attributes/properties |
| ~~~~~~~~~~~~~~~~~~~~~ |
| Power supply class has predefined set of attributes, this eliminates code |
| duplication across drivers. Power supply class insist on reusing its |
| predefined attributes *and* their units. |
| |
| So, userspace gets predictable set of attributes and their units for any |
| kind of power supply, and can process/present them to a user in consistent |
| manner. Results for different power supplies and machines are also directly |
| comparable. |
| |
| See drivers/power/ds2760_battery.c and drivers/power/pda_power.c for the |
| example how to declare and handle attributes. |
| |
| |
| Units |
| ~~~~~ |
| Quoting include/linux/power_supply.h: |
| |
| All voltages, currents, charges, energies, time and temperatures in µV, |
| µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise |
| stated. It's driver's job to convert its raw values to units in which |
| this class operates. |
| |
| |
| Attributes/properties detailed |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| ~ ~ ~ ~ ~ ~ ~ Charge/Energy/Capacity - how to not confuse ~ ~ ~ ~ ~ ~ ~ |
| ~ ~ |
| ~ Because both "charge" (µAh) and "energy" (µWh) represents "capacity" ~ |
| ~ of battery, this class distinguish these terms. Don't mix them! ~ |
| ~ ~ |
| ~ CHARGE_* attributes represents capacity in µAh only. ~ |
| ~ ENERGY_* attributes represents capacity in µWh only. ~ |
| ~ CAPACITY attribute represents capacity in *percents*, from 0 to 100. ~ |
| ~ ~ |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| |
| Postfixes: |
| _AVG - *hardware* averaged value, use it if your hardware is really able to |
| report averaged values. |
| _NOW - momentary/instantaneous values. |
| |
| STATUS - this attribute represents operating status (charging, full, |
| discharging (i.e. powering a load), etc.). This corresponds to |
| BATTERY_STATUS_* values, as defined in battery.h. |
| |
| CHARGE_TYPE - batteries can typically charge at different rates. |
| This defines trickle and fast charges. For batteries that |
| are already charged or discharging, 'n/a' can be displayed (or |
| 'unknown', if the status is not known). |
| |
| AUTHENTIC - indicates the power supply (battery or charger) connected |
| to the platform is authentic(1) or non authentic(0). |
| |
| HEALTH - represents health of the battery, values corresponds to |
| POWER_SUPPLY_HEALTH_*, defined in battery.h. |
| |
| VOLTAGE_OCV - open circuit voltage of the battery. |
| |
| VOLTAGE_MAX_DESIGN, VOLTAGE_MIN_DESIGN - design values for maximal and |
| minimal power supply voltages. Maximal/minimal means values of voltages |
| when battery considered "full"/"empty" at normal conditions. Yes, there is |
| no direct relation between voltage and battery capacity, but some dumb |
| batteries use voltage for very approximated calculation of capacity. |
| Battery driver also can use this attribute just to inform userspace |
| about maximal and minimal voltage thresholds of a given battery. |
| |
| VOLTAGE_MAX, VOLTAGE_MIN - same as _DESIGN voltage values except that |
| these ones should be used if hardware could only guess (measure and |
| retain) the thresholds of a given power supply. |
| |
| CHARGE_FULL_DESIGN, CHARGE_EMPTY_DESIGN - design charge values, when |
| battery considered full/empty. |
| |
| ENERGY_FULL_DESIGN, ENERGY_EMPTY_DESIGN - same as above but for energy. |
| |
| CHARGE_FULL, CHARGE_EMPTY - These attributes means "last remembered value |
| of charge when battery became full/empty". It also could mean "value of |
| charge when battery considered full/empty at given conditions (temperature, |
| age)". I.e. these attributes represents real thresholds, not design values. |
| |
| CHARGE_COUNTER - the current charge counter (in µAh). This could easily |
| be negative; there is no empty or full value. It is only useful for |
| relative, time-based measurements. |
| |
| CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger. |
| CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the |
| power supply object. |
| INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates |
| the current drawn from a charging source. |
| CHARGE_TERM_CURRENT - Charge termination current used to detect the end of charge |
| condition. |
| |
| CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger. |
| CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the |
| power supply object. |
| |
| CHARGE_CONTROL_LIMIT - current charge control limit setting |
| CHARGE_CONTROL_LIMIT_MAX - maximum charge control limit setting |
| |
| ENERGY_FULL, ENERGY_EMPTY - same as above but for energy. |
| |
| CAPACITY - capacity in percents. |
| CAPACITY_ALERT_MIN - minimum capacity alert value in percents. |
| CAPACITY_ALERT_MAX - maximum capacity alert value in percents. |
| CAPACITY_LEVEL - capacity level. This corresponds to |
| POWER_SUPPLY_CAPACITY_LEVEL_*. |
| |
| TEMP - temperature of the power supply. |
| TEMP_ALERT_MIN - minimum battery temperature alert. |
| TEMP_ALERT_MAX - maximum battery temperature alert. |
| TEMP_AMBIENT - ambient temperature. |
| TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert. |
| TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert. |
| TEMP_MIN - minimum operatable temperature |
| TEMP_MAX - maximum operatable temperature |
| |
| TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e. |
| while battery powers a load) |
| TIME_TO_FULL - seconds left for battery to be considered full (i.e. |
| while battery is charging) |
| |
| |
| Battery <-> external power supply interaction |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| Often power supplies are acting as supplies and supplicants at the same |
| time. Batteries are good example. So, batteries usually care if they're |
| externally powered or not. |
| |
| For that case, power supply class implements notification mechanism for |
| batteries. |
| |
| External power supply (AC) lists supplicants (batteries) names in |
| "supplied_to" struct member, and each power_supply_changed() call |
| issued by external power supply will notify supplicants via |
| external_power_changed callback. |
| |
| |
| QA |
| ~~ |
| Q: Where is POWER_SUPPLY_PROP_XYZ attribute? |
| A: If you cannot find attribute suitable for your driver needs, feel free |
| to add it and send patch along with your driver. |
| |
| The attributes available currently are the ones currently provided by the |
| drivers written. |
| |
| Good candidates to add in future: model/part#, cycle_time, manufacturer, |
| etc. |
| |
| |
| Q: I have some very specific attribute (e.g. battery color), should I add |
| this attribute to standard ones? |
| A: Most likely, no. Such attribute can be placed in the driver itself, if |
| it is useful. Of course, if the attribute in question applicable to |
| large set of batteries, provided by many drivers, and/or comes from |
| some general battery specification/standard, it may be a candidate to |
| be added to the core attribute set. |
| |
| |
| Q: Suppose, my battery monitoring chip/firmware does not provides capacity |
| in percents, but provides charge_{now,full,empty}. Should I calculate |
| percentage capacity manually, inside the driver, and register CAPACITY |
| attribute? The same question about time_to_empty/time_to_full. |
| A: Most likely, no. This class is designed to export properties which are |
| directly measurable by the specific hardware available. |
| |
| Inferring not available properties using some heuristics or mathematical |
| model is not subject of work for a battery driver. Such functionality |
| should be factored out, and in fact, apm_power, the driver to serve |
| legacy APM API on top of power supply class, uses a simple heuristic of |
| approximating remaining battery capacity based on its charge, current, |
| voltage and so on. But full-fledged battery model is likely not subject |
| for kernel at all, as it would require floating point calculation to deal |
| with things like differential equations and Kalman filters. This is |
| better be handled by batteryd/libbattery, yet to be written. |