Hi Arshad, > The driver used by the USB controller is MUSB_HDRC. Looking at musb_core.c, I've found the following comment: * * Control and bulk use dedicated endpoints, and there's as * yet no mechanism to either (a) reclaim the hardware when * peripherals are NAKing, which gets complicated with bulk * endpoints, or (b) use more than a single bulk endpoint in * each direction. * * RESULT: one device may be perceived as blocking another one. * * * Interrupt and isochronous will dynamically allocate endpoint * hardware, but (a) there's no record keeping for bandwidth; * (b) in the common case that few endpoints are available, there * is no mechanism to reuse endpoints to talk to multiple devices. * * RESULT: At one extreme, bandwidth can be overcommitted in * some hardware configurations, no faults will be reported. * At the other extreme, the bandwidth capabilities which do * exist tend to be severely undercommitted. You can't yet hook * up both a keyboard and a mouse to an external USB hub. Sounds like this could be the limitation you're running into? I'm CC'ing Felipe, who is the maintainer for the musb driver, perhaps he can comment? > > This problem sounds familiar to a problem I have observed in an Ralink > > RT3052 board, which uses the dwc_otg / dwc2 driver. Here, the problem > > was that the host controller offers four "host channels" to communicate > > with different device endpoints, but ttyUSBx interfaces which did not > > have any data to send would keep such a host channel occupied. Having > > two host channels occupied by these IN endpoints, one for the interrupt > > endpoint of the 3G device and one for the interrupt endpoint of the hub, > > occupies all four, making outgoing transfers block and timeout. > > So does this mean that having only 4 TX and RX endpoints available in the > host controller means that you can only ever have 4 USB devices plugged in > at once? No, normally a host channel is only occupied for the duration of the bulk transfer and can be reused for another USB device / endpoint after the transfer completes. The problem occurs when the transfer doesn't complete for a longer period of time (because the device keeps replying with NAK). >From the above comment, it seems that something similar might be going on for your situation. > It is very possible that I have the same problem. The actual error I get > when trying to connect multiple ttyACMx ports is: > > tty_port_close_start: tty->count = 1 port count = 0. > Open_port: Unable to open /dev/ttyACM3: Input/output error For me, I got timeouts and errors like "cat: timed out on ep0out" with USB debugging enabled, but perhaps the musb driver is actually aware that it has run out of endpoints and thus denying the opening of the device? > It seems like you managed to resolve the issue. If so, then could you please > explain how you managed to do it. It's probably not directly helpful to you since the driver is really different, but I patched up the dwc_otg driver to detect this "lockup" situation and halt a transfer that was receiving NAKs to make room for other transfers (and then retry the transfer afterwards). In case anyone is interested, the patch is available on the Fonosfera trac [1] (I hope the link is correct, since the trac seems to be down right now). I plan to port this patch, or perhaps another solution, over to the dwc2 driver in the near future as well. Gr. Matthijs -- 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
