On Thu, 24 Sep 2015, Steinar H. Gunderson wrote: > On Thu, Sep 24, 2015 at 10:17:19AM -0400, Alan Stern wrote: > > However, none of this answers the question of why you can use both > > cards on a different machine but not on yours. It comes down to the > > implementations of the xHCI controller chips. In USB-3, bandwidth > > allocation is handled by firmware running on the controller, not by the > > operating system's driver. The driver presents a series of endpoints > > with all their bandwidth requirements to the controller, and the > > controller either accepts it or rejects it. > > OK, I feared as much. The other machine also has an Intel controller, > but as far as I know, a newer one (and the PCI ID is different -- 8086:9cb1). > > > It doesn't give any explanation for its decision, and as far as I know, it > > doesn't provide any information about the details of how it allocates the > > bandwidth. > > I thought I saw something in the xHCI spec about enumerating the bandwidth > domains to try to get some more insight in what the topology looks like, > but I guess I misunderstood it? (It all wasn't very clear to me.) Ah, you're referring to the Get Port Bandwidth command, documented in section 4.6.15 of the xHCI-1.1 spec. Yes, that does provide some information on what bandwidth remains available. Apparently the xhci-hcd driver doesn't support it. Adding it would be a good way to improve the driver's debugging facilities. > I assume there's no way I can lie to the chip? Like, if I know for a fact > that the card will send less data than the alternate claims (like, > I'm using a video mode that will require only a few hundred megabits/second > in practice, but even the lowest alternate claims >1 Gbit/sec). You can always patch the kernel to do whatever you want. For instance, you could reduce the bMaxBurst value in the descriptor after the kernel gets it from the card. Short of that, there is no way to affect the outcome. 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
