> By performing iterative port suspend and resume (which results in function > suspend and resume), ring expansion failure is observed. Attached device > has multiple interfaces for which interface host drivers are unlinking the > urbs during function suspend and submitting urbs during resume. > > For the cases when dequeue ptr is close to the end of deq segment, value > of num_trbs_in_deq_seg (= ring->dequeue - ring->deq_seg->trbs) becomes > high when function suspend is over. At the time of resume this high value > is causing to trigger ring expansion in the middle of submitting > urbs(ring->num_trbs_free < num_trbs + num_trbs_in_deq_seg). All the > interface host drivers only request one TRB per urb (num_trb =1). Ring > expansion logic is doubling the num of previously allocated segments every > time. This is causing the num of segments to grow at fast pace (at the > time of failure, one of the ep rings num_seg was 128), even though it is > also increasing num_trbs_free. Something must be miscalculating num_trbs_free during suspend/resume. ... > I was trying to think of some options to reduce ring expansion with > respect to suspend resume scenario: - > 1) Can we reset enq and deq ptr to point to ep_ring first seg once all the > urbs are unlinked (function suspend)? > 2) Can we free the segments at the time of suspend and allocate segments > back when resume happens? > > In general, as per the spec can we also implement shrinking of transfer > ring (4.9.2.4). I think the bulk tx code should be willing to queue urb when there aren't enough ring entries. Then all the code to handle multiple ring segments could be ripped out. (possibly allocating 128 entries for some of the rings - only 2k). This would simplify a lot of code. David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
