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

[Andy Green]

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

Somebody in the thread at some point said:
| Andy Green wrote:
|> 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
| Your welcome :)

Yeah "any time", right?

| Please just make sure that the kernel does not drive the LED. I now have
| it being turned on without my permission when I plug in the USB cable.
| This is not right. I want to and I am controlling the LED myself and do
| not expect the kernel to change it.

Yesterday Holger showed us his uevent patches he started working on and
that is already decided on the list to be the way to get the information
from this patch out to userspace.

Since you're running the code that will be the basis for this indication
either way, can you check if it actually works consistently for you
under all circumstances?  Because tracking the charging state was not
entirely straightforward, and now we can see what the charger actually
does it exposed at least one inconsistent behaviour from the charger
itself for me.

- -Andy

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

iEYEARECAAYFAkhGRWMACgkQOjLpvpq7dMqf9wCfVH7IAKQ6wOZ86gs55kNhDHzL
rpgAn2pWA0s0s0Muc3flNcPGvyEMFFUv
=wlSB
-----END PGP SIGNATURE-----