> > EHCI can't really do "square tetris". It's not a video game. ;) > > Very funny :-)
:) And also, the parts are not uniform. ITDs are uniform; SITDs are not, especially in conjunction with FSTNs. > What I meant was that the USB docs make it very clear (in examples and > whitepapers, less so in the formal spec) that drivers are expected to > rebuild schedules from scratch with every endpoint subtraction (or > lazily at at addition time) such that all holes are compressed out of > the schedule at every step. HCDs are _allowed_ to do that if they want. I don't really see any point to doing that rebalancing unless the schedule doesn't have enough space otherwise. > I've not yet read source for a driver > that actually does this, but every presentation example I've seen from > a USB committee member illustrates it that way. So, someone's drivers > somewhere are doing it 'the right way'. I wouldn't bet on it, myself. Presentations quite routinely aim to mislead on such topics. Though you have a point that it might be useful for transaction translators. (And if you can abstract that TT support well enough that it could work with different high speed HCDs that would be a Good Thing... even if the re-use is mostly at the design level, not as code.) > Also, QHs will often need to be stuck into a slot that is already > full, pushing other QHs out into earlier slots. I've also not seen > any other drivers do that (they just say no bandwidth). It's needed > for the case where, eg, uFrame 5 is full of QHs, there's a QH in > uFrame 4, but a new FS QH *must* go into uFrame 5 because of its level > in the intr tree (the complete splits must be processed in order of > the original ssplits when the transactions overlap! So you end up > constrained to scheduling the QHs into uFrames in the same order the > QHs appear in the tree despite the apparently superflexible scheduling > mechanisms). Good fun, eh? :) > So... like square tetris with a little 'Dig Dug' thrown in. And alot > less Q*bert. Or "Joust" ... gotta keep re-issuing periodic "fly" URBs! ;) > > How long it takes is orthogonal. So long as the "reactivate" can see > > the old schedule position, and verify it, that's sufficient to make > > sure the jigsaw puzzle goes back together in the same way. > > Not in the rebalancing case, because the old slot would be gone. Or > if we're scheduling anew and need to move QH, the slot was previously > not there. I see your point, yes ... but that's restricted to the TT cases, and not all of them either. Example, take one out and the space in the schedule is still present, so it can go right back into the same schedule slot; and so on. > Because we need to *move* slots in rebalancing, there will be a time > when the budget and schedule disagree. We can't just hold a spinlock > the whole time, and we can't just blindly schedule on obsolete (or > not-yet-valid) information. I'd say it's a bug if the schedule and budget ever disagree... > I'm not worried about timing in the jigsaw puzzle case if we stop at > the jigsaw puzzle and don't do anything more aggressive. I'm only > woried about active rebalancing. Probably the first solution should just identify the "we need to rebalance" case and treat that as an error. That would not be any worse than what we have today. - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
