[PATCH 0/5] Power supply and resume ordering meddling

Andy Green andy at openmoko.com
Sun Jun 8 22:40:17 CEST 2008


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

Somebody in the thread at some point said:
| Hi Andy,
|
| I'm curious... there is a control state for LEDs where you can set the
| trigger. Why can't that be implemented properly so that if someone wants
| the LED to reflect charging state then they just write the appropriate
| trigger to that LED? If not, then it can be set to something else (i.e.
| for me, timer). Wouldn't that satisfy everyone?

I never used LED Class before now, I see it's pretty cool and the
triggers are not hard to register and make events on.  So thanks for the
good idea.

I will add support for it to my patch, with the LED trigger about
charging owned by pcf50633.c, which "owns the charger".

| As far as exposing the charging stuff, I provided a patch quite some
| time ago that brought out the information as power_supply class objects.
| I was using information from the apm emulation, but it could be changed.
| This is really where Linux is suppose to be exposing such information.

There are three issues here.

~ - Capture anywhere of charging state

Whatever information you were bringing out, did it really include
charging state -- as opposed to charger presence?  AFAIK no event source
existed for stopping and resuming charging until my patch.  Did you
really solve that already?

~ - Exposure of events

Holger has this stuff coming out of "change notification" uevents
associated with the battery kobject, it sounds OK to me as a general
solution userspace can subscribe to.  Probably better than sticking
events down the PMU input event subsystem for example, which would have
been defensible seeing as we do it already for some PMU things.

~ - Lighting LEDs or reacting otherwise; and overloading for notifications

I never heard about even the need for shared formal UI notifications on
LEDs until after the charging patch.  So that is at least one reason why
we don't get to the end in one step.

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

iEYEARECAAYFAkhMQ7EACgkQOjLpvpq7dMpiLwCfSS4ho4vMdvgJJL+IP0eyt0ah
pvoAoJUyXVcbrsN9eAdpdHMv2YIM2oOL
=yvsT
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list