This patch registers the power supply as a cooling device if the power
supply has support for charge throttling.

Now with this change low level drivers need not register with thermal
framework as it is automatically done by power supply framework.
Signed-off-by: NRamakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

Add support for power supply attributes CHARGE_CONTROL_LIMIT
and CHARGE_CONTROL_LIMIT_MAX.

These new attributes will enable the user space to implement
custom charging algorithms based on platform state.
Signed-off-by: NRamakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

There are different types of chargers avalibale like AC, Solar, USB,
etc..  Even in USB we have different types SDP/DCP/CDP/ACA and all these
chargers have different o/p ratings. For example SDP supports only 500mA
of charge current whereas AC charger can support upto 8A or more.

Similarly batteries also come with charge current and voltage ratings
and these ratings vary depending on its capacity and the technology
used.

This patch adds two new power supply properties
CONSTANT_CHARGE_CURRENT_MAX and CONSTANT_CHARGE_CURRENT_MAX.
Signed-off-by: NRamakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

It is possible that users can use non-standard chargers or use invalid
batteries especially with mobile devices.

This patch adds a new power supply property called 'AUTHENTIC' to
indicate this to the user(user space).
Signed-off-by: NRamakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

Minimum and maximum alerts on power supply properties will help or allow
the user space to "proactively" create policies like connect/disconnect
charger or stop/start the user apps based on capacity or temperature
parameters.

These parameters can be used to avoid unnecessary polling from user space
and even from kernel space if the underlying HW can support INT triggers
(ex: max17042/47).

This patch adds the following power supply alert type properties:

 CAPACITY_ALERT_MIN
 CAPACITY_ALERT_MAX
 TEMP_ALERT_MIN
 TEMP_ALERT_MAX
 TEMP_AMBIENT_ALERT_MIN
 TEMP_AMBIENT_ALERT_MAX
Signed-off-by: NRamakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

Constant Charge Current(CC) is charging parameter which limit the
maximum current which can be pumped into the battery during charge cycle.

Constant Charge Voltage(CV) is also charging parameter which limit the
maximum voltage that battery can reach during charge cycle.

It is very common practice that at low or high temperatures we
do not charge the batteries upto it's fullest charge voltage
to avoid battery and user safety issues.

These sysfs properties will be useful for debug and to implement
certain user space policies like "Charging limited due to OverTemp".
Signed-off-by: NRamakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

Battery and charger contribute to Thermals in most of the embedded
devices. So, it makes sense to identify them as Thermal zones in a
particular platform.

This patch registers a thermal zone if the power supply is reporting
a temperature property. The thermal zone will be used by platform's
thermal management solution.
Signed-off-by: NJenny TC <jenny.tc@intel.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

On Mon, Apr 02, 2012 at 01:53:23PM +1000, Benjamin Herrenschmidt wrote:
> > drivers/built-in.o: In function `.nouveau_pm_trigger':
> > (.text+0xa56e8): undefined reference to `.power_supply_is_system_supplied'
> >
> > nouveau probably needs to depends on CONFIG_POWER_SUPPLY to force a module
> > build with the latter is =m
>
> Ok, not that trivial...
>
> The problem is more like POWER_SUPPLY should be a bool, not a tristate.
>
> If you think about it: you don't want things like nouveau to depend on a
> random subsystem like that, people will never get it. In fact,
> POWER_SUPPLY provides empty inline stubs when not enabled, so that's
> really designed to not have depends...
>
> However that -cannot- work if POWER_SUPPLY is modular and the drivers
> who use it are not.
>
> The only fixes here that make sense I can think of
> that don't also involve Kconfig horrors are:
>
>  - Ugly: in power_supply.h, use the extern variant if
>
>       defined(CONFIG_POWER_SUPPLY) ||
>        (defined(CONFIG_POWER_SUPPLY_MODULE) && defined(MODULE))
>
> IE. use the stub if power supply is a module and what is being built is
> built-in. Of course that's not only ugly, it somewhat sucks from a user
> perspective as the subsystem now exists but can't be used by some
> drivers...
>
>  - Better: Just make the bloody thing a bool :-) The power supply
> framework itself is small enough, just make it a boolean option and
> avoid the problem entirely. The actual power supply sub drivers can
> remain modular of course.
Suggested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This adds a new sysfs file called 'voltage_ocv' which gives the
Open Circuit Voltage of the battery.

