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

Sean McNeil sean at mcneil.com
Sun Jun 8 23:27:23 CEST 2008

Andy Green wrote:
> 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".
That would be great.

> | 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?
No, I didn't really solve it. I had some of the framework there, 
however, which could have given the charging state correctly from the 
apm emulation.

> ~ - 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.
This is what I need as well. I also need uevents for when the capacity 
or temperature changes. I hope the uevents aren't being initiated with 
the kobjects directly. They should be calling into a hook for the 
battery device and then it should in turn be calling 
power_supply_changed(). I would also very much like to see the 
power_supply class have 3 objects: battery (instead of bat as it is more 
standard), ac, and usb. This is what I have now and tried to indicate 
charging state through the ac and usb objects. By the way, I've found 
that some of the timing and retries for reading battery info are too 
low. I'd get errors trying to read the status if I did it too often.
> ~ - 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.
This has been a little bit of a sticky issue. I firmly believe that the 
kernel should not dictate LED behavior. If we can implement the charging 
state stuff as an LED trigger which can be optionally turned on or off 
(I'm somewhat OK with it being a default trigger, but perhaps it can be 
a config option?), then I'm happy.
> -Andy

More information about the openmoko-kernel mailing list