On Wednesday 13 October 2004 1:59 am, Russell King wrote: > On Tue, Oct 12, 2004 at 07:01:41PM -0700, David Brownell wrote: > > > > 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. Root hub resets are supposed to last at least 50msec... it can be in pulses of 10msec if the gaps between them are short enough. > 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. I see. So that HCD code didn't know enough to ignore that IRQ in that context, until you refactored it a bit. > > 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. Good... > 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. Except that the HCD must do a "hub" emulation in any case, so that it can talk sanely to usbcore ... and it turns out that the OHCI registers are almost bit-for-bit compatible with the relevant hub class status! So that particular issue can't be dodged so easily. > > 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. And of course isn't the only Linux architecture where HZ=100. This is a case where the OHCI frame counter sometimes helps ... not for timers of 1msec though. > > > 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.) If USB were a relatively simple protocol, it'd be easier to get this straight. But it's not; the learning curve (as I think you've noticed!) is a bit larger than usual. > That kind of instability is wholely unsuitable. No kidding! - Dave ------------------------------------------------------- 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
