On Mon, 6 Jun 2011, Sarah Sharp wrote: > > > succeeds. The bandwidth checking needs to be done before the USB core > > > issues that control transfer. > > > > Is this requirement in the xHCI spec? I don't recall seeing it (but > > then I haven't read the whole thing). > > Yes, it is a requirement of the xHCI spec. It's really that they want > to allow virtualization hosts the opportunity to deny guests the chance > to switch to certain configurations or alternate interface settings. I > suppose if two guests could share different interfaces of the same > device, then you wouldn't want one guest to suddenly switch > configurations. I don't see the connection. Preventing a guest from switching configs or altsettings doesn't have anything to do with whether the bandwidth checking is done before or after the control transfer. > > Regardless, this is how we should do it. At the same time, we could > > include a feature allowing drivers to decrease the de facto maxpacket > > values below the values given in the endpoint descriptors, for improved > > scheduling performance. > > Well, ok, but the xHCI host controller will only accept powers of 2 max > packet sizes, Sez who? In my copy of the xHCI spec, 6.2.3.5 states that the Max Packet Size field shall be set to the value defined in bits 10:0 of the endpoint descriptor. Those values don't have to be powers of two. > so will there be any drivers that will benefit from that? Didn't we discuss this some time ago? Video drivers that won't be using the full resolution available in a particular altsetting are an example. The packets they will transfer will be smaller than the maxpacket values listed in the descriptors. > Also, what about USB 3.0 devices, where multiple max packets can be > burst at one time? The devices that set bMaxBurst are required to set > the max packet size to a fixed value. I think USB 3.0 isochronous > devices can do bursts, but I would have to check. Yes, bursting might complicate the issue. Still, drivers should be able to tell the scheduling code how much of the potential bandwidth they actually intend to use. > I'm more interested in making sure that the drivers that use a different > polling interval than advertised in the endpoint descriptors are able to > change the xHCI interval. Why would a driver want to use a different interval? Generally speaking, with isochronous transfers you _can't_ reasonably change the interval. With interrupt transfers you can, but the only effect is to decrease latency -- why wouldn't the latency in the descriptor be adequate? > If the host rejects a new configuration or alt setting, we should stay > with the current setup, without attempting to change the device. If the > device rejects the change by stalling the control transfer to set the > new configuration or alt setting, we need to revert the host state back > to the old setup. In the case of config changes, we _can't_. It's already too late -- by the time the bandwidth change is tested or the control transfer is sent, we have already unbound the existing drivers and called device_del() for the old interfaces. Even trying to reinstall the old config from scratch would be very difficult; it would be much simpler to send a Set-Config(0) request. In the case of altsetting changes, we can. In fact, that's what we do now. (Although not entirely correctly...) 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
