Hi, On Wed, Feb 11, 2015 at 2:25 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 11 Feb 2015, Bin Liu wrote: > >> Felipe, >> >> On Wed, Feb 11, 2015 at 2:03 PM, Felipe Balbi <balbi@xxxxxx> wrote: >> > On Wed, Feb 11, 2015 at 12:54:52PM -0600, Bin Liu wrote: >> >> Peter, >> >> >> >> On Tue, Feb 10, 2015 at 10:08 PM, Peter Stuge <peter@xxxxxxxx> wrote: >> >> > Bin Liu wrote: >> >> >> I have a ARM SoC which has a dwc3 drd controller, to validate if there >> >> >> is a limit of max device connections, I connected multiple hubs, then >> >> >> keyboards and mice. >> >> >> >> >> >> When plugged in the 32th device, xHCI shows the following message and >> >> >> the numeration failed. >> >> >> >> >> >> Not enough host controller resources for new device state. >> >> >> can't set config #1, error -12 > > Can't set config means the device was enumerated. So there were enough > device slots; the problem was some other sort of resource. > >> >> >> Then plugging in more keyboards or mice, this message always happened. >> >> >> But then MSC devices were still enumerated correctly at this point. So >> >> >> it seems the issue is only related to interrupt transfers? > > Probably the resource is connected with scheduling of periodic > transfers (interrupt and isochronous). > >> >> >> I am trying to understand if this is hardware or xHCI driver >> >> >> limitation. Anyone has any pointers how to debug this issue? >> >> > >> >> > I don't know if it is the reason for what you experience above, but >> >> > xHCI allows for host controller hardware to limit the number of >> >> > devices that can successfully be attached - which IMO permits xHCI >> >> > host controllers to be generally incompatible with the USB >> >> > specification. >> >> > >> >> > http://marc.info/?l=linux-usb&m=139654353325844 >> >> >> >> Thanks for the pointer. I checked HCSPARAMS1 register on my platform, >> >> its value is 0x02000440, which means it has 64 device slots. So I >> >> think my issue is on elsewhere. >> >> >> >> Keep looking... >> > >> > no, you're hitting the limit alright :-) You said it dies after the 32nd >> > device right ? I think each device is taking up 2 slots. >> >> I am still reading, I thought each device takes one slot. Also MSC >> device still got enumerated after keyboard failed, that is why I don't >> think this is slot limitation problem. >> >> The failure point varies in my test, sometimes it failed at 32nd, >> sometimes at 28th. >> >> > >> > Just a guess, probably worth counting how many slots are used by each >> > device. >> >> Trying to figure out where to patch the driver... >> >> The error message means ep configuration failed, trying to understand >> what ep means in xhci, I don't it is the same as that in musb... The >> SoC datasheet says the dwc3 has 15-in + 15-out eps, plus ep0. > > The problem probably isn't the number of endpoints, but rather the > scheduling entries for interrupt and isochronous endpoints. -12 return code in the log is due to COMP_ENOMEM (7, in Table 135 in xHCI Specs) returned by the completion of configure endpoint command. All in xhci_configure_endpoint() in xhci.c. Then in xHCI Specs Section 4.6.6 Configure Endpoint, and Section 4.14.1.1 System Bus Bandwidth Scheduling, I got a feeling it is indeed due to periodic scheduling, after certain amount of interrupt (applicable to ISO as while) endpoints have been scheduled, there does not have enough bus bandwidth left for new interrupt scheduling any more. I am new to xhci, any comments for my suspicion? Thanks, -Bin. > > Alan Stern > -- 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
