#9631 NORM 1.5-har: DCON doesn't assert correct status during resume

[Zarro Boogs per Child]

#9631: DCON doesn't assert correct status during resume
--------------------------------+-------------------------------------------
           Reporter:  pgf       |       Owner:  wad           
               Type:  defect    |      Status:  new           
           Priority:  normal    |   Milestone:  1.5-hardware-C
          Component:  hardware  |     Version:  1.5-C2        
         Resolution:            |    Keywords:                
        Next_action:  diagnose  |    Verified:  0             
Deployment_affected:            |   Blockedby:                
           Blocking:            |  
--------------------------------+-------------------------------------------

Comment(by wad):

 Are you sure about your terminology ?  I've attached a diagram which shows
 the proper operation as specified in the documentation.   The difference
 is that the 01 status comes from scanline interrupts which occur while the
 DCON is still frozen.   Once it is unfrozen, the scanline interrupt is
 identified by 00.

 I would change the driver timeout to something more reasonable, like 100
 mS.

 Despite the fact that this bug is due to a flaw in either the VX855
 silicon or documentation (failure to maintain the state of a GPIO across
 suspend/resume, despite claiming to do so in the data sheet) it may still
 be possible to work around it.

 The DCON will not unfreeze until the trailing edge of the first VSYNC
 pulse that it sees from the host.  As long as the VX855 display controller
 hasn't been restarted,
 you should still be able to use the scanline interrupt and get 01 as the
 status.

 And if we enable the VX855 display controller in a manner synchronous to
 VSYNC generated from the DCON (see ticket #9869), there shouldn't be a
 glitch upon resume.

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