On Mon, Sep 27, 2010 at 11:51:44AM -0400, Alan Stern wrote: > On Mon, 27 Sep 2010, Sarah Sharp wrote: > > Then we're stuck with a device in one alt setting, and the USB core and > > xHC in a different alt setting. So I think we need a shared bandwidth > > lock for the whole xHCI host controller. > > You know, I'm not so sure a shared lock will work -- not even in the > form we're using now. Consider this variant scenario: > > 1. The class driver wants to switch a USB 2.0 to a different alt > setting, perhaps with fewer endpoints. The xHCI Configure Endpoint > command succeeds, freeing some internal resources. > > 2. An URB is submitted for some other device entirely, consuming some > of the internal resources. The xHCI host controller guarantees that all resources (bandwidth and internal) for a given configuration are available when the Configure Endpoint command is successfully completed. Issuing URBs and putting things on the endpoint rings should not change internal resources. Section 4.6.6 is explicit about the host controller needing to keep global bandwidth and resources available varies that only change when a configure endpoint, evaluate context, reset device, or disable slot command happens. > 3. The USB 2.0 device fails to respond to the control transfer to > switch alt settings, and the USB core needs to put the device back > into its old alternate setting. The Configure Endpoint command > fails because the old alt setting would take more internal resources > than are currently available. > > Is there anything in the spec that says this can't happen? For that > matter, is there anything that says the hardware can't accept a > Configure Endpoint at one time and refuse it at another time, even with > the _same_ amount of resources available? (Sort of like the way > fragmentation can affect memory allocation.) There's no explicit statement disallowing host controllers from changing their minds about the same Configure Endpoint command issued twice. But if they really were following the instructions Section 4.6.6, I don't see how this could happen. > This is beginning to sound sufficiently difficult that it ought to be > addressed officially. Can you bring this up before the USB-IF or ask > somebody there at Intel? How does one change between alternate > settings in a way that is guaranteed to backtrack successfully if the > device refuses the change? I tried to get the xHCI spec architect to put something more concrete into the spec, but my suggestion didn't make it into the 0.96 spec. I can redig those conversations out of my mail archives, but changing the spec now isn't going to change the hardware that's already out there. I can probably get the USB-IF compliance team to add a test that simply switches back and forth between two alternate settings or configs, but I don't think a spec change is very likely at this point. :( > > I know of a few xHCI prototypes where each port on the xHCI host > > controller is a completely separate bus. So each port gets its own > > bandwidth and separate bus addresses. I don't think there's a good way > > for the xHCI driver to figure out which ports are separate bus instances > > (the Get Port Bandwidth command is not quite sufficient), but I could > > see a method being added as a xHCI 1.0 ECN, or maybe a USB 4.0 thing. > > So it's possible we could see USB hosts with more than two buses. > > The bandwidth and bus addresses don't really concern the OS because > they are all handled internally by the xHCI hardware. To what extent > would the USB core need to know that each port has its own bus? True, the USB core probably doesn't need to know about the separate buses. It might be useful to speed up the enumeration process, since you could have multiple devices at address 0 under an xHCI host with such a configuration. Sarah Sharp -- 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
