On Thu, Jul 24, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
Johannes Erdfelt wrote:
This should probably go into the core since every HCD needs it to be set to 0.
If we keep it, yes. But the only use of error_count seems to be in debug printk() calls ... is there a real reason to keep it around? Anyone who really needs it can count urbs for which urb->status != 0, it's clearly not necessary.
You mean the ISO descriptors where status != 0?
If so, I agree. It is superfluous.
Yes, sorry.
And although given URB queueing, "iso_frame_desc" is also superfluous (and also badly named for period != 1msec), I won't suggest that we remove that mechanism from the 2.6 kernel ... :)
So the HC will transfer td[0] during frame 100, then td[4] during frame 276, then td[1] during frame 400, and so on. td[4] will be transferred at the wrong time; it shouldn't be sent until frame 276 _of the next loop_.
I see.
I think we should consider this a bogus request. Maybe we should return an error if we see a driver submit an URB like this.
If it's bogus, yes return an error. Some new errno value.
Kind of. It's not like it doesn't make sense, but that leaving this unbounded would make all of the HCDs more complicated for little gain.
If the calling driver wants to do this, submit it as 2 seperate requests at the correct time.
It'd also be good to let USB device drivers know the biggest iso period that can be scheduled. It's not necessarily the same as the biggest interrupt period, and on EHCI it's also configurable. Otherwise drivers will not be able to tell in advance what requests are legal.
Is it always as large or larger than 1024 frames?
UHCI has a fixed schedule of 1024 frames, so scheduling further than that isn't easy.
If OHCI and EHCI greater than or equal to 1024, might as well make it a fixed limit of 1024 frames.
For EHCI, it's configurable as 256, 512, or 1024 frames. (Except that some hardware may have it fixed at 1024.) We currently default to the shortest possible schedule, some users have observed that it's friendlier to dcache that way (which can matter a lot on some systems).
For OHCI, the periodic schedule has a size of 32 frames, but iso TDs can be scheduled at fairly arbitrary intervals since ISO TDs have a frame counter that the hardware reads.
Non-PCI controllers will likely make their own decisions there too.
It's simple enough to store this info in the usb_bus as it's initialized.
- Dave
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
