On Tue, 14 Dec 2010, Sergej Pupykin wrote:
> At Tue, 14 Dec 2010 12:07:34 -0500 (EST),
> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > Yes, that's probably true.
> >
> > I don't know if your program will work if it does Set-Config(0). The
> > device may not accept the DFU requests in that state.
> >
> > If necessary, you can force all control transactions to be spaced at
> > millisecond intervals by editing drivers/usb/host/uhci-q.c in the Linux
> > source. At the end of uhci_submit_control(), remove the lines saying
> >
> > if (urb->dev->speed == USB_SPEED_LOW ||
> > urb->dev->state != USB_STATE_CONFIGURED)
> > skel = SKEL_LS_CONTROL;
> > else {
> > skel = SKEL_FS_CONTROL;
> > uhci_add_fsbr(uhci, urb);
> > }
> >
> > and replace them with the single line:
> >
> > skel = SKEL_LS_CONTROL;
>
> I checked it firstly and it works! Thank you very much for this
> workaround.
You're welcome.
> I don't know how Windows guesses to slow it down. Can it be Linux HCD
> bug or device is slightly broken and windows has workaround? Btw,
> MacOS X also does not work in the same way as Linux.
My guess is that this is a bug in the device. It _should_ be able to
work no matter how fast the host tries to transfer data -- the device
should simply delay the transfer until it is ready.
Perhaps enough devices share this same bug that Windows has a
workaround for it. There is a similar workaround in uhci-hcd; as you
can see from the code above, the driver uses SKEL_LS_CONTROL if the
device isn't in the CONFIGURED state. I don't know exactly how Windows
works here -- maybe it _always_ uses slow control transfers for
full-speed devices.
It would be very interesting to test your device under Windows and
Linux on a computer with an OHCI controller instead of UHCI. With
OHCI, there is no way to tell the hardware to use slow transfers.
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
