On Thu, Sep 25, 2014 at 07:43:35PM +0000, Paul Zimmerman wrote: > > From: Paul Zimmerman > > > > > From: Felipe Balbi [mailto:balbi@xxxxxx] > > > > > > On Wed, Sep 24, 2014 at 09:40:37PM -0500, Felipe Balbi wrote: > > > > On Thu, Sep 25, 2014 at 01:37:05AM +0000, Paul Zimmerman wrote: > > > > > > > > Then, after the host cleared the halt, the gadget apparently sent the > > > > > > > > data that _should_ have been sent previously. The host was expecting > > > > > > > > to receive the CSW at this point, so there was an overflow error. > > > > > > > > That's what caused the host to perform a reset. > > > > > > > > > > > > > > > > Evidently this UDC implements the set_halt method incorrectly. > > > > > > > > According to the kerneldoc for usb_ep_set_halt: > > > > > > > > > > > > > > > > * Attempts to halt IN endpoints will fail (returning -EAGAIN) if any > > > > > > > > * transfer requests are still queued, or if the controller hardware > > > > > > > > * (usually a FIFO) still holds bytes that the host hasn't collected. > > > > > > > > > > > > > > damn old bugs :-) I'll fix that up and Cc stable. > > > > > > > > > > > > alright fixed. Below you can see a combined diff which I'll still split > > > > > > into patches so they can be applied properly. > > > > > > > > > > [ snipped patch which grubs around in the GDBGFIFOSPACE registers ] > > > > > > > > > > Ick. That shouldn't be necessary. The Synopsys vendor driver works > > > > > > > > you need to make sure that both there are no pending transfers and FIFO > > > > is empty in case of IN endpoints. Databook itself says (sorry, forgot > > > > the section and no access to the docs right now) that to figure out if > > > > the FIFO is empty, application can use GDBGFIFOSPACE. Do you have any > > > > better ideas ? > > > > > > oh, and btw... I only noticed the failure with Linux. I mentioned that > > > it, though flakey during start, worked very stably against Mac OS X. > > > Perhaps Windows is also more forgiving ? > > > > Yeah, I see you said it only fails with 3.17-rc on an embedded platform > > you have. Can you say which platform that is? Do you know whose xHCI > > controller it uses? > > > > > Can you share a little more details on what you guys did to get it to > > > work without making sure FIFO is empty ? I can't really understand how > > > you'd cover all cases otherwise... > > > > See my other email, I will try to find the fix for the similar issue > > that we saw. > > OK, it looks like that issue is not related to this one. We were > accidentally setting the Stream Capable bit in the endpoint > configuration for all bulk EPs, not just stream-enabled ones. That > caused several strange behaviors, including the Set Stall command > not working. ok, this it not about Set Stall not working, however, it's about making sure we don't stall at the wrong time :-) -- balbi
Attachment:
signature.asc
Description: Digital signature
