[PATCH 4/6] various janitorial work on the pcf50633.c

[Holger Freyther]

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> 
babbled:
> > 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")) &&
       (dir_has_contents("/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. :)



> this 
> 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
> older
> 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...

z.