Opened 5 years ago

Closed 5 years ago

Last modified 20 months ago

#11401 closed defect (fixed)

keystroke which causes resume is lost

Reported by: pgf Owned by: pgf
Priority: blocker Milestone:
Component: ofw - open firmware Version: Development build as of this date
Keywords: Cc: rsmith, pgf, wad
Blocked By: Blocking:
Deployments affected: Action Needed: test in build
Verified: no


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.

Change History (15)

comment:1 Changed 5 years ago by pgf

  • Cc rsmith pgf wad added
  • Component changed from not assigned to ofw - open firmware
  • Owner set to wmb@…

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.

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by 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.

comment:6 Changed 5 years ago by 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.

comment:7 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by wmb@…

  • Owner changed from wmb@… to pgf

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.

comment:10 Changed 5 years ago by martin.langhoff

  • Action Needed changed from design to test in build

Test in OS18 or later, on C2 build machines.

comment:11 Changed 5 years ago by wad

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

comment:12 Changed 5 years ago by 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.

comment:13 Changed 5 years ago by 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?

comment:14 Changed 5 years ago by martin.langhoff

  • Resolution set to fixed
  • Status changed from new to closed

Tested on ramp units, w OS26. Works!

comment:15 Changed 20 months ago by Quozl

  • Milestone 1.75-firmware deleted

Milestone 1.75-firmware deleted

Note: See TracTickets for help on using tickets.