Hi Arnaud, >> >> 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 meet the described problem with s3c2440a SoC and latest kernels, so the fix isn't applied currently in the Linux kernel. Actually the change itself is quite obvious, if to regard such interrupts as FIFO ready notification *only* for EP0. >> >> 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). > Agree, the best way is to have a feedback from Samsung regarding the issue. The other way is to create specific test cases, including long data transfers from target to host via transport endpoints. This shall dispel or confirm doubts about null EP_INT_REG, when IN_PKT_RDY bit is cleared for transport enpoints. With best wishes, Vladimir -- 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
