On Thu, 17 Nov 2005, Pete Zaitcev wrote: > On Thu, 17 Nov 2005 13:39:23 -0600, "Frantz, Chris" <[EMAIL PROTECTED]> wrote: > > > What do you think about making IDLE_TIMEOUT a module parameter with a > > reasonable default value? > > Proliferation of knobs is not a good idea in general. I can do that > in RHEL 4, but I am going to resist it in the mainline until it's shown > that nothing else works. > > I would rather consider looking into usb-uhci and taking its algorithm > of dealing with FSBR. The small problem is, if I take this action item, > it's going to take approximately eternity, give or take some forevers. > I hoped to ride Stern's back here...
If Chris can determine a useful and reasonable value (not too large) for IDLE_TIMEOUT, I won't mind changing it. Making it a parameter doesn't seem to be generally useful. Ultimately the correct approach will involve monitoring the number of TDs completed during a time interval. When this number remains at 0, FSBR should be turned off. The next TD in each active endpoint queue can be marked to generate an interrupt on completion, so as soon as the tranfers resume the driver will know to turn FSBR back on. FSBR tracking should not involve timeouts for individual URBs. It should be tied to endpoints, not URBs. The current structure of the driver makes this difficult; that's one of the planned major changes. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
