Power button behaviour
olivier at aixmarseille.com
Mon Oct 20 10:40:37 CEST 2008
Mike (mwester) wrote:
> [cc'ing the kernel list, as this is pertinent to the kernel and recent
> discussion on that list]
> Olivier Fauchon wrote:
>> Sometimes, I can't hard poweroff my GTA02 by "holding power down for
>> 10s" : ex when phone is really crashed or during boot (That's boring to
>> remove battery)
>> Could you tell me why this situation occurs ? Pressing power 10s+ is an
>> hardware reboot, isn't it ? this should power down the phone in any
>> circonstances, without OS control ?
> It is "hardware" on the GTA01 (handled by the power-management chip),
> but it is done by the OS on the GTA02. So for it to be able to power
> down the phone, at least some portion of the operating system needs to
> still be functional.
What is correct :
1/ There is no more power-management chip for hardware reset chip in
GTA02 ? Why ?
2/ The kernel configures the power-management chip at boot, and then
only, the hardware reboot is working
If 1 is true, does this mean it's not sure we can power off a zombified
kernel system ( ugly battery removal procedure )?
If 2 is true, can we move the power-management chip initialization in
bootloader so it works as soon as possible in boot sequence?
Freelance System-Network Admin
Phone: +33 610 493 763
>> Can I change this 10s delay ? It's too long for me . 5s is good (like
>> for most of mobiles phones)
> Since it's done in software, it can be changed - it would require a
> modification to kernel source code and a rebuild of the kernel. The big
> concern I have on that is that if I recall correctly, entering suspend
> manually on the FSO distro requires that you hold the power button down
> for nearly 4 seconds -- this would be awfully close to the 5 second
> emergency powerdown! I think other distributions for the device have
> different timeouts, but since there are so very few buttons available on
> the device to begin with, I think that anything less than very long
> periods like 10 seconds will run the risk of being falsely triggered.
> Mike (mwester)
More information about the devel