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

Michael 'Mickey' Lauer mickey at openmoko.org
Mon Jun 9 00:00:57 CEST 2008

On Sunday 08 June 2008 23:27:23 Sean McNeil wrote:
> 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.

Given that there is a charging trigger since ages in the kernel LED class, it 
looks like adjusting this to get Will's behaviour is a sane path.


More information about the openmoko-kernel mailing list