#9423 NORM 1.5-fir: Stabilize OFW USB handling on XO-1.5

[Zarro Boogs per Child]

#9423: Stabilize OFW USB handling on XO-1.5
-------------------------------------------+--------------------------------
           Reporter:  wmb at firmworks.com    |       Owner:  wmb at firmworks.com
               Type:  defect               |      Status:  reopened         
           Priority:  normal               |   Milestone:  1.5-firmware     
          Component:  ofw - open firmware  |     Version:  1.5-B2           
         Resolution:                       |    Keywords:                   
        Next_action:  diagnose             |    Verified:  0                
Deployment_affected:                       |   Blockedby:                   
           Blocking:                       |  
-------------------------------------------+--------------------------------
Changes (by wmb at firmworks.com):

  * status:  closed => reopened
  * next_action:  test in release => diagnose
  * resolution:  fixed =>


Comment:

 Replying to [comment:13 wmb at firmworks.com]:
 > Additional information describing a similar failure:
 >
 > If the initial delay is set to 0, so that polling begins immediately
 after attaching a new queue head to the async list, other types of
 transactions often fail.  Specifically, the "get descriptor" transactions
 on the control pipe, which are done during device probing, often fail, so
 that the driver cannot identify the devices.
 >
 > This initial failure only happens when the EHCI Sleep Timeout (D16F4
 Rx4b[6:5]) is set to "11".  When that field is set to "00", the initial
 failures do not occur, even with initial delay = 0.

 I now understand and have a fix for this "similar" initial-delay problem,
 but the original problem persists.  The cause of the initial-delay problem
 is a software error. The polling code was looking for the active bit in
 the token field of the queue head's transfer overlay to become 0.  That is
 problematic because it takes some time for the host controller to "perform
 the overlay", in which it copies the transfer descriptor data into the
 overlay area.  Before that has happened, the active bit will be 0, so if
 the polling happens immediately, it will mistake that 0 for "transfer
 done", when in fact the transfer has not yet started.

 The fix is to first check that the queue head's "current pqtd" field is
 nonzero, and if so, access the done bit in the transfer descriptor instead
 of the one in the overlay area.  With that fix (and 0 initial delay), the
 get-descriptor transactions succeed.

 This fix does NOT affect the original problem - timeouts still occur with
 the Kingston DataTraveler device.

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