Opened 7 years ago

Closed 7 years ago

#1710 closed defect (fixed)

EC blocks for long periods while processing game buttons

Reported by: rsmith Owned by: David.Lin
Priority: blocker Milestone: Trial-2
Component: embedded controller Version:
Keywords: power Cc: rsmith
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no

Description (last modified by rsmith)

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.

Attachments (1)

tek00001.png (54.4 KB) - added by rsmith 7 years ago.

Download all attachments as: .zip

Change History (12)

Changed 7 years ago by rsmith

comment:1 Changed 7 years ago by rsmith

  • Description modified (diff)

comment:2 Changed 7 years ago by jg

  • Milestone changed from Untriaged to Trial-2

comment:3 Changed 7 years ago by jg

  • Component changed from distro to embedded controller

comment:4 Changed 7 years ago by jg

  • Keywords power added

comment:5 Changed 7 years ago by kimquirk

  • Milestone changed from Trial-2 to BTest-4

Would like to fix this on the B4 boards.

comment:6 follow-up: Changed 7 years ago by jg

  • Milestone changed from BTest-4 to Trial-2

comment:7 in reply to: ↑ 6 Changed 7 years ago by rsmith

Replying to jg:

David Woodhouse made a kernel change the mitigates this issue by moving the blocking call out of the irq handler.
There is also some test code from quanta that aims to solve it yet but its not yet been fully tested.

comment:8 Changed 7 years ago by David.Lin

Richard,
Does EC(PQ2C19) fix this one?

comment:9 Changed 7 years ago by David.Lin

In PQ2C19, EC will keep the game key into queue as SUS_ON is low.
The game key will not lose.

comment:10 Changed 7 years ago by jg

  • Cc rsmith added

comment:11 Changed 7 years ago by jg

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.