#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 rsmith):

 Replying to [comment:5 pgf]:
 > is all this behavior a regression?  or has it always been this way?  if
 a regression, since when?

 We need to to find this out. We have always had problems with key repeats
 on resume.  It's possible that the suspend speed of the previous kernels
 was slow enough that this didn't happen so much.

 It important to know this because the core of this problem is that for
 some reason when the system suspends the EC sees a read of the keyboard
 data register so it thinks that the break code has been read by the host.
 If this has always been the case and then there is perhaps some sort of
 hardware glitch and solving the root cause may not be possible.  If the
 false key read does not occur on previous releases then there's hope that
 some sort of kernel tweak can solve this.

 Solving it directly in the EC is tricky because you have to interrupt the
 normal path before suspend since the EC isn't doing anything different.
 Its sees a read and goes on to wait for the the next keypress.  By the
 time the EC sees that the system has suspended its too late because the
 data has been lost.

 The 11260 hack was a trivial attempt at a fix and didn't pan out.  A 2nd
 idea I'm having is to use the SCI inhibit system we have for XO-1.  On
 XO-1 the kernel sends an SCI_INHIBIT prior to the suspend so the EC knows
 not to send up an SCI until the system has has a chance to go all the way
 into suspend otherwise XO-1 will hang.  Its unused on 1.5 but all the code
 is still present.  We can possibly use the SCI inhibit period as a
 keypress processing inhibit period.  I can explore that option but I need
 a kernel which sends the SCI INHIBIT command prior to going into suspend.

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