On Tue, 17 Nov 2009, Oliver Neukum wrote: > > Several volunteers and me have experimented with the udelay values. > > See > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/435352/comments/167 > > > > udelay(2000) - works (> 2 people) > > udelay(1000) - works (knuutsen, catscrash) > > udelay(600) - works (catcrash) > > udelay(500) - works (deChrLam with method see # 148, stephan d.) > > udelay(400)- works (knuutsen, stephan d.) > > udelay(375) - breaks (stephan d.) > > udelay(350) - breaks (stephan d.) > > udelay(300) - breaks (catscrash) > > udelay(250) - breaks (stephan d.) > > udelay(100) - breaks (catscrash, stephan d.) > > udelay(50) - breaks (stephan d., jbob) > > udelay(48) - breaks (knuutsen) > > > > It seems that a delay of 400 usec fixes the thing, and that we're > > nowhere near the requested 50 usecs. > > > > Seems like someone either adds the udelay(400) or introduces a proper > > fix (with timers). I am too inexperienced in USB things to fully > > understand the negative implications of the former or do the latter. > > Alan, > > as this affects only buggy chipsets, I'd prefer to just add the required > udelay conditional on a chipset quirk. Do you concur? Do you want me > to do it and close this bug? Sure, go ahead. There's also Bugzilla #14406, which might or might not be the same issue. I'd like it if there was also some way to move the delay into disable_periodic(), before the handshake_on_error_set_halt(), and have it take effect only if the most recent enable_periodic() call occurred less than 400 us previously. Can you do it that way? 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
