On Tue, 5 May 2009, Jason Wessel wrote: > The problem that this patch tries to solve is that data is lost > because there are too many outstanding transmit urb's. > > The question is what is the right way to force the controller to catch > up, and ideally let the kernel do some other things in the mean time? What do standard serial port drivers do? > This patch takes the route of forcibly polling the hcd device to drain > the urb queue and initiate the bulk write call backs. > > NOTE this patch is not signed off, it is a question of what is the > right way to do this? This patch is highly questionable. Is the idea to force the HCD to search for completed URBs before the host controller has issued a completion interrupt? Wouldn't it be better instead to use more URBs? Besides, why should there be too many outstanding transmit URBs? A normal serial debugging port running at 115200 baud can transmit no more than 12 bytes per ms. You should be able to surpass that using only three URBs! In fact, if you buffer up to 8 bytes per URB then with only two URBs you could send 64 bytes per ms, which is equivalent to 640000 baud. Do you really need to go more than (say) ten times faster than that? Even if people do agree this is a reasonable thing to do (which I doubt), the poll_hcd_irq() code doesn't belong hidden away in serial/usb_debug.c. It belongs in core/hcd.c. 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
