On Tue, Oct 12, 2004 at 01:57:43PM -0700, David Brownell wrote: > On Tuesday 12 October 2004 9:41 am, Russell King wrote: > > > > I suspect that problem isn't associated with Lothar's code at all; > > > a lot of folk have been running into problems like that lately. > > > > Actually it is. After running the SL811HS against the SA1110 UDC driver, > > the problem comes out immediately. The SL811HS driver is _NOT_ following > > the protocol for bringing a device out of "default suspend" state. > > > > Sure, it's resetting the bus, but then it's waiting for about 10ms before > > enabling SOFs, by which time the device has given up completely and gone > > back to suspend mode. > > > > With this kind of bug, this driver could never have worked. > > Hmm, that sounds like a longtanding issue in OHCI that I finally > fixed not long ago. Fix is in the MM tree; it finally mattered on some > hardware. Basically initialization was split into two routines, and > a 2 msec timeout spanned both ... preemptibly! It was amazing > to me that it ever worked at all reliably. The fix was obvious.
No - this bug is completely specific to the way the SL811 code is interacting. The basic sequence of events is: 1. receive interrupt for insertion/removal. trigger bottom half 2. bottom half starts looking at the insert/remove state, and delays 10ms 3. bh discovers the device speed and enables SOFs 4. some time later, the USB subsystem issues a reset, which disables SOFs 5. reset is released 10ms later, and triggers an insert/remove interrupt. this triggers the bottom half again. 6. bottom half runs again, and again delays 10ms 7. SOFs are re-enabled Unfortunately, between steps 5 and 7 is some 10ms delay which is outside the suspend delay of any peripheral device I have here. So, the device refuses to accept its address. My solution to this - rip out the device speed discovery from the BH and make it merely trigger the relevant connection change events. Then, intercept the hub control path and handle the reset event ourself doing everything that the USB spec requires in a linear progression, from detecting the device speed to issuing and releasing the reset, to enabling the generation of SOFs. This gives 100% reliability for this section of the code, and hey - it's a hell of a lot more understandable what's actually going on in there. Unfortunately, many other problems appear to remain, including but not limited to bad scheduling of transfers - I regularly see the timer handler killing transfers off with bad consequences. I can generally get devices connected directly to the chip to be recognised, but anything behind a hub seems a dead loss. It looks like it'll take a fair amount of work to sort this problem out - and until it is sorted, the whole driver seems to be at best unreliable. I'm just hoping that there's sufficient timescale available for this. Even so, I do wonder whether it would be far better to start from scratch with a clean design. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
