123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215 |
- 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/supply/ds2760_battery.c and drivers/power/supply/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.
- VOLTAGE_BOOT - Reports the voltage measured during boot
- CURRENT_BOOT - Reports the current measured during boot
- 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.
- CALIBRATE - battery or coulomb counter calibration status
- 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.
|