Alan, On Wed, Feb 11, 2015 at 3:56 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 11 Feb 2015, Bin Liu wrote: > >> > 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? > > It could be that there is not enough bus bandwidth. Or it could be > some other resource that the xHCI controller uses internally for the > periodic scheduling. Either way, that's the reason you reach the > limit. Yeah. My question is answered, I just wanted to understand if there was a hw or sw bug which causes the limit. I believe this is just a nature of periodic transfers - within the period between the minimum interrupt intervals, it can only have a limited slots for new interrupt transfers. 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
