#2767 HIGH Trial-3: Problem with watch-battery in OFW.

[Zarro Boogs per Child]

#2767: Problem with watch-battery in OFW.
----------------------------------+-----------------------------------------
  Reporter:  garysu               |       Owner:  David.Lin
      Type:  defect               |      Status:  new      
  Priority:  high                 |   Milestone:  Trial-3  
 Component:  embedded controller  |     Version:           
Resolution:                       |    Keywords:           
  Verified:  0                    |  
----------------------------------+-----------------------------------------
Comment (by rsmith):

 Replying to [comment:1 wmb at firmworks.com]:
 > The "EC port 6c output buffer timeout" message occurs because the EC
 port 6c command sequence takes too long to complete.  The timeout in OFW
 is currently set to 1 second, which ought to be enough time for the EC to
 respond.
 >
 > We need to either fix the EC code to handle port 6c more reliably, or
 eliminate port 6c commands entirely, instead using AUX port multiplexing
 to transmit commands and results via the normal PS/2 port registers.

 I've looked at this a bit and there still appears to be some sort of race
 condition in the EC code dealing with the IB/OB flags.  The length of the
 timeout will not matter.  When it happens the flags are incorrectly
 set/cleared and it will never change until the next command is issued.

 Finding this issue has been difficult because even with minimal debugging
 statements enabled in the code the race seems to go away.  While at QSMC I
 left the watch-battery command (against my debug code) with a 20ms delay
 running for many hours with no timeouts.

 The debugging statements are wrapped with #defines and its only been in
 the last few builds that the EC protocol debugging was disabled.

 I'll going to work on this some more using some other debug methods that
 don't involve debug prints out the EC serial port.

 A short term fix until the race is found or until we refactor all the ec
 commands into PS/2 commands is to decrease the timeout to a much smaller
 value and then retry the command if it timesout.  This is what the kernel
 is currently doing and its working quite well.

-- 
Ticket URL: <https://dev.laptop.org/ticket/2767#comment:3>
One Laptop Per Child <http://laptop.org/>