#9983 HIGH 1.5-sof: Battery charging has race if EXT power bounces quickly

[Zarro Boogs per Child]

#9983: Battery charging has race if EXT power bounces quickly
---------------------------------+------------------------------------------
 Reporter:  rsmith               |                 Owner:  rsmith            
     Type:  defect               |                Status:  new               
 Priority:  high                 |             Milestone:  1.5-software-later
Component:  embedded controller  |               Version:  not specified     
 Keywords:                       |           Next_action:  code              
 Verified:  0                    |   Deployment_affected:                    
Blockedby:                       |              Blocking:                    
---------------------------------+------------------------------------------
 If the external power bounces quickly then the EC will turn off the IO
 controlling the charging mosfet but other parts of the code will fail to
 detect the change.  Thus the result is that the battery is not getting
 charged but the charging LED is enabled and the battery code thinks its
 charging.

 The core of the problem is that there are several different parts of the
 code that frob the charging state and they get out of sync.  Each has its
 own logic.  Fixing this properly where only 1 system makes the charge/no
 charge decision will involve a fair bit of refactoring in various parts of
 the code.  Enough that I don't want to do it so close to mass production.

 EC code 1.9.21 contains a workaround of extending the debounce time for
 EXT power loss from 120ms to 500ms.  In my tests this seems to give enough
 time for all parties to decide we lost EXT power.
 Ver 1.9.21 also has the charge LED tied to the state of the IO pin for the
 mosfet so if the race does still occur at lest the EC wont lie to you.

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