On Sat, May 08, 2010 at 03:45:41PM -0700, Mauro Carvalho Chehab wrote: > Jean-Francois Moine wrote: > > On Fri, 7 May 2010 09:39:16 -0300 > > Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > > > >> == Gspca patches - Waiting Jean-Francois Moine > >> <moinejf@xxxxxxx> submission/review == > >> > >> Feb,24 2010: gspca pac7302: add USB PID range based on > >> heuristics http://patchwork.kernel.org/patch/81612 > >> May, 3 2010: gspca: Try a less bandwidth-intensive alt > >> setting. http://patchwork.kernel.org/patch/96514 > > > > Hello Mauro, > > > > I don't think the patch about pac7302 should be applied. > > > > > The patch about the gspca main is in my last git pull request. > > (c/c Sarah) > > I also didn't like this patch strategy. It seems a sort of workaround > for xHCI, instead of a proper fix. > > I'll mark this patch as rejected, and wait for a proper fix. This isn't a work around for a bug in the xHCI host. The bandwidth checking is a feature. It allows the host to reject a new interface if other devices are already taking up too much of the bus bandwidth. I expect that all drivers that use interrupt or isochronous will have to fall back to a different alternate interface setting if they can. Now, Alan Stern and I have been talking about making a different API for drivers to request a specific polling rate and frame list length for an endpoint. However, I expect that the call would have to be either before or part of the call to usb_set_interface(), because of how the xHCI hardware tracks endpoints. So even if we had the ideal interface, the drivers would still need code like this to fall back to less-bandwidth intensive alternate settings. Is there a different way you think we should handle running out of bandwidth? Sarah Sharp -- 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
