Hi Matt, On Tue, May 31, 2011 at 03:52:16PM +1000, Matt Evans wrote: > Commit dfa49c4ad120a784ef1ff0717168aa79f55a483a > "USB: xhci - fix math in xhci_get_endpoint_interval()" > expands the clamping of the interval value to 0-15, which is only legal > for HS/SS endpoints. For FS, it must be 3-11. When testing with FS > isochronous endpoints (an audio device), values outside this range caused > the following error 0x11 (again) on an NEC xHCI controller: > > xhci_hcd 0000:01:00.0: ERROR: unexpected command completion code 0x11. > usb 1-1: Not enough bandwidth for altsetting 1 > Hmm, however USB2.0 spec (to whcih high/full/low-speed devices should conform states: "For full-/high-speed isochronous endpoints, this value must be in the range from 1 to 16. The bInterval value bInterval-1 is used as the exponent for a 2 value; e.g., a 4-1 bInterval of 4 means a period of 8 (2 )." > This commit makes xhci_parse_exponent_interval() check the EP speed and > clamp the interval appropriately. Also, xhci_parse_frame_interval() clamped > interval to 3-10; this has been changed to 3-11, as is valid for LS/HS. > > With this patch, full-speed isoch devices (e.g. audio) work again on xHCI. > > This should be queued for all stable kernels that contain > dfa49c4ad120a784ef1ff0717168aa79f55a483a > > Signed-off-by: Matt Evans <matt@xxxxxxxxxx> > --- > > A review of the xhci_parse_frame_interval() change (max 10 -> 11) would be > appreciated. The value 10 comes from Sarah's original xhci_get_endpoint_interval() > implementation; was there a reason for this being 10 rather than (as per the spec) > 11? The allowed interval is 1-255 ms or 8-1024 uframes, which gives 3-10 exponent interval. Thanks, Dmitry -- 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
