On Sun, Nov 29, 2009 at 9:42 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 29 Nov 2009, Hans de Goede wrote: >> As well written drivers for devices which do always send isoc packets >> up to wMaxPacketSize, should always submit isoc urbs of wMaxPacketSize, >> changing this inside ehci-sched.c should not impact existing drivers, >> where as it will help hardware which can be told to always send >> packets < wMaxPacketSize, this I would like to propose to change >> ehci-sched.c: iso_stream_init() to use the actual urb size to calculate >> the amount of needed usecs. >> >> 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. > > The correct solution to the problem of limited bandwidth is to have > multiple altsettings, providing support for different levels of > resolution and bandwidth. Of course, only the manufacturer can do > this. > > Alan Stern Hi Alan, You are right about the correct solution. But in a windows dominated world where windows drivers can work around gadget bugs this is difficult. I believe the way windows does this is the driver will send the control packet to the gadget to set the transfer size, then change the host drivers copy of wMaxpacketsize for the isoc endpoint to this new value. At that point things are back in spec. And normal scheduling should work. However, I am not sure that Linux allows drivers to change wMaxPacketSize? How far do we go to support buggy devices? Regards, Steve -- 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
