[PATCH 1/5] introduce-charging-led-behaviour.patch

Andy Green andy at openmoko.com
Wed Jun 4 08:14:22 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

|> This is done by leveraging the PMU interrupts, but in one scenario
|> there is no interrupt that occurs, when the battery is replaced after
|> being removed with the USB power in all the while.  So a sleepy work
|> function is started under those circumstances to watch for battery
|> reinsertion or USB cable pull.
|>
|> 100mA limit was not being observed under some conditions so this was
|> fixed and tested with a USB cable with D+/D- disconnected.  1A
|> charger behaviour was also tested.
|>
|> Showing the charging action exposes some inconsistency in pcf50633
|> charging action.  If your battery is nearly full, it will keep
|> charging it at decreasing current even after it thinks it is at
|> 100% capacity for a long while.  But if you pull that same battery
|> and re-insert it, the charger state machine in pcf50633 believe it is
|> full and won't charge it.
|>
| Please file this patch away and revery....
|
| a) The behavior belongs in the application layer.
| b) It interferes with application control of LEDs.

Please read what the patch actually does before joining in hating on it
without understanding the situation.  2 lines of it concern LEDs, the
rest generates the information and events needed in kernel OR userspace
to actually track charging activity without polling.

Holger's patchset that puts in the plumbing to push events to userspace
won't actually track charging action it is intended for without this
patch either.

But thanks for the drive by negative opinion anyway.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhGMr4ACgkQOjLpvpq7dMoCvwCeMVauK3LA3akSjkMRe/yrTKIS
xHUAoIjk2RrSYSa/Kvh2v3W90zeLjJmN
=m8ux
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list