On Tue, 28 Oct 2003, Julian Back wrote: > Thanks to all on this list I have got my USB Device Controller Driver > for the SuperH working quite well. It works OK with the mass storage > gadget and I've tested it with Linux 2.4, Linux 2.6, Windows 2000 and > Windows XP hosts. We've also got the SuperH host controller at least > partially working. > > The biggest problem I have had with the UDC is stalling endpoints from > the device. This happens quite a lot when using the mass storage device > with Windows as a lot of unsupported (optional) commands are sent. > > The problem is that the hardware is (again) trying to be too clever. I > set a bit in a register to stall an endpoint. The hardware also has an > internal stall bit for each endpoint (not accessible to software). When > the host attempts a transaction on an endpoint the hardware checks the > internal stall bit and if this is set it sends a stall, if the internal > bit is not set it checks the software settable bit and if this is set it > latches the internal bit and sends a stall. Resetting the software > stall bit does not affect the latched bit, the latched bit can only be > cleared by a Clear Feature command from the host. But the Clear Feature > is processed by the hardware and the software is not informed. If I > leave the software stall bit set there will be another stall on the next > transaction so I need to clear the stall bit.
This sounds very strange indeed. It implies that there's no reliable way for the UDC driver to halt an endpoint. > I do this by starting a > timer to clear the stall bit sometime after I set it. This seems to > work most of the time but it's not 100% reliable as I don't know whether > the host has actually received the stall (or sent the Clear Feature). > > The optimum time delay needed for resetting the stall seems to depend on > the speed of the host system, I've tried it with a 2.2GHz P4 and a > 300MHz Celeron and it doesn't seem possible to have a value that works > well with both systems. I wouldn't expect there to be any good way of making that work. > Unless anyone can suggest an alternative that will make this more > reliable it seems my only solution will be to implement all the optional > mass storage commands that Windows sends so the gadget never has to > stall an endpoint. I've already implemented a few of the missing > commands and this has improved things. I've also added an option to the > mass storage gadget to pad out short replies rather than sending the > short reply and stalling (this seems to be a valid alternative according > to the mass storage spec) and this also makes it more reliable. It's impossible to implement all the commands. More realistic is your other option, switching the gadget to use the no-stall option in the Bulk-only spec. I've been having a discussion about this off-list with Pat LaVarre and David Brownell. Our general conclusion has been that although the no-stall option is better for the controller driver (since it doesn't have to worry about halting endpoints) and might lead to somewhat increased throughput, nevertheless using stalls is probably more interoperable -- and anyway the controller driver _has_ to be able to halt endpoints safely to be more widely useful. I also considered the possibility of adding a "no-stall" option to the storage gadget, but it seemed like such an obscure sort of thing that nobody would ever want to have to worry about it. Are you quite sure there's no way to halt endpoints sensibly on your UDC? Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
