keystroke which causes resume is lost

[pgf]

currently the keystroke that wakes the system never arrives at the kernel. this needs to be fixed.

possibilities include using the EC to assert flow control in time to prevent the keycode from arriving at the SoC until it's fully awake, or maybe using the ps/2 "resend" (0xfe) command.

[pgf]

another possibility is not letting the SP go completely to sleep, when in idle-suspend mode. lid-closed or power-button sleeps would of course still do a full sleep.

[pgf]

one more note: it's not just ps/2 chars that we lose -- we lose gamekey codes as well. i believe the issue may simply be that the SP wakes up much later than the SoC, and the interrupt is no longer present. needs investigation though.

[pgf]

right now i'm most interested in pursuing the notion of sending a "resend" command, to get back a copy of the key we lost. our keyboard does respond to that command, albeit with the scanset 2 value, not the matrix value. (i think this means that we'd be unable to retrieve copies of our "special" keystrokes -- i.e., the ones that are the reason we use matrix mode in the first place. but that's probably okay. maybe.)

but doing this requires that we know we lost a key in the first place. i believe this means we need to know that a) we just woke up, and b) we were woken by pin 71 (kbd clock). i'm now trying to figure out how we can most easily determine those things.

[wmb@…]

you can tell that pin 71 woke you by looking in the GPIO Edge registers. GPIOE_RERx on page 1655 of the ARMADA 610 Registers manual. See "gpio-wakeup?" in openfirmware/cpu/arm/mmp2/dramrecal.fth . In fact, see "kbd-wakeup?" in that same file. ".wakeup" might also be enlightening - it displays everything that I could find in the manual that is relevant to wakeups. ".icu" displays interrupt status - which is somewhat separate from wakeups, but coupled in many cases.

[pgf]

thanks. i've instrumented the consoleio interrupt handler with counters, and i'm pretty sure we're not passing through there at all for the lost character, but that doesn't mean the gpio edge detector hasn't triggered.

and thanks for the pointer to .wakeup -- hadn't found that yet, or .setup-key-wakeup, which looks like it might simplify my testing.

[pgf]

mitch -- i'm also curious about this comment from dramrecal.fth:

\ !!! The problem right now is that I have woken from keyboard, but the interrupt is still asserted
\ So perhaps the interrupt handler didn't fire

obviously there are a lot of work-in-progress comments in there, but that one stands out at the moment.

[wmb@…]

I'm not sure if that comment is still relevant. It looks like something I would have written when I was interrupted, to remind me where I was when I got back. I might have fixed the problem already, or perhaps not. I just don't remember.

[pgf]

thanks. i suspected as much. i'll look into that.

looking further ahead: this "resend" idea might not work out -- it seems like a fragile undertaking. we should reconnect the keyboard to the EC -- i.e., populate both paths. the EC will hopefully never have use of that line, but "just in case".

one possible scenario, mentioned above, which would avoid fully returning to the old "EC fully in charge" ways: the EC would ignore KBDCLK except when the system sleeps. during that time (SOC_SLEEP asserted), it would respond to KBDCLK activity by immediately asserting KBDCLK itself, as flow control. when ready, the SoC would instruct the EC to release the flow control.

[wmb@…]

Changing owner to pgf since he is the one running this to ground. Reassign to me or Quozl when the right solution is identified and needs to be deployed in an official build.

[martin.langhoff]

Test in OS18 or later, on C2 build machines.

[wad]

This may also be tested on earlier XO-1.75 laptops (B1 or C1), after they have been modified as shown at:

http://wiki.laptop.org/go/XO_1.75_C1_ECOs#Loss_of_first_keypress_when_suspended

[pgf]

this code is all present in OS18 and Q4C07 and EC 0.3.06, and it works on a modified C1 with all those items freshly installed. (actually, i tested OS19, but i'm sure it worked in 18 as well.)

it will probably not work yet on a modified B1 -- priority was for C1/C2 machines, where the EC has a better idea of whether the SoC is asleep or not.

[erikos]

Hmm, as I have only unmodified B1/B2s I can not test if the fix is working (I can nonly say that the wake-up-keystroke is lost here :) Can someone with an adequate machine at hand please test with os25?

[martin.langhoff]

Tested on ramp units, w OS26. Works!