On Tuesday 22 March 2005 10:28 am, Lothar Wassmann wrote: > Hi, > > > There are also chiprev-specific issues on PXA. If you're using > > a PXA 250, especially with B steppings, you might see issues > > > No, we are only using PXA255, because the 250's were just too buggy. > For the PXA255 I found only one Erratum regarding SET/CLEAR FEATURE > requests that respond with ACK instead of STALL when an illegal > feature is requested and some minor documentation changes.
See what I mean about Intells errata documentation being incomplete? That hardware has quite a few more problems than that. :) > > Hmm, I don't remember seeing such failures. I probably wouldn't > > for "test9", using a fast OHCI host. But "test10" uses some of > > those, and so I'd expect to see such errors with it. Can you > > reproduce the failures with an OHCI host? > > > I ran the test with a PXA270 OHCI HC and the pxa27x_udc driver from: > http://www.free-electrons.com/pub/drivers/pxa27x-0218.patch > but it just hangs after completing test 9 successfully. I have no reason to believe there's a functional pxa27x UDC driver yet. But it'd surprise me if their OHCI was problematic; it's way too easy to license a good working OHCI and toss it into your silicon integration soup. > But the driver only sends out one request at the start of every other > frame, so the problem cannot occur. I came across a description of some limitations of MSFT's USB stack recently, which said it can't issue more than one URB per frame. That might partially explain why you're seeing som of this... > > Are you sure you're not just cutting the end-of-frame timings > > a bit too close? Maybe you shouldn't send the SETUP quite so > > near the next frame's SOF. (If you have control over that...) > > I remember a similar issue with the SL811 code. > > > Unlike the SL811 (which is more or less only a parallel to USB serial > converter) the ISP1362 won't start a transfer that would overrun the > end of a frame. You can safely queue up more data than fits into a > frame and the controller will spread the packets across multiple > frames without errors. There is normally no need to check the > allocated frame time by software. That sounds good ... > Nevertheless I tried to move the SETUP transfer away from the > end of the frame by checking the HcFmRemaining register before > queueing a SETUP request. This indeed made this error disappear. ... that sounds better! - Dave > > Lothar Wassmann > ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
