[PATCH 1/5] introduce-charging-led-behaviour.patch
sean at mcneil.com
Wed Jun 4 08:38:55 CEST 2008
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.
Your welcome :)
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.
More information about the openmoko-kernel