Re: dwc3/xHCI max connection limit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Regards,
-Bin.

>
> --
> balbi
--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux