#6192 HIGH Update.: Lid switch detection only works on AC

Fri Jan 25 03:12:32 EST 2008

#6192: Lid switch detection only works on AC
---------------------+------------------------------------------------------
  Reporter:  cjb     |       Owner:  dilinger
      Type:  defect  |      Status:  new     
  Priority:  high    |   Milestone:  Update.1
 Component:  kernel  |     Version:          
Resolution:          |    Keywords:          
  Verified:  0       |    Blocking:          
 Blockedby:          |  
---------------------+------------------------------------------------------

Comment(by rsmith):

 Replying to [comment:4 dilinger]:
 > 20:39  dilinger> i mean, this isn't a (kernel) bug
 > 20:39  dilinger> PM_GPE0_STS claimed GPIO_WAKEUP_EC was set
 > 20:39  dilinger> it shouldn't have claimed that
 > }}}
 >
 > Remember to tip your waitress!

 I don't tip when they bring me the wrong food.

 A few facts I've discovered:

 - This problem is not firmware specific.  Its sporadic.  Both my newer
 firmwares and Q2D09 will have/not have the issue. The logs below were
 generated with q2d09.
 - The EC is indeed sending a SCI 0x01 but it is NOT in response to the lid
 switch doing anything.  Its in response to the kernel talking to the kbc
 during the normal resume sequence.
 - The kernel incorrectly thinks that the lid event is an EC SCI of 0x00.

 Logs:

 First the EC log:

 {{{
 IBF
 6c 32
 3956020:<- 0
 3956023:SCIInhibit On
 M
 3956061:SCIInhibit Off
 IDEL_STATE

 3962850:-01,
 IBF
 6c 34
 3962858:-1B,
 3962862:<- 0
 IBF
 6c 24
 3962869:WAKE->WLAN
 3962875:<- 0
 IBF
 6c 24
 3962882:WAKE->WLAN
 3962888:<- 0
 IBF
 6c 1c
 RdMask bb
 3962896:<- bb
 IBF
 6c 1b
 3962903:-01,
 3962906:D=ff
 3962910:-02,
 Mask=ff
 3962915:1d<-F 0
 IBF
 6c 84
 3962923:<- 0
 3963572:Wackup SCI
 3963576:SCI:01
 IBF
 6c 84
 3963585:<- 1
 IBF
 6c 84
 3963592:<- 0
 IBF
 6c 1c
 RdMask ff
 3964138:<- ff
 IBF
 6c 1b
 3964144:D=bb
 Mask=bb
 3964151:1d<-F 0
 IBF
 6c 32
 3964159:<- 0
 3964162:SCIInhibit On
 M
 3964200:SCIInhibit Off
 IDEL_STATE
 }}}

 Kernel sends a cmd 32 and the corresponding IDEL_STATE (suspend) happens.
 We see the EC pick up and start processing EC commands a 0x34 an then 2
 0x24s _without_ and indication of an SCI happening.  Now skip forward
 until where you see the "Wackup SCI" and the SCI 0x01.  Just before that
 SCI we see the kernel send down a 0x84 command which is "read SCI queue."
 There has not been an EC SCI so the EC correctly reports zero.
 Then in response to PS2 traffic from the kernel the EC generates a SCI
 0x01.  Then the kernel gets the EC SCI and correctly reads an SCI 0x01 and
 the end of the queue with 2 cmd 0x84's.  Then a bit later we go back into
 suspend.

 The corresponding kern.log filtered by 'grep olpc-'

 {{{
 Jan 25 07:24:04 localhost kernel: [   19.140520] olpc-ec:  running cmd
 0x32
 Jan 25 07:24:04 localhost kernel: [    0.005687] olpc-ec:  running cmd
 0x34
 Jan 25 07:24:04 localhost kernel: [    0.016751] olpc-ec:  running cmd
 0x24
 Jan 25 07:24:04 localhost kernel: [    0.029804] olpc-ec:  running cmd
 0x24
 Jan 25 07:24:04 localhost kernel: [    0.042857] olpc-ec:  running cmd
 0x1c
 Jan 25 07:24:04 localhost kernel: [    0.050898] olpc-ec:  received 0xbb
 Jan 25 07:24:04 localhost kernel: [    0.050914] olpc-ec:  running cmd
 0x1b
 Jan 25 07:24:04 localhost kernel: [    0.053940] olpc-ec:  sending cmd arg
 0xff
 Jan 25 07:24:04 localhost kernel: [    0.054828] platform olpc-battery.0:
 EARLY resume
 Jan 25 07:24:04 localhost kernel: [    0.068184] olpc-ec:  running cmd
 0x84
 Jan 25 07:24:04 localhost kernel: [    0.075222] olpc-ec:  received 0x0
 Jan 25 07:24:04 localhost kernel: [    0.075328] olpc-pm:  SCI 0x0
 received
 Jan 25 07:24:04 localhost kernel: [    1.127124] platform olpc-battery.0:
 resuming
 Jan 25 07:24:04 localhost kernel: [    1.180575] olpc-ec:  running cmd
 0x84
 Jan 25 07:24:04 localhost kernel: [    1.187617] olpc-ec:  received 0x1
 Jan 25 07:24:04 localhost kernel: [    1.187632] olpc-pm:  SCI 0x1
 received
 Jan 25 07:24:04 localhost kernel: [    1.187649] olpc-ec:  running cmd
 0x84
 Jan 25 07:24:04 localhost kernel: [    1.195691] olpc-ec:  received 0x0
 Jan 25 07:24:04 localhost kernel: [    1.195857] olpc-pm:  SCI 0x0
 received
 Jan 25 07:24:04 localhost kernel: [    1.231490] platform olpc-battery.0:
 suspend
 Jan 25 07:24:04 localhost kernel: [    1.280754] platform olpc-battery.0:
 LATE suspend
 Jan 25 07:24:04 localhost kernel: [    1.281191] olpc-ec:  running cmd
 0x1c
 Jan 25 07:24:04 localhost kernel: [    1.290235] olpc-ec:  received 0xff
 Jan 25 07:24:04 localhost kernel: [    1.290252] olpc-ec:  running cmd
 0x1b
 Jan 25 07:24:04 localhost kernel: [    1.292276] olpc-ec:  sending cmd arg
 0xbb
 Jan 25 07:24:04 localhost kernel: [    1.304326] olpc-ec:  running cmd
 0x32
 }}}

 This matches the EC log perfectly.  The kernel issues cmd 32 and then goes
 into suspend.  It gets woken up by a the lid event and then runs a few EC
 commands.  The kernel issues a 0x84 because it  thinks it was woken up by
 the EC.  The result is zero since the SCI queue is empty.  Then a real EC
 SCI shows up a bit later the kernel reads the 0x01 and finishes the SCI
 queue.  Then goes back to sleep because it has missed detecting that a lid
 event was the real source of the wakeup.

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