Em Wed, 15 Jan 2014 16:52:45 +0000 Sean Young <[email protected]> escreveu:
> On Wed, Jan 15, 2014 at 01:49:17PM -0200, Mauro Carvalho Chehab wrote: > > Hi Martin, > > > > Em Wed, 11 Dec 2013 21:34:55 +0100 > > Martin Kittel <[email protected]> escreveu: > > > > > Hi Mauro, hi Sean, > > > > > > thanks for considering the patch. I have added an updated version at the > > > end of this mail. > > > > > > Regarding the info Sean was requesting, it is indeed an xhci hub. I also > > > added the details of the remote itself. > > > > > > Please let me know if there is anything missing. > > > > > > Best wishes, > > > > > > Martin. > > > > > > > > > lsusb -vvv > > > ------ > > > Bus 001 Device 002: ID 2304:0225 Pinnacle Systems, Inc. Remote Kit > > > Infrared Transceiver > > > Device Descriptor: > > > bLength 18 > > > bDescriptorType 1 > > > bcdUSB 2.00 > > > bDeviceClass 0 (Defined at Interface level) > > > bDeviceSubClass 0 > > > bDeviceProtocol 0 > > > bMaxPacketSize0 8 > > > idVendor 0x2304 Pinnacle Systems, Inc. > > > idProduct 0x0225 Remote Kit Infrared Transceiver > > > bcdDevice 0.01 > > > iManufacturer 1 Pinnacle Systems > > > iProduct 2 PCTV Remote USB > > > iSerial 5 7FFFFFFFFFFFFFFF > > > bNumConfigurations 1 > > > Configuration Descriptor: > > > bLength 9 > > > bDescriptorType 2 > > > wTotalLength 32 > > > bNumInterfaces 1 > > > bConfigurationValue 1 > > > iConfiguration 3 StandardConfiguration > > > bmAttributes 0xa0 > > > (Bus Powered) > > > Remote Wakeup > > > MaxPower 100mA > > > Interface Descriptor: > > > bLength 9 > > > bDescriptorType 4 > > > bInterfaceNumber 0 > > > bAlternateSetting 0 > > > bNumEndpoints 2 > > > bInterfaceClass 255 Vendor Specific Class > > > bInterfaceSubClass 0 > > > bInterfaceProtocol 0 > > > iInterface 4 StandardInterface > > > Endpoint Descriptor: > > > bLength 7 > > > bDescriptorType 5 > > > bEndpointAddress 0x81 EP 1 IN > > > bmAttributes 2 > > > Transfer Type Bulk > > > Synch Type None > > > Usage Type Data > > > wMaxPacketSize 0x0040 1x 64 bytes > > > bInterval 10 > > > > Hmm... interval is equal to 10, e. g. 125us * 2^(10 - 1) = 64 ms. > > > > I'm wandering why mceusb is just forcing the interval to 1 (125ms). That > > sounds wrong, except, of course, if the endpoint descriptor is wrong. > > Note that the endpoint descriptor describes it as a bulk endpoint, but > it is used as a interrupt endpoint by the driver. For bulk endpoints, > the interval should not be used (?). > > Maybe the correct solution would be to use the endpoints as bulk endpoints > if that is what the endpoint says? mceusb devices come in interrupt and > bulk flavours. Yes, this could be a possible fix. > > > On my eyes, though, 64ms seems to be a good enough interval to get > > those events. > > Each packet will be 64 bytes, and at 64 ms you should be able to 960 > bytes per second. That's more than enough. > > > Jarod/Sean, > > > > Are there any good reason for the mceusb driver to do this? > > ep_in->bInterval = 1; > > ep_out->bInterval = 1; > > I don't know. > > > At least on my tests here with audio with xHCI and EHCI with audio on > > em28xx, it seems that EHCI just uses the USB endpoint interval, when > > urb->interval == 1, while xHCI uses whatever value stored there. > > The xhci driver is not happy about the interval being changed. With > CONFIG_USB_DEBUG you get: > > usb 3-12: Driver uses different interval (8 microframes) than xHCI (1 > microframe) Maybe then changing the interval to 3 could also fix it, if the device is using high speed (480 kHz), and 1 otherwise. E. g. changing the logic to something like: if (dev->speed == USB_SPEED_HIGH || dev->speed == USB_SPEED_SUPER) { if (ep_in) ep_in->bInterval = 3; if (ep_out) ep_out->bInterval = 3; } else { if (ep_in) ep_in->bInterval = 1; if (ep_out) ep_out->bInterval = 1; } At the device probing logic. I think that using a bulk transfer, if it works, is a better solution, though. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