This property can be used for platform shutdown policies and
can be useful for initial capacity estimations.

Note: This patch is generated against linux-next branch.
Signed-off-by: NRamakrishna Pallala <ramakrishna.pallala@intel.com>
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>

The <linux/device.h> header includes a lot of stuff, and
it in turn gets a lot of use just for the basic "struct device"
which appears so often.

Clean up the users as follows:

1) For those headers only needing "struct device" as a pointer
in fcn args, replace the include with exactly that.

2) For headers not really using anything from device.h, simply
delete the include altogether.

3) For headers relying on getting device.h implicitly before
being included themselves, now explicitly include device.h

4) For files in which doing #1 or #2 uncovers an implicit
dependency on some other header, fix by explicitly adding
the required header(s).

Any C files that were implicitly relying on device.h to be
present have already been dealt with in advance.

Total removals from #1 and #2: 51.  Total additions coming
from #3: 9.  Total other implicit dependencies from #4: 7.

As of 3.3-rc1, there were 110, so a net removal of 42 gives
about a 38% reduction in device.h presence in include/*
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

For the default value of power supply type, "unknown" is added.
With default prop value, supply type property can be displayed
as default - "Unknown".
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

If a power supply has a scope of "Device", then allow the power supply
to indicate what device it actually powers. This is represented in the
power supply's sysfs directory as a symlink named "powers", which points to
the sysfs directory of the powered device.

If the device has children, then the sub-devices are also powered by
the same power supply.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
Cc: Richard Hughes <richard@hughsie.com>

This adds a "scope" attribute to a power_supply, which indicates how
much of the system it powers.  It appears in sysfs as "scope" or in
the uevent file as POWER_SUPPLY_SCOPE=.  There are presently three
possible values:
	Unknown - unknown power topology
	System - the power supply powers the whole system
	Device - it powers a specific device, or tree of devices

A power supply which doesn't have a "scope" attribute should be assumed to
have "System" scope.

In general, usermode should assume that loss of all System-scoped power
supplies will power off the whole system, but any single one is sufficient
to power the system.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
Cc: Richard Hughes <richard@hughsie.com>

Update the power_supply_is_watt_property function to include POWER_NOW.
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

Add new trigger to power_supply LEDs. It will blink when battery is
charging, and stay solid when battery is charged. It's usefull to
indicate battery state when there's only one LED available.
Signed-off-by: NVasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

Adding support for charge properties for gas gauge.

Also ensuring that battery mode is correct now for energy as well as
charge properties by setting it on the fly.

I also added 2 functions to power_supply.h to help identify the units for
specific properties more easily by power supplies.
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

USB only gives the maximum current allowed to draw.
Signed-off-by: NHeikki Krogerus <ext-heikki.krogerus@nokia.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This adds power supply types for USB chargers defined in
Battery Charging Specification 1.1.
Signed-off-by: NHeikki Krogerus <ext-heikki.krogerus@nokia.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This patch adds support for writeable power supply properties and
exposes them as writeable to sysfs.

A power supply implementation must implement two new function calls in
order to use that feature:

  int set_property(struct power_supply *psy,
                   enum power_supply_property psp,
                   const union power_supply_propval *val);

  int property_is_writeable(struct power_supply *psy,
                            enum power_supply_property psp);
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>
Cc: Len Brown <len.brown@intel.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Matt Reimer <mreimer@vpop.net>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This fixes a race between power supply device and initial
attributes creation, plus makes it possible to implement
writable properties.

[Daniel Mack - removed superflous return statement
 and dropped .mode attribute from POWER_SUPPLY_ATTR]
Suggested-by: NGreg KH <gregkh@suse.de>
Suggested-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Tested-by: NDaniel Mack <daniel@caiaq.de>

Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

This adds a function that indicates that a battery is fully charged.
It also includes functions to get a power_supply device from the class
of registered devices by name reference. These can be used to find a
specific battery to call power_supply_set_battery_charged() on.

Some battery drivers might need this information to calibrate
themselves.
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Cc: Ian Molton <spyro@f2s.com>
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: Matt Reimer <mreimer@vpop.net>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This adds a new sysfs file called 'charge_type' which displays the
type of charging (unknown, n/a, trickle charge, or fast charging).

This allows things like battery diagnostics to determine what the
battery/EC is doing without resorting to changing the 'status' sysfs
output.
Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This reverts commit 8efe4440 and
4cbc76ea.

Richard@laptop.org was apparently using CAPACITY_LEVEL for debugging
battery/EC problems, and was upset that it was removed.  This readds it.

Conflicts:

	Documentation/power_supply_class.txt
Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

ACPI has smart batteries, which work in units of energy and measure
rate of (dis)charge as power, thus it is not appropriate to export it
as a current_now. Current_now will still be exported to allow
for userland applications to match.
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some systems are able to report problems with batteries being under
temperature.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

Certain drivers benefit from knowing whether the system is on ac or
battery, for instance when determining which backlight registers to
read. This adds a simple call to determine whether there's an online
power supply other than any batteries.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This adds PROP_CHARGE_COUNTER to the power supply class (documenting it
as well).  The OLPC battery driver uses this for spitting out its ACR
values (in uAh).  We have some rounding errors (the data sheet claims
416.7, the math actually works out to 416.666667, so we're forced to
choose between overflows or precision loss.  I chose precision loss,
and stuck w/ data sheet values), but I don't think anyone will care
that much.
Signed-off-by: NAndres Salomon <dilinger@debian.org>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

egrep serial /proc/acpi/battery/BAT0/info
serial number:           32090

serial number can tell you from the imminent danger
of beeing set on fire.
Signed-off-by: Nmaximilian attems <max@stro.at>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add LiMn (one of the most common for small non-rechargable batteries)
battery technology and voltage_min/_max properties support.
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: NAnton Vorontsov <cbou@mail.ru>

The CAPACITY_LEVEL stuff defines various levels of charge; however, what
is the difference between them?  What differentiates between HIGH and NORMAL,
LOW and CRITICAL, etc?

As it appears that these are fairly arbitrary, we end up making such policy
decisions in the kernel (or in hardware).  This is the sort of decision that
should be made in userspace, not in the kernel.

If the hardware does not support _CAPACITY and it cannot be easily calculated,
then perhaps the driver should register a custom CAPACITY_LEVEL attribute;
however, userspace should not become accustomed to looking for such a thing,
and we should certainly not encourage drivers to provide CAPACITY_LEVEL
stubs.

The following removes support for POWER_SUPPLY_PROP_CAPACITY_LEVEL.  The
OLPC battery driver is the only driver making use of this, so it's
removed from there as well.
Signed-off-by: NAndres Salomon <dilinger@debian.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

This class is result of "external power" and "battery" classes merge,
as suggested by David Woodhouse. He also implemented uevent support.

Here how userspace seeing it now:

    	# ls /sys/class/power\ supply/
    	ac  main-battery  usb

    	# cat /sys/class/power\ supply/ac/type
    	AC

    	# cat /sys/class/power\ supply/usb/type
    	USB

    	# cat /sys/class/power\ supply/main-battery/type
    	Battery

    	# cat /sys/class/power\ supply/ac/online
    	1

    	# cat /sys/class/power\ supply/usb/online
    	0

    	# cat /sys/class/power\ supply/main-battery/status
    	Charging

    	# cat /sys/class/leds/h5400\:red-left/trigger
    	none h5400-radio timer hwtimer ac-online usb-online
    	main-battery-charging-or-full [main-battery-charging]
    	main-battery-full
Signed-off-by: NAnton Vorontsov <cbou@mail.ru>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>