OLPC battery class

Richard Hughes hughsient at gmail.com
Tue Jun 19 10:55:04 EDT 2007


Hi,

I've been looking at adding OLPC battery support into HAL so it can be
used with OHM and the power meter in sugar.

Putting it bluntly, the "generic battery class" is a bit of a misnomer,
as it's very OLPC specific. It also violates key sysfs rules such as
one-value per file, and it's not going to be pretty adding the current
battery/ac_adapter interface to HAL.

So far we have:

capacity_percentage	13
current			940
name			OLPC Battery
status			present charging
status_cap		present low full charging discharging overtemp critical
technology		NiMH
temp1			29101
temp1_name		battery
temp2			48753
temp2_name		ambient
type			battery
voltage			7101

Specific problems:

* 'capacity' is probably the wrong word to use, in common use it means
the battery capacity compared to when nit was new, to measure how the
battery has degraded over time.

* 'status' and 'status_cap' violate the one-value-per file mentality of
sysfs. This means we have to do string processing in HAL, rather than
just read the value of a flag. status_cap shouldn't be used at at all -
if the capability does not exist to report this, then do not export the
attribute (so no file in sysfs). See below for an example.

* 'temp1' - why not temperature_ambient?

* 'temp2' - why not temperature_internal?

* Why is the AC adapter exported as a battery of type ac? This is simply
wrong, they are _completely_ different types of device.

So, I would envisage a generic battery class to look like (munging
together OPLC and acpi stuff for the example):

***** BATTERY CLASS *****
description		OLPC Battery
present			1
charging		1
discharging		0
over_temperature	0
percentage		13
technology		NiMH
internal_temperature	29101
ambient_temperature	48753
voltage			7101
current			700
charge_now		940
charge_design		1100
charge_last_full	997
charge_unit		mAh
model_number		X2344
serial_number		300360
vendor			Sanyo

***** AC CLASS *****
present			1
description		OLPC AC Adapter

Now, I'm prepared to put my money where my mouth is and offer to rewrite
the kernel code to the above, and then write the (now trivial) HAL
interface for this. Any problems/comments?

Richard.





More information about the Devel mailing list