[PATCH 4/6] various janitorial work on the pcf50633.c
zecke at openmoko.org
Sat May 10 15:58:39 CEST 2008
On Saturday 10 May 2008 15:13:42 Carsten Haitzler wrote:
> On Sat, 10 May 2008 14:46:20 +0200 Holger Freyther <zecke at openmoko.org>
> > On Saturday 10 May 2008 14:06:18 Wolfgang Spraul wrote:
> > > We ship only with HDQ batteries, that's correct.
> > > But people may well have old GTA01 batteries, or use compatible Nokia
> > > BL-4C/5C/6C batteries, or no-name replacements for those.
> > > Our battery driver and infrastructure should be as robust as possible.
> > > Wolfgang
> > The driver is robust. Currently "cat /proc/apm" is returning -1 for HDQ
> > based batteries, after the patch a sane number is reported (good for the
> > product). Regarding "acme replacement batteries". They will charge, "cat
> > /proc/apm" will return a wrong voltage number, but we don't know the
> > battery curve of these batteries anyway. The best I can think of is to
> > have a sysfs file somewhere to switch between ADC and HDQ...and move this
> > prob' to userspace.
> hmmm. grrr. ok - this is painful. i ready battery
> from /sys/class/power_supply/... the new 2.6.24+ generic power supply
> interface. even if /proc/apm exists - it prefers the newer interface.
hehe, in my copy of batget.c I see this:
if ((ecore_file_is_dir("/sys/class/power_supply")) &&
(!ecore_file_exists("/proc/apm"))) /* >= 2.6.24 */
So as long as I have a file called /proc/apm it will not use the battery
class. It is also matching by observation and I go as far as saying that is
not "prefering" the new interface over the old one. :)
> is rather painful that you need to flip interfaces on the fly - i had the
> code all wonderfully generic and automatic so it'd use the newest interface
> available if it exists, but this does kind of make life painful unless
> non-coulomb-counter batteries are emulated via /sys/class/power_supply/ as
> well. are they?
No, they are not emulated. To make it worse the bq27000 driver will always
succeed when probed. But I agree with andy's post that it is close to
impossible to get meaningful values for random 3rdparty batteries. As hard as
it might sound, I consider this a "non issue". 3rd party batteries will
charge, lifetime/charge prediction will not work, it wouldn't work even if we
throw a lot of work on this...
More information about the openmoko-kernel