2010/9/25 Martin Fuzzey <mfuzzey@xxxxxxxxx>: >>> When I configure different max packet sizes for IN transfers and observe >>> the data size >>> on the bus (with a bus analyser) I see: >>> >>> config bus >>> 256 256 >>> 512 512 >>> 248 256 >>> 1020 1024 >>> 1023 1024 >> >> How do you trigger the IN transfer in usb host? usb test #16? >> > Yes > >> If the usb device does response packets which size is larger than >> the max packet size in endpoint descriptor, you may meet overflow >> error. If you don't see this kind of error in usb hcd, seems the data >> size from your bus analyser is not accurate. >> > Indeed I do get overrun errors from the host controller in this case. > > I dug into this a bit (I'm only using the gadget side as a test > device for my HCD)... > > It turns out that the gadget side hardware (antgw100 based on > atmel ap7000 SoC - avr32 arch) uses a bitfield for the endpoint > size supporting 8 to 1024 by powers of two. > This uses the atmel_usba_udc gadget driver. > > That explains the behaviour I'm seeing above but does raise > the question (though not directly related to f_iso) of how > gadget function drivers are supposed to adapt to this. > > Suppose a gadget function driver defines a non power > of two endpoint size (say 192 bytes). > > When running on atmel_usba_udc the size in the > descriptor will be 192 but the size on the wire will be > 256 and hence the host side will get overruns. It is surely caused by your atmel_usba_udc controller or its driver. According to usb spec, max packet size of ISO endpoint should not go beyond 1023. > The same function driver will work fine with a UDC > accepting arbitary endpoint sizes. The f_iso has been verified OK using musb on beagle B5 as gadget controller, either full speed or high speed. >> Follows the patch, which can fix your two issues and is against v1. >> > Yes that works fine thank you. Thanks for your test, I will resend the patch later with this fix. -- Lei Ming -- 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
