On Tue, 30 Oct 2012, Sebastian Andrzej Siewior wrote: > * Alan Stern | 2012-10-29 12:04:10 [-0400]: > > >Was that really the problem? My memory is not what it was three weeks > >ago... > > > >If so, there's a simpler solution. The list_for_each_entry_safe() > >loop in dummy_timer() should not consider URBs that were added after > >the loop started. That ought to be easy enough to implement. (One > >solution: Increment a counter each time dummy_timer() runs, and store a > >copy of the counter value in each urbp during submission. Exit the > >loop when the stored counter value in urbp is equal to the current > >counter.) > > > >This will prevent you from getting into an infinite loop in atomic > >context. Of course, the resubmission problem would still exist, but > >that's true with non-emulated gadgets too. > > > >Alan Stern > > Okay. So now I added an interval check. It looks better. However if you > prefer the "don't check URBs that were added during completion" way then > I could try that. This would start that I remove the "restart:" label > which is used after URB completion. Real HCDs might or might not check the status of URBs that were submitted during a completion. While it probably doesn't matter very much, I think we should not check them, on the theory that a just-submitted URB most likely hasn't had time to complete. > --- > dummy_urb_enqueue() now assigns the endpoint to the qh structure if it > finds one. Plus in case of an INT URB we track the interval so we don't > schedule the packet too often. In theory you should implement an entire scheduler for periodic transfers so that the bandwidth doesn't all get used up. In practice this isn't likely to matter much, because one device isn't likely to use all the bandwidth. > If UDC disables the endpoint (on the device side) the endpoint information > is removed from the qh as well. I think real HW would timeout on > transfer (and return -EPROTO). Yes. You should do the same thing. The host isn't supposed to know anything about what the device does, except for what it can learn over the bus. > With this change the, the busy loop which occurs if the host always > re-queues an INT URB in the completion is gone because we "skip" this qh > until the interval. Your patch uses jiffies for comparison of time intervals. This won't work well in situations where HZ is too small. It would be better to count the timer callbacks and let each callback correspond to one frame (or 8 uframes). Or maybe adjust it dynamically, based on the actual time interval between callbacks. Alan Stern -- 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
