On Tue, 7 Jun 2011, Sarah Sharp wrote: > > > so will there be any drivers that will benefit from that? > > > > Didn't we discuss this some time ago? Video drivers that won't be > > using the full resolution available in a particular altsetting are an > > example. The packets they will transfer will be smaller than the > > maxpacket values listed in the descriptors. > > Ok, sure. If the drivers are always transferring one frame per packet, > and the resolution is smaller, the packets will be consistently smaller, > correct? We'll never have the case where the driver will need to > transfer some larger packet for an endpoint that has a custom Max > Packet size? If it does, it clearly is making a mistake. We should expect things to go wrong when that happens. > > > I'm more interested in making sure that the drivers that use a different > > > polling interval than advertised in the endpoint descriptors are able to > > > change the xHCI interval. > > > > Why would a driver want to use a different interval? Generally > > speaking, with isochronous transfers you _can't_ reasonably change the > > interval. With interrupt transfers you can, but the only effect is to > > decrease latency -- why wouldn't the latency in the descriptor be > > adequate? > > Aren't there some devices that advertise the interval in the wrong > format? I.e. using frames for high speed device intervals instead of > microframes? I thought I saw some quirks in the webcam drivers for > fixing those intervals up. If the descriptor is just plain wrong, the driver can change the descriptor and then call usb_set_interface(). That's a separate issue. > I originally thought that one of my HS webcams had this issue, but I've > double checked, and the issue is with the interrupt endpoint, not the > isochronous endpoint like I thought. > > [ 2310.414885] usb 3-2: Driver uses different interval (8 microframes) than xHCI (128 microframes) > [ 2310.430819] xhci_hcd 0000:06:00.0: ep 0x87 - asked for 16 bytes, 9 bytes untransferred > > lsusb output: > > Bus 003 Device 004: ID 046d:09a5 Logitech, Inc. Quickcam 3000 For Business > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > ... > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x87 EP 7 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0010 1x 16 bytes > bInterval 8 > > Now, the kernel doc around urb->interval is not very clear. It says: > > * @interval: Specifies the polling interval for interrupt or isochronous > * transfers. The units are frames (milliseconds) for full and low > * speed devices, and microframes (1/8 millisecond) for highspeed > * and SuperSpeed devices. > > So is interval supposed to be decoded as a straight value, like for a HS > device, would an urb->interval of 8 mean 8 microframes? Or is the USB > core and host controller drivers supposed to decode urb->interval using > the same encoding from the USB bus specifications? I admit, the kerneldoc could be more specific. You didn't go on to read the part where it says: * Isochronous URBs also have transfer intervals. (Note that for isochronous * endpoints, as well as high speed interrupt endpoints, the encoding of * the transfer interval in the endpoint descriptor is logarithmic. * Device drivers must convert that value to linear units themselves.) The implication is that the urb->interval value is in linear units, not logarithmic units. You can confirm this by reading the kerneldoc and code for usb_fill_int_urb(). > I assumed that the kernel doc meant the xHCI driver was supposed to > interpret urb->interval as a straight value of either frames or > microframes. So the converted interval from the endpoint descriptor is > 2^(8-1) = 128 microframes, and that's what the xHCI driver has told the > host to use as a polling interval. uvcvideo sets urb->interval to 8, > which if it's a straight value is 8 microframes, which is != 128. Is > this a bug in the uvcvideo driver, or a misinterpretation on my part? It's a bug in uvcvideo. Evidently it doesn't use usb_fill_int_urb(). > There are several drivers that set urb->interval to the interval from > the descriptor without checking what speed the device is operating at. Some drivers assume the device is operating at a specific speed. For instance, they may be written for devices that only support full speed. > There are other drivers that set it to some constant, and I can't tell > if that matches the device descriptors at all. So it's difficult to > tell whether drivers are using different polling intervals than what the > device specifies. In almost all cases, these are mistakes. I don't know of any situations where a driver would want to use an interval different from the descriptor's value (although there may be a few). > > In the case of altsetting changes, we can. In fact, that's what we do > > now. (Although not entirely correctly...) > > Are there bugs in the alt setting fall back mechanism? Caused by my > bandwidth code or something else? I meant that usb_set_interface() calls usb_hcd_alloc_bandwidth() _before_ calling usb_disable_interface() to disable and flush the current endpoints, and it does this to simplify the fallback mechanism. 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
