On Thu, 30 Jun 2011, Sarah Sharp wrote: > On Thu, Jun 30, 2011 at 05:01:36PM -0400, Alan Stern wrote: > > On Thu, 30 Jun 2011, Sarah Sharp wrote: > > > > > Hi Alan, > > > > > > In an upcoming patchset, I'm going to need to walk the USB tree in the > > > xHCI driver in order to gather some information during a device > > > configuration or alt setting change. Is there anything stopping the USB > > > tree from changing while this operation is in progress? > > > > Are you talking about a single bus or a whole bunch of buses? > > I'm talking about the buses that are associated with the High Speed or the > SuperSpeed split roothub under xHCI. I think I'll only have to walk > the bus that the changed device is under for a first pass, but I may > need to walk both buses later. Changed device? > For a while, the xHCI driver has had code to walk up the tree whenever a > new device is enumerated to figure out which root port it's connected > under. Do I need to lock usb_lock_device() for that, or does the USB > core already take care of making sure the device's parent and ancestors > don't get disconnected? Well, the parent and ancestors can't get removed from memory while a child is present. > > What information are you collecting and what do you want it for? > > Sigh. Basically the Intel xHCI host controller in Panther Point needs > software to do the bandwidth checking, rather than it being implemented > in hardware. They decided not support virtualization for this version, > and the hardware bandwidth checking is really only in the xHCI spec for > virtualization. Plus the hardware folks really wanted to validate their > algorithm in software before shoving it into hardware. How is their algorithm going to get implemented in software? Is that your job? > So the xHCI driver gets to do some worst-case schedule building each > time the USB core calls xhci_check_bandwidth, and reject the new config > or alt setting if there's not enough room in the schedule for it. > Otherwise the hardware will blindly accept the command, and then run > into issues later when it tries to dynamically schedule the packets, > which could cause dropped periodic packets. Oh dear. You get to implement scheduling for LS/FS, HS, TTs, and SS. Considering that, among all the other HCDs in Linux, only the first has been done correctly, you have your work cut out. We really ought to coordinate fixing up the TT implementation so that it can be used properly by both xhci-hcd and ehci-hcd. We should also talk about the proper algorithm to use for scheduling with TTs. > To do that calculation, I need to know several things for every > device's endpoints under a particular rootport: > > - speed > - max packet size > - mult and burst size > - max esit value > - endpoint interval > - the TT it's attached to > - whether a TT on a HS device has any LS or FS devices attached to it > with active periodic endpoints. The USB core doesn't really keep > track of whether each port on a multi-TT hub has LS or FS devices > attached. But you don't need this information for every endpoint whenever a change occurs. You need it only for the endpoints that are being added to the schedule or modified (which is the same as remove + add). > Basically, I would have given all that information to the hardware in > the input context for the Configure Endpoint command, and it's supposed > to use the information stored in the Output Device Context to make this > worst-case schedule and decide if it can handle the added, changed, or > dropped endpoints. I'm storing much of that information in the xHCI > driver's array of devices (indexed by slot ID), and I could just build > the information from that array, but it seemed much simpler to just > traverse the USB core's tree. Without giving it much deep though, I eould expect that you don't actually need to traverse the USB device tree. 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
