On Thursday 16 April 2009, Alan Stern wrote: > > > I see. Yes, that might need to change. And it would be a > > flavor of "rebalancing" too. ISTR thinking about biasing > > interrupt transfers for "late" in the frame, but may never > > have done much with that thought. > > A disadvantage of moving interrupt transfers "late" in the frame is > that it would force the use of FSTNs, which the driver currently > doesn't have code for. Even worse, FSTNs aren't defined for EHCI-0.95. Not many folk ship the 0.95 hardware any more. Way back when I wrote that code, that was about the only stuff available... ;) Easy to deal with that. The revision is recorded somewhere during chip init. If FSTN code gets written, just make sure nothing relies on it with hardware that won't cooperate. > > To treat ISO frames that way it might be useful to add a > > new abstraction: a full speed view of that schedule tree. > > Maybe not; but, it might make for a simpler structure. > > Without actually writing the code, it's hard to judge how much state > should be stored explicitly vs. reconstructedon-the-fly. Not entirely true. I chose "reconstruct on-the-fly" because I wanted to have exactly one record -- avoiding introduction of bugs caused by inconsistency there. But already it got to be awkward in some cases. I guess you could say that's with the benefit of having written some of that code. ;) It wouldn't necessarily be much state that's needed to have such a full-speed view. An array of 32 frames (say) to match the scheduling horizon; a pointer in the SITD and QH structs; and that's essentially what OHCI works with. Abstract it just a little bit, and it's potentially usable by non-EHCI code that needs to schedule a TT subtree. I'm moderately sure that decoupling TT scheduling from details that are EHCI-specific would make it easier to understand what's going on, and thus to produce better code. - Dave -- 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
