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. > Some webcams, at least those based on stv06xx > bridges, have only 1 alt setting, Are the manufacturers aware that this is a violation of the USB 2.0 specification? > but they have a register which allows > one to tell it to send isoc frames which are never bigger then the value > set in the register. I've tested this and it works as advertised, > when you create isoc urbs with a size < wMaxPacketSize, then normally > when trying to stream from the camera, you will get -EMSGSIZE errors (iirc) > as the camera sends isoc frames, larger then the buffers in the isoc urbs > created. > > But if you then write the size you created the isoc urbs with to the register > in question, things will work. So this seems to works as advertised. > > I would like to use this feature of the camera to make it work in cases > where there is another isoc stream also active (for example a usb 1.1 audio > device) and thus there is not enough bandwidth to make the camera stream > with wMaxPacketSize sized isoc urbs, so usb_submit_urb() will fail > with -ENOSPC. > > But even if I make the packets smaller (and thus using less > bandwidth) I keep getting -ENOSPC, as ehci-sched.c: iso_stream_init() > does not look at the size of the submitted urb, but just assumes > wMaxPacketSize, which in case of these webcam simply is not necessarily > true. > > 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 -- 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
