There are times when the battery is present but trickle charging,
and the EC sets only the TRICKLE bit. So we must check for the bit
when we're checking the charging/present status.
Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

The eeprom read function was placing values into the wrong place in
'buf'; we were starting from buf[off], rather than buf[0].

Also, the for loop that we were using was much uglier than it needed to
be.  This cleans it up a bit.
Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Acked-by: NAndres Salomon <dilinger@queued.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As Richard Smith pointed out, ACR * 6250 / 15 provides for less
precision loss than ACR * 4167 / 10, _and_ it doesn't overflow.  Switch
to using that equation for CHARGE_COUNTER.
Signed-off-by: NAndres Salomon <dilinger@debian.org>
Cc: "Richard A. Smith" <richard@laptop.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
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>

Refuse to run with an EC < 0x44.  We're playing it safe, and this is a pretty
old EC version.

Also, add a comment about why we're checking the EC version.
Signed-off-by: NAndres Salomon <dilinger@debian.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

Move portions of the massive switch statement into functions.  The layout of
this thing has already caused one bug (a break in the wrong place), it needed
to shrink.
Signed-off-by: NAndres Salomon <dilinger@debian.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This allows you to dump 0x60 bytes from the battery's EEPROM (starting at
address 0x20).  Note that it does an EC command for each byte, so it's pretty
slow.  OTOH, if you want to grab just a single byte from somewhere in the
EEPROM, you can do something like:

dd bs=1 count=1 skip=16 if=/sys/class/power_supply/olpc-battery/eeprom | od -x

Userspace battery collection/logging information needs this.
Signed-off-by: NAndres Salomon <dilinger@debian.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This adds serial number support to the OLPC battery driver.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndres Salomon <dilinger@debian.org>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This adds support for OLPC XO hardware.  Open Firmware on XOs don't contain
the VSA, so it is necessary to emulate the PCI BARs in the kernel.  This also
adds functionality for running EC commands, and a CONFIG_OLPC.

A number of OLPC drivers depend upon CONFIG_OLPC.

olpc_ec_timeout is a hack to work around Embedded Controller bugs.

[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: geode_has_vsa build fix]
[akpm@linux-foundation.org: olpc_register_battery_callback doesn't exist]
Signed-off-by: NAndres Salomon <dilinger@debian.org>
Acked-by: NIngo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@suse.de>
Cc: Jordan Crouse <jordan.crouse@amd.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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>

Per Jeff Garzik request.
Signed-off-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NAnton Vorontsov <cbou@mail.ru>

Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAnton Vorontsov <cbou@mail.ru>