[PATCH 4/6] various janitorial work on the pcf50633.c
andy at openmoko.com
Sat May 10 12:47:32 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| On Saturday 10 May 2008 11:37:33 joerg at openmoko.org wrote:
|> Am Fr 9. Mai 2008 schrieb Holger Freyther:
|>> From 2ce5e12156c3aaf4574b736bbaf103f40c593d14 Mon Sep 17 00:00:00 2001
|>> From: Holger Freyther <zecke at openmoko.org>
|>> Date: Thu, 8 May 2008 23:15:46 +0200
|>> Subject: [PATCH] [pcf50633] Assume that all gta02's have a battery with
|>> coulumb counter
|>> For the gta02 and the bq27000 battery it does not make sense to use
|>> the ADC to get the current voltage. Under the assumption that all mass
|>> production gta02's have such batteries it does not make any sense to
|>> forward this value to APM.
|> We may use GTA01 or even Nokia replacement batteries! Those don't have
|> bq2700. Think we should be able to handle these too though.
|> Just a comment from Ur hw-department, I had no look at the source at all
| Even worse. You can start with a bq27000 battery and then switch to a
| replacement battery not having a bq27000 at runtime. You would have to
| constantly monitor if the battery speaks HDQ and then switch the APM
| method to either the pcf50633 or the apm_power one. Sadly there is no
| framework for such things inside the kernel.
| From these options having a working /proc/apm by default was the most
| solution I could think of.
We ship with only HDQ capable battery AFAIK. PMU will charge anything.
~ APM interface didn't show meaningful data for me the old way. So it is
an issue only about battery voltage reporting (not capacity) with
What we could do is if HDQ effort times out, fall back to ADC method
(and fix that now or later).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel