#1771 HIGH Trial-2: Send SCI events through keyboard queue

[Zarro Boogs per Child]

#1771: Send SCI events through keyboard queue
----------------------------------+-----------------------------------------
  Reporter:  kimquirk             |       Owner:  wmb at firmworks.com
      Type:  enhancement          |      Status:  new              
  Priority:  high                 |   Milestone:  Trial-2          
 Component:  embedded controller  |     Version:                   
Resolution:                       |    Keywords:                   
  Verified:  0                    |  
----------------------------------+-----------------------------------------
Changes (by wmb at firmworks.com):

  * type:  defect => enhancement
  * component:  kernel => embedded controller

Comment:

 The idea is for the EC to send all events through the PS2 (keyboard/mouse)
 queue, instead of sending some through the PS2 queue and others through
 the cmd 6c SCI queue. The PS2 keyboard driver would demux the events,
 sending some to the power manager and others to the normal keyboard input.

 The rationale is:

 a) Right now, when an SCI interrupt wakes up the CPU, it's necessary to
 check both queues, because keystroke wakeups result in PS2 queue entries
 and some other wakeups result in port 6c queue entries.  A keystroke
 wakeup doesn't generate a normal keyboard IRQ, because the interrupt
 controller is off when the keyboard event happens, so you have to "bounce"
 the SCI interrupt over to the keyboard handler anyway.

 b) Accessing the port 6c queue is slow and blocking, so you have to use a
 tasklet to access it safely from an interrupt.

 c) My guess is that the EC code would be simpler if it had only one longer
 queue instead of two separate queues.

 d) This change would move the "policy" decision of where specific events
 go solidly into the kernel, because the EC would not have to choose which
 queue to put individual events in.

 This would require a change to the existing PS2 code in the kernel.  It
 might be better to fork the PS2 driver and make an OLPC-specific one.
 That might be worthwhile in any case, because the existing driver has to
 handle PS2 variants that don't exist on OLPC, and the OLPC PS2 is somewhat
 idiosyncratic as it is.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1771#comment:2>
One Laptop Per Child <http://laptop.org/>