On Mon, Nov 19, 2012 at 05:31:57PM -0500, Alan Stern wrote: > On Mon, 19 Nov 2012, Sarah Sharp wrote: > > > On Mon, Nov 19, 2012 at 10:50:32AM -0500, Alan Stern wrote: > > Perhaps we should only update the schedule after the configuration or > > alt setting is installed? We could force a driver to claim an endpoint > > before submitting any URBs to it, and release an endpoint when it was > > done. > > I don't want to change the drivers. Totally understandable. :) We could possibly hook into usb_submit_urb and claim the endpoint on the first URB submission, and unclaim it on driver disconnect. But if your view is that switching to an alt setting is basically claiming the endpoints, then it doesn't make much sense to do this. So we'll just stick with the model we have under xHCI. > The time when the schedule actually gets updated would indeed be after > the config or altsetting is installed. But most of the computations > have to be done beforehand, to know whether there is sufficient > bandwidth for the update to succeed. > > > That way if a driver doesn't use a particular endpoint, it doesn't take > > up useless space in the schedule. This helps for webcams or serial > > devices that don't need the endpoints until their open FOP is called, > > and can release the endpoints when their close FOP is called. > > "FOP"? Filesystems operation. A lot of the examples in the Linux Device Drivers book used fops in the file system operations table name, so I just got used to calling it fops. > The USB spec already provides for this, to some extent. Altsetting 0 > is not supposed to contain any isochronous endpoints and should have > minimal bandwidth requirements. Drivers ought to switch back to > altsetting 0 when they are not using the device. Yep. I have seen broken webcams with isoc endpoints on alt setting 0, though. > > It also means you don't have to go through a revert if the Set > > Configuration or Set Interface control transfers fail. It has the > > further advantage that drivers could specify the interval they're using > > for periodic endpoints, and we could finally address the issue of xHCI > > only being able to use the interval from the endpoint descriptors. > > Maximum transfer size too, not just interval. You mean that some devices have bogus bMaxPacketSize fields? I'm confused by what you mean by maximum transfer size. > This could be done as part of an extended set-interface API. Along > with specifying the altsetting to install, a driver could pass a list > of the transfer sizes and intervals it wants for all the periodic > endpoints in the altsetting. Sure. Then we would only need to chase down the drivers that don't use bInterval from the endpoint descriptors. > > > What do you think? Does this seem feasible? > > > > Your original idea of storing the state and reverting it does seem > > feasible. However, I like the idea of doing one big fix to solve > > several different bandwidth issues. What do you think of having drivers > > claim endpoints? > > I really don't want to update the drivers. :-) Ok, I was just throwing it out there, since you were asking for ideas. :) I guess you're stuck with rebalancing after a Set Interface fails. I don't think that will be too common though. 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
