#11260 NORM Not Tri: i8042 data loss over suspend/resume

[Zarro Boogs per Child]

#11260: i8042 data loss over suspend/resume
-------------------------------------------+--------------------------------
           Reporter:  dsd                  |       Owner:  rsmith     
               Type:  defect               |      Status:  new        
           Priority:  normal               |   Milestone:  Not Triaged
          Component:  embedded controller  |     Version:  1.5-C2     
         Resolution:                       |    Keywords:             
        Next_action:  never set            |    Verified:  0          
Deployment_affected:                       |   Blockedby:             
           Blocking:                       |  
-------------------------------------------+--------------------------------

Comment(by dsd):

 Richard reproduced and has found a possible workaround in the EC. Testing
 with http://dev.laptop.org/~rsmith/11260.rom

 Observations:

 1. When suspending with `sleep 5; echo mem > /sys/power/state` (i.e. no
 keypresses for a long time before suspend) and resuming with the power
 button, a 1c (make enter) 9c (break enter) interrupt sequence is correctly
 received before suspend, however on resume a duplicate 9c (break enter)
 interrupt is received.

 2. The same experiment repeated but waking the system with the 'j' key
 results in 1c,9c before suspend, and 24,a4 on resume. (all correct)

 3. Reproducing the conditions described on this ticket, where the system
 suspends on a 1c event (make enter) before the 9c break interrupt has been
 received, upon power-button-triggered resume, the Linux-simulated 'soft'
 interrupt receives a 9c interrupt, then Linux receives a 'real' interrupt
 with no data.

 4. If the system suspends on a 1c event (make enter) before the 9c break
 interrupt has been received, if I resume with the 'j' key the wrong thing
 happens. The system wakes with 24,a4 (j make, j break) codes, but no '9c'
 enter break is ever received, so Linux continues believing that enter is
 held down.

 5. If the system suspends on a 1c event (make enter) before the 9c break
 interrupt has been received, if I resume with the 'j' key the wrong thing
 happens. The system wakes with 1c,9c (enter make, enter break). However,
 this interrupt pattern suggests that I had held enter down long enough for
 one interrupt-autorepeat to happen, and then released just once. In
 reality, I pressed and released enter once to suspend, and pressed and
 released enter once to resume.


 In summary, I think (1) is probably no big deal on its own, (3) similarly
 a bit strange behaviour but unlikely to have adverse effects, (4) is a
 problem however because it would cause Linux/X to effectively ignore the
 next keypress of the "stuck key", and (5) is also a problem because I
 effectively lose a keypress/keyrelease from the userspace perspective.

-- 
Ticket URL: <http://dev.laptop.org/ticket/11260#comment:4>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system