On Mon, 21 May 2007, David Brownell wrote:
> 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.
The start_frame values actually do get used by a few drivers:
drivers/media/video/usbvideo/konicawc.c
drivers/usb/misc/stimulus/stimulus.c
sound/usb/usx2y/usbusx2yaudio.c
sound/usb/usx2y/usx2yhwdeppcm.c
They test start_frame in various hacky ways, and some even try to set
urb->start_frame before submission.
So it would seem to be best to keep the get_frame() value as a frame
number. When people need higher precision we can add it.
(By the way, there may be another minor problem with ehci_get_frame.
I don't completely understand the EHCI spec, but it says that the frame
boundaries reported by the controller register differ by 125 us from
the frame boundaries transmitted on the bus. See sections 2.3.4 and
4.5. Should this be corrected for?)
> "Long term -- as yo"u probably guessed, I'd rather just see a single
> programming interface for such stuff. Easier to test, document, and
> maintain.
Me too. But what happens when USB 3.0 comes out and we have to deal
with "super-high-speed" (or "ultra-speed" or "hyper-speed" or whatever
they decide to call it) buses? -- I know, it's not possible to give a
reasonable answer at this time.
> > 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...
I wouldn't mind removing it. Presumably when a driver starts up an iso
stream, the exact starting time doesn't matter. But what if the new
stream needs to be in a prescribed phase relationship with an
already-existing iso stream? Or should we just not worry about this?
(And if we do remove it, there won't be any reason to keep
USB_ISO_ASAP, will there? HCDs would behave the same whether or not
the flag was turned on.)
> 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.
If we do support it, I think there should be some minimum figure for
drivers to rely on. Otherwise you're just shifting the burden from the
HCDs to the drivers. I'm okay with 1/4 second.
Alan Stern
-------------------------------------------------------------------------
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
