#1710 BLOC Untriag: EC blocks for long periods while processing game buttons

Zarro Boogs per Child bugtracker at laptop.org
Thu Jun 14 05:31:13 EDT 2007


#1710: EC blocks for long periods while processing game buttons
----------------------+-----------------------------------------------------
  Reporter:  rsmith   |       Owner:  David.Lin
      Type:  defect   |      Status:  new      
  Priority:  blocker  |   Milestone:  Untriaged
 Component:  distro   |     Version:           
Resolution:           |    Keywords:           
  Verified:  0        |  
----------------------+-----------------------------------------------------
Old description:

> The EC blocks for long periods when the game keys are pressed.  I have
> seen as much as 150mS but 90mS is typical.
>
> This blocking period happens when the key is first depressed.  So on
> resume from a host CPU suspend to ram if the key bounces or is pressed
> twice quickly the EC will block the processing of commands issued to it
> from the kernel and cause the kernel to issue an EC command timeout
> message.
>
> Please refer to the attached scope trace of a resume function and the
> processing of EC command 0x24 (Wake WLAN). When the game key is pressed
> twice very quickly.
>
> To understand this trace you need to know:
>
> I hijacked the Battery L0 and L1 signals from the EC and used them as
> debug flags.
>
> Channel 4 (Green) markes the time from which an LPC interrupt happens to
> when the IBF flag gets clear.  The LPC interrupt handler sets this bit
> low and then the main loop code that actually does the processing clears
> IBF and sets this bit high.
>
> Channel 2 (Blue) is the duration of the function that processes the game
> buttons. Upon entry into the function the bit is set low and when it
> exits the bit is set high.  This function is called every 10mS to check
> for game key presses.
>
> Channel 1 (yellow) is the WLAN wake up signal.  When this signal is
> strobed low the 0x24 command is complete.
>
> Channel 3 (purple) is the MAIN_ON signal to the CPU core voltage.
>
> So what happends here is:
>
> - The host CPU is in suspend.. MAIN_ON is low... The user presses the
> game button twice in rapidly.
> - The EC detects that a game button has been pressed.  It blocks in the
> game button processing function for about 95mS.  Then the 2nd game button
> press happens.
> - Inbetween the 2 game key presses the EC code issues the wakup SCI to
> the host.
> - Main on is enabled and the host starts to process the resume path
> - 25mS after resume was started the kernel issues a EC cmd 0x24 to wakeup
> the WLAN.
> - The EC however is still processing the game buttons.  After 60mS the
> game button function exits
> - The main loop then processes the 0x24 command and the WLAN wake signal
> is asserted
>
> The net result is that the kernel has to wait 60mS until it can issue the
> next command to the EC.

New description:

 The EC blocks for long periods when the game keys are pressed.  I have
 seen as much as 150mS but 90mS is typical.

 This blocking period happens when the key is first depressed.  So on
 resume from a host CPU suspend to ram if the key bounces or is pressed
 twice quickly the EC will block the processing of commands issued to it
 from the kernel and cause the kernel to issue an EC command timeout
 message.

 Please refer to the attached scope trace of a resume function and the
 processing of EC command 0x24 (Wake WLAN). When the game key is pressed
 twice very quickly.

 To understand this trace you need to know:

 I hijacked the Battery L0 and L1 signals from the EC and used them as
 debug flags.

 Channel 4 (Green) markes the time from which an LPC interrupt happens to
 when the IBF flag gets clear.  The LPC interrupt handler sets this bit low
 and then the main loop code that actually does the processing clears IBF
 and sets this bit high.

 Channel 2 (Blue) is the duration of the function that processes the game
 buttons. Upon entry into the function the bit is set low and when it exits
 the bit is set high.  This function is called every 10mS to check for game
 key presses.

 Channel 1 (yellow) is the WLAN wake up signal.  When this signal is
 strobed low the 0x24 command is complete.

 Channel 3 (purple) is the MAIN_ON signal to the CPU core voltage.

 So what happends here is:

 - The host CPU is in suspend.. MAIN_ON is low... The user presses the game
 button twice in rapidly.

 - The EC detects that a game button has been pressed.  It blocks in the
 game button processing function for about 95mS.  Then the 2nd game button
 press happens.

 - In between the 2 game key presses the EC code issues the wakup SCI to
 the host.

 - Main on is enabled and the host starts to process the resume path.

 - 25mS after resume was started the kernel issues a EC cmd 0x24 to wakeup
 the WLAN.

 - The EC however is still processing the game buttons.  After 60mS the
 game button function exits.

 - The main loop then processes the 0x24 command and the WLAN wake signal
 is asserted.

 The net result is that the kernel has to wait 60mS until it can issue the
 next command to the EC.

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



More information about the Bugs mailing list