new kernel ... / meaning of stable-tracking

Andy Green andy at
Mon Sep 29 20:14:03 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| 2008/9/29 Andy Green <andy at>:
|> Somebody in the thread at some point said:
|> | On a different note does someone know if gta01 had any stronger
|> | mechanism than what we have now?  I seem to recall that my gta01 would
|> | *always* power down if I pressed one of the two buttons and no driver
|> | was there to react to the button presses, i.e. something like a
|> | hardware hang check - I may be wrong but I thought it was something
|> | clever in the PCF50606 that would power down the whole device whenever
|> | an interrupt remained un-ACKed for longer than 5s or so.  It worked
|> | independently of whether the kernel finished booting or panicked.
|> I looked this up, there is an 8 second "timeout" option in pcf50633 tied
|> to the On Key button: you could enable it in if you hold the button for
|> | 1s, then it has 8 seconds to service the interrupt or it will go to
|> standby mode in hardware.
|> But, this is not settable by i2c but only set by variant.  And on our
|> variant it doesn't do that but just has it waking the device on press.
| Oooh, I don't suppose the PMU variant for gta03 is under discussion

We just got to use what we got I think.... there's a list of variants in
docs folder, I don't think we find one that differs solely by this

For example, we carefully match regulator function to variant-defined
regulator on/off and voltage state in NOPOWER, other variants change
those around basically because other NXP customers had designs that
wanted the differences.  They're probably not all equally available from
stock either.

And... the tight binding of the VB_SYS problem on A5 to inrush current
parameter also set by variant... I don't think we dare change it if we
want a chance of a "predictable ride" on power for GTA03.  Very much
"Devil we know".

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


More information about the openmoko-kernel mailing list