Hello Sarah,
Thursday, November 4, 2010, 3:44:35 PM, you wrote:
> On Wed, Nov 03, 2010 at 12:59:56AM +0100, Sander Eikelenboom wrote:
>> I have changed some dbg's into warn's for some bandwidth related stuff, and also added some printk's to bandwidth related stuff in uvcvideo driver.
>> Patch attached
>> With that i get the following output, seems the uvc drivers requests a packetsize of 3072, but max packet size later on still seems to be 1024 as reported by xhci ?:
> The UVC driver is probably asking for a max packet size of 1024, with
> two "additional transaction opportunities per microframe". So three
> transfers of 1024 packets will be sent out in one interval, or 3072
> bytes per interval. For the xHCI input endpoint context, those map into
> two separate fields. The 1024 max packet size goes into the "max packet
> size" field, and the "number of additional transaction opportunities per
> microframe" goes into the "max burst size" field. See section 6.2.3.4
> of the xHCI spec.
> Your added debug messages seem to indicate the max burst size is being
> set correctly:
> From your patch:
> @@ -1144,6 +1144,7 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,^M
> max_esit_payload = xhci_get_max_esit_payload(xhci, udev, ep);^M
> ep_ctx->tx_info = MAX_ESIT_PAYLOAD_FOR_EP(max_esit_payload);^M
> ^M
> + printk("SEIK: maxpacket: %d max burst: %d \n",max_packet,max_burst);^M
> From the output:
>> [ 31.566721] usb 9-3: ep 0x83 - urb len = 0x10 (16), addr = 0x78993a10, num_trbs = 1
>> [ 31.573776] UVC requested bandwidth3: 3072 | 3072
>> [ 31.581270] UVC requested bandwidth5: 3072
>> [ 31.585463] UVC requested bandwidth6: 3072 | 128
>> [ 31.590173] UVC requested bandwidth6: 3072 | 256
>> [ 31.594878] UVC requested bandwidth6: 3072 | 512
>> [ 31.599585] UVC requested bandwidth6: 3072 | 1024
>> [ 31.604385] UVC requested bandwidth6: 3072 | 2048
>> [ 31.609185] UVC requested bandwidth6: 3072 | 3072
>> [ 31.614008] usb 9-3: ep 0x81 - rounding interval to 1 microframes
>> [ 31.620101] SEIK: maxpacket: 1024 max burst: 2
> So the xHCI driver is properly setting the fields, according to your patch.
> The xHCI hardware is just rejecting the configuration.
Hmm ok .. so everything seems to go well .. but it would be the hardware rejecting and not the xhci driver ?
If i see the UVC iterate i would assum it is trying from low to high the determine the bandwidth that's acceptable, and see where it fails and take the highest allowed.
But it ends up with the 3072 none the less.
> Sarah Sharp
> p.s. I'm not sure whether your editor or your email system is to blame,
> but your patch included non-Unix line endings (the "^M" characters). If
> you want to send a patch in the future that needs to apply to someone's
> tree, you're probably going to have to fix that. :)
Ahh yes sorry .. my laptop runs MS-windows, mangled by going through a windows editor, and forgot to put it back to unix line endings.
--
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
