On Mon, Feb 16, 2015 at 08:52:35AM -0600, Bin Liu wrote: > Felipe, > > On Mon, Feb 16, 2015 at 7:17 AM, Felipe Balbi <balbi@xxxxxx> wrote: > > 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. > > My response above meant the same - bandwidth limitation. > > But I now believe Alan is correct, the limitation is very likely due > to xhci internal resource, not about bus bandwidth. > > bInterval of EP in mouse or keyboard is 10ms, xhci polls the EP in > about 7~8ms, each interrupt transfer takes about 500ns roughly. > > So in 7ms interval, roughly the bus can do 7000us / 0.5 = 14K > interrupt transfers, considering other factors in reality, for example > packet turn around time, the 14K number will be much smaller, but it > cannot be lower to 28. So in this particular case, I don't think it > reaches bus bandwidth limit for periodic transfers. Makes sense. I wonder if that's configurable for the IP or is it something XHCI just mandates and that's it. -- balbi
Attachment:
signature.asc
Description: Digital signature
