On Tue, Oct 12, 2004 at 07:01:41PM -0700, David Brownell wrote: > On Tuesday 12 October 2004 3:16 pm, Russell King wrote: > > 3. bh discovers the device speed and enables SOFs > > 4. some time later, the USB subsystem issues a reset, which disables SOFs > > Strictly speaking, speed isn't known until after port reset.
USB1.1 (which is what this device implements) provides two options: 1. detect the speed immediately before USB bus reset 2. detect the speed immediately after USB bus reset > > 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 > > SOFs have to start within something like 3msec after > the reset finishes. What's with punting all this to a BH? The badly written SL811 driver code. 8) Basically what happens is that the USB code asks for a port reset. The port reset emulation places the USB bus in SE0 state for 10ms and then releases it. It does nothing else. SE0 also looks like a device disconnect, so the chip reasserts its insert/remove interrupt, which in turn triggers the BH. If the BH then decides that a device is connected (which takes 10ms), it will enable SOFs. So, the time between reset being released and SOFs being re-enabled is 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. > > 10msec could be a task preemption, but such delays should be > designed out of existence. mdelay() isn't task preemption, especially when it is used in a BH. > > 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. > > Is there any problem having khubd do its usual job? There are > root hub requests for all the key things: reporting port change > events, resetting ports, disabling them, suspending, resuming, > retrying, and all that good stuff. I think with my approach we are getting closer to allowing khubd to do its usual job. However, the small problem that in order for the rest of the "OHCI" emulation to continue working, we need to emulate the port status updates in this code accurately - other parts of the OHCI code depend on this. Sure, if the emulation could be ripped out tomorrow, this would probably be a good thing. > > 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. > > Well, that's all outside scope of OHCI, it doesn't have a timer > doing anything like that. Software scheduling probably takes > a while to get right, especialy with periodic transfers (what > you'd use to get status updates from that hub). It may be outside the scope of OHCI, but I'm describing a problem which I'm seeing there. What's more is that the driver assumes that it can set 1ms timers on ARM platforms... unfortunately they only have a resolution of 10ms. > > Even so, I do wonder whether it would be far better to start from > > scratch with a clean design. > > That's probably not the fastest way to working code, unfortunately. > Unless maybe you've already written waaay too many HCDs! I doubt that trying to hack around this OHCI emulation is going to end up being faster - it's virtually impossible to see what's going on, and just when you think you managed to get the thing working, new problems crop up when you try a different bus topology (eg, throwing in a USB hub.) That kind of instability is wholely unsuitable. -- 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
