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

[Sean McNeil]

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 :)

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.

Thanks,
Sean