On Tue, 28 Oct 2003, David Brownell wrote:
My concern here to cleanup the usb_ep_set_halt() semantics so it was usable for a "real driver", one that didn't need to care about the hardware underneath it. I think we're probably as close as we can get to that state now (BK-current), but we still have things to learn about how SuperH behaves (or doesn't).
One point we haven't addressed is whether Clear-Feature(Halt) also clears the fifo. If it does, we're in trouble again.
One controller does that, but there's a workaround in software that's invisible to the gadget driver. (Implement that clear feature in software, don't let the hardware do it, so you can keep the FIFO blocked until the halt clears.)
If SuperH really can't implement endpoint halts in a usable way (except for ep0), then the options would seem to be (a) kick in the "no-stall" protocol option, at least when SuperH is in use, or (b) just say SuperH can't support FSG. The former sounds a lot better to me...
(a) is a reasonable approach. I'll try to code it up later on.
And it looks like it's the approach that the sample BBB driver from the SuperH designers used too. (Not a Linux driver, and here I'm just going by a PDF appnote Google showed me.) Maybe Julian's patches can help? :)
But if SuperH can't halt endpoints other than ep0, I would expect that to limit its uses pretty severely.
Not really ... most device protocols don't rely on halts at all. Mass storage is an exception; that's how the discussion started! :)
- Dave
------------------------------------------------------- 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
