On Mon, 16 Oct 2006, Christopher "Monty" Montgomery wrote:

> > > Maybe 'polling' in general is the right call after all.  It's not
> > > really polling if we know exactly when we should be checking for
> > > completions.
> >
> > How would you know exactly when to check?
>
> You have the uframe clock, you know where the packets were scheduled
> and you have a kernel timer.  The only unknown is the exact completion
> uframe within the three uframe window... so check all three, it's
> still carefully bounded.
>
> >  And how would arrange to check
> > at that precise moment?
>
> Kernel timer.  I understand there are resolution issues, but if that's
> the only hill to surmount...

I'll say!  At the moment you can't get resolution better than 4 ms, with
the standard setting for HZ.  For the time being let's forget about
polling.  You may find that you don't need it.


> > Yes, differing interpretations.  Perhaps we should introduce a new URB
> > submission flag, such as URB_ISO_STRICT, which would mean to schedule each
> > packet for its intended slot even if it's already too late.  That way the
> > driver could choose which policy to follow.
> 
> I've seen the equivalent of ISO_ASAP in other drivers and had assumed
> there was a standard set that USB defined or at least recommended....

Not as far as I know.

> > > I hope we agree that on URB completion, start_frame indicates when that
> > > frame started.
> >
> > When the URB started, yes.  Or was nominally scheduled to start in the
> > case of URB_ISO_STRICT, since it didn't actually start until some time
> > later.
> 
> What happens when the driver specifies a frame that differs from the
> slot is was scheduled into?  Take the next available?  Reject?  "Do
> what I say, damn the budget, no questions"?  If scheduled into a slot
> different than the requested one, I assume we'd have to modify the
> start_frame field.
> 
> Any of these are easily possible, which is most correct?  This is
> beginning to feel like it's on the cusp of being hashed out enough to
> impelement.

If either URB_ISO_ASAP or URB_ISO_STRICT is set then urb->start_frame is
ignored; the HCD will set start_frame to the value it selects (the next
available slot for ASAP or the one following the end of the previous URB
for STRICT).

If neither of those flags is set then the HCD does pay attention to 
start_frame.  At this point the URB hasn't been scheduled into any slots 
yet; the HCD uses start_frame to select the slots where the URB should go.  

If this isn't the first URB in the stream then there should not be any 
problem, assuming start_frame actually is one of the allocated slots.  If 
this is the first URB in the stream then the submission will fail if the 
requested slot doesn't have sufficient bandwidth remaining.

> Which of the options I listed above is closes to what UHCI currently does?

Reject.  But that's quite likely to change.

Alan Stern


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to