On Sun, 29 Nov 2009, Hans de Goede wrote: > Hi, > > On 11/29/2009 06:42 PM, Alan Stern wrote: > > On Sun, 29 Nov 2009, Hans de Goede wrote: > > > >> Hi, > >> > >> I've the following problem, which has lead me to believe that for > >> scheduling isoc streams ehci-sched.c should uses the actual isoc > >> urb packetsize instead of wMaxPacketSize. > > > > This can't be done. The URB packet size isn't known at the time the > > scheduling is performed. That is, the packet size for the _current_ > > URB is known but not the sizes for URBs to be submitted in the future. > > > > That is true, but I would assume that it is normal for all urb's > in an isoc stream to be the same packet size, Normal perhaps, but it's very common for the packet sizes to vary. For example, consider an audio stream running at the usual CD data rate: 44100 samples per second. That's 44.1 samples per frame, so one out of every ten packets will have to be larger than the others. > after scheduling one could > check that future URB's have the same size and if not error out. The > same is already done for interval. The usage of the interval field is probably going to change as well -- it will become purely an output parameter. On the other hand, it has been suggested that new programming interfaces be added to the core, allowing drivers to change the interval and maxpacket values. This would affect both the host's copies of the descriptors and the bandwidth allocation. But there is a kind of chicken-and-egg problem. If the values provided by the device would require too much bandwidth, they won't get installed and the driver won't get loaded. Hence it won't have a chance to change the values. > >> I'm willing to write a patch for this, but have not done so far, because > >> if this idea gets shot down it is little use to spend time on such a > >> patch. > > > > This isn't a good idea. The trend for the future is to allocate > > bandwidth as soon as a config or an altsetting is installed, based on > > the descriptor values. (The xHCI driver for USB 3.0 already works this > > way.) In your case the allocation would fail even before the driver > > got a chance to modify the camera's register values. > > > > And usb3 probably has enough bandwidth to make this makes sense, maybe usb2 > even has enough bandwidth for this to make sense but usb1 (which I know I did > not say this was about, again this is my bad, sorry), does not have enough > bandwidth. No, no, no. The amount of bandwidth is determined by the speed of the bus, not by which version of the spec is supported. It's entirely possible for parts of a USB-3.0 bus to run at high speed or at full speed. In fact, they are _forced_ to run at these speeds if they are behind a USB-2.0 or USB-1.1 hub. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
