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

Andy Green andy at openmoko.com
Mon Jun 9 09:32:33 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

|> 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.

English is perfectly ambiguous sometimes... "which could have, given..."
~ matches the situation you were not given the charging state from APM

|> ~ - 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

Yeah we had a thread about this and that is what we decided.

However, unlike PMU activity signalled by interrupt, there is no "event"
that signals temp or capacity changes: the underlying way has to be
polling.  And this is best done from userspace I think.

| 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.

Not sure why that is (or what "retries" are for this, have I
misunderstood you?), I put a mutex around the HDQ foreground read and
write operations, and the dump sysfs node spews back-to-back reads fine
last time I looked.  Maybe you are exposing some unreliability that is
probability based, faster you read more you see it?

|> ~ - 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.

Hum I can see in this case there are enough interested parties pulling
in different directions (and we wired it up through LED class already)
that this is a good solution, but "over engineering" does exist.  For
example, now various class stuff and userspace daemons written and
having to be maintained by several people is involved now in "lighting
an LED", which initially was defined to spend its whole life only
reflecting charge state.  Nobody is documenting this wonderland either.

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


More information about the openmoko-kernel mailing list