GTA02 PMU goes out to lunch...

Andy Green andy at
Sun Jul 27 08:51:30 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

|> Mike, it means apm stuff is reporting PMU ADC voltage reading or HDQ?
| For the testing I was doing, it was reading the ADC (i.e. /proc/apm was
| reporting using the apm battery code in the pcf50633 driver -- which
| according to Zecke is *not* using the HDQ).
| I built a new kernel with CONFIG_APM_POWER enabled, and I'll test with
| that; perhaps /proc/apm will behave.
| But the fundamental problem is at a more primitive level than APM;
| that's just an easy way for users to see the failure.  The problem is


| that at some point the readings you get when you query the /sysfs files
| for the pcf50633 all go to 0xff, and stay that way until a
| suspend/resume cycle resets things, and you once again get sane values.
|  Something is going out to lunch, and on my GTA02 it does it rather
| often (5 min often, and I've never seen it able to return valid values
| for longer than an hour on the latest kernels).

Hum OK.  I guess it is some failure around handling ADC interrupt.

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


More information about the openmoko-kernel mailing list