>> 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. The same function driver will work fine with a UDC accepting arbitary endpoint sizes. > Follows the patch, which can fix your two issues and is against v1. > Yes that works fine thank you. Regards, Martin -- 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
