Vladimir Zapolskiy <vzapolskiy@xxxxxxxxx> writes: > Hello Michael and Marek, Hi, > > I've found that you're involved in Linux USB gadget development, and > I've decided to write you a email asking about full speed S3C2410 UDC > specifics, hope you could help me with some information. > > Right now in the UDC driver in the Linux kernel there is a bug related > with MCU feedback irq notification after IN_PKT_RDY set for endpoints. > There is no processing of EP interrupts, when EP_INT_REG == 0, and > this leads to stopping in IN queue processing. Consequently host > doesn't receive responses on its requiests in reasonable time etc. > > It is observed that the interrupt is honestly reported, but no bits > are set in EP_INT_REG. For now in my development branch of the Linux > kernel I process all interrupts under (EP_INT_REG == 0 && > USB_INT_REG == 0 && PWR_REG == 0) condition with EP0 handler, and it > at least works well for g_file_storage gadget. According to the 2410/2442 manuals I've looked at, getting an interrupt and no bit set in EP_INT_REG and USB_INT_REG should indeed not happen. Unfortunately, while on 2410 it's working as expected, it's not the case on 244x. afaik a patch (iirc made by David Anders but maybe it was made by someone else, you'll have to check) to handle this case has been sent a long time ago but if you're still seeing the issue, it may have been lost. > > I have a question, if such behaviour, namely no set bits in > EP_INT_REG, present for bulk endpoints too. If it is so, how should > the driver interpret the condition EP_INT_REG == 0 and select a proper > EP for IN queue processing? It should not happen too but who knows, maybe it's needed. The specs I have at hand disagree but the reality may be telling us a different story. At least, I'm not aware of any errata about that. Having a feedback from Samsung about that would be nice (with docs/errata if possible). Arnaud -- 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
