On Wed, Feb 11, 2015 at 04:14:49PM -0600, Bin Liu wrote: > 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. The limitation is imposed by the USB spec. I can't remember which section but it does state that for isochronous and interrupt EPs, we need to guarantee bandwidth; a consequence of that is we can't allow new interrupt/isoc endpoints to be used if we can't fulfill bandwidth requirements. -- balbi
Attachment:
signature.asc
Description: Digital signature
