XO-1 lid sensor incorrectly reads as closed after Linux reboot

[Quozl]

The lid sensor will read as closed, despite the lid being open, after Linux reboot and restart of Open Firmware.

Method to reproduce:

• use Q2F12 or later,
• use any build,
• select reboot in Linux,
• use the escape key to enter Open Firmware,
• quickly type lid-off to disable the automatic power down,
• type lid? . to view the lid sensor status.

Does not occur if the unit is turned on using the power button.

The lid sensor is attached to both the EC and a main CPU GPIO. It may be that the EC is not managing the pin correctly after reboot.

The problem was exposed by an Open Firmware change to pay attention to the lid switch. (#11095).

Reproduced by Kevin Gordon with builds 711, 802, 860, 874, 883, 885 and 12.1.0 build 21, with firmware q2f12. Other firmware versions in the same test were q2e45, q2e48, q2f05, q2f09, q2f10, q2f11, q2f12, and q2f13.

[dsd]

The lid handling code is a bit weird, but it seems reliable this way (under Linux). If you weren't already aware of it, maybe this code gives you some clues:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/platform/olpc/olpc-xo1-sci.c;h=63d4aa40956e33abe7f98f5ed3c36916a6c7b94f;hb=HEAD#l96

Also see setup_lid_events()

[Quozl]

Thanks. The code you pointed me to was critical to my understanding; there's a GPIO pin invert register bit that is cleared on power up reset, but not cleared on reboot. The reference to #5703 was also very useful.

Changing the pin invert bit costs two cycles of a 32kHz clock for the data to be updated, per http://wiki.laptop.org/images/4/46/GPIO.png . By XORing against the invert input bit, the true sense of the pin is obtained without the delay cost. Fixed in svn 3278, and will be in next XO-1 Open Firmware release.

A development build is available at http://dev.laptop.org/~quozl/q2f13je.rom ... which lacks svn 3235 to avoid a build problem.

[Quozl]

Kevin Gordon has tested Q2F13je with builds 885, 883, 874 and 860, and with 12.1.0 builds 14, 20, and 21.

[dsd]

James, what do you think about making an OFW release so that we have this in a build?

[Quozl]

Risky. There have been significant changes for XO-4 development. No source tree stabilisation work has been done for quite a while, as far as I know. Have you made and tested any current Open Firmware builds? I don't think this problem justifies a backport build. I'm inclined to wait until there are other XO-1 firmware problems that need fixing. What do you think?

[dsd]

OK, sounds fine. Lets not consider this for 13.1.0 at this time.

[Quozl]

Is in Q2F14.