GTA02 PMU goes out to lunch...

[Mike (mwester)]

Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> | Latest kernel (even newer than new!), gta02, on USB cable, no
> | suspend/resume enabled, after some period of time /proc/apm reports 0xff
> | for some of the fields.  Suspending the device and resuming returns the
> | status to normal.
> |
> | I know these sorts of issues have been discussed -- what's the current
> | status, and what can I do to help track this down?  It's quite
> | repeatable here...
> 
> 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).

Mike (mwester)