214 lines
9.1 KiB
Text
214 lines
9.1 KiB
Text
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.
|
|
|
|
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.
|