Re: [RFT 2/2] USB: Free bandwidth when usb_disable_device is called.

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

 



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


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

  Powered by Linux