On Fri, Jul 01, 2011 at 10:35:48AM -0400, Alan Stern wrote: > On Thu, 30 Jun 2011, Sarah Sharp wrote: > > > On Thu, Jun 30, 2011 at 05:01:36PM -0400, Alan Stern wrote: > > > 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? Yes, apparently it is my job. I've convinced them to let me release their algorithm in the xHCI driver, so I'll be using that. It's actually somewhat hardware specific, because while the xHCI host doesn't check whether a changed endpoint pushes the worst-case schedule over the top, the hardware does the dynamic scheduling itself. So the algorithm actually uses a bit of information about the logic that does the dynamic scheduling to make sure it is actually creating the worst-case schedule. > > 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. The algorithm covers all those, and also accounts for a couple other things. I finally understand the LS/FS/HS and TT scheduling algorithm, and I've been putting that into code. I'm still not convinced I understand their SuperSpeed algorithm, so those patches will come later. I'll post what I have later today. > 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. So which part of the TT implementation are you talking about? I'm not familiar with how EHCI uses the usb_tt structure, but it would be nice if we can share some information/code. > > 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. I think I just need to post the code with the algorithm and let you see what it's doing. I do need information about all the devices on the port, and I could keep that information in the xHCI driver and only update the worst-case schedule with the changed endpoints. However, as I said I started to reproduce the USB core tree structure when I tried to figure out how to store this information. It seemed better to implement the algorithm the dumb, simple way, get it correct, and then optimize it. 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
