On Monday 21 May 2007, Alan Stern wrote: > Dave: > > The situation with regard to start_frame is a mess. Although the name > and the documentation refer to frame numbers, for high speed devices > the value stored there is a microframe number instead. > > Clearly anyone who's interested in the value will want to know the full > microframe number. But on the other hand, the value returned from > ehci_get_frame() actually _is_ a frame number, so there's no way for > drivers to learn the current microframe. Thus we have several related > problems: How to tell whether you're dealing with frames or microframes > and when to use each. Any suggestions on how to solve them?
Simplest notion: define new primitives that always work in terms of microframes, convert to using them exclusively. Full speed ISO would ignore the LSBs. Phase out the old primitives; it's not as if anyone can rely on them much right now ... Alternatively, do that but make the old primitives work right and don't phase them out. At least, not for a year or two; this would help if anyone actually uses those primitives right now. Long term -- as yo > Also, it seems to me that drivers ought to be able to take the current > (micro)frame value, add a small amount to it, and specify the result as > the start frame for an URB. But such behavior is not documented as > always workable, In fact it's documented as barely supported. Only UHCI attempts to do that, AFAIK. > and we don't have any firm standard for how big the > "small amount" can be. My feeling is that all HCDs should guarantee > that anything up to 1 second will be acceptable. What do you think? First, do we even want to support that "please use this start frame" mechanism? I'm not sure we do. We can't have many users that care about it right now, so removing it should be cheap... Second, if we were to want to support it, I think that kind of absolute limit is inadvisable. EHCI uses 1/4 second scheduling horizons whenever it can, because of performance issues (cache trashing on some PPCs) with the larger 1 second horizon. Some controllers would need to emulate that in software by having a second "we didn't yet tell the hardware about it" schedule. Better to have the HCD export what it can handle. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
