2005/9/7, David Brownell <[EMAIL PROTECTED]>:
> > When you say NAK is not an error case, this is true except for setup
> > stage. Functions cannot issue a NAK packet in response to a setup
> > packet. In that case, it is an _error_, is it correct ?
>
> If they can't issue it, why are you worried about how your
> host side code would handle such out-of-spec peripherals?
> Do you have one that "must work" with your code? (Out-of-spec
> means you can handle those peripherals any convenient way...)
>
> A good rule in protocols is "be strict when sending and
> tolerant when receiving". Strict function/peripheral code
> won't NAK any SETUP packets. Lenient host code will recover
> (where possible) from peripherals that do make that mistake.
>
You're right, it seems the simplest solution. So waiting for control
transaction to time out is a good solution, thanks.
>
> > Most important question, let say for an interrupt point "URB1" is
> > submitted. The HCD checks that this endpoint is not already scheduled
> > and if not it schedules it if there's enough bandwidth.
>
> OK...
OMG, I'm starting to understand ;)
>
> > Now "URB2" is
> > submitted for the same endpoint and "URB1" is still in the queue. The
> > driver detects that the endpoint is already scheduled and so does
> > nothing (BTW, URB2->start_frame is not setup, isn't it ?).
>
> That's right. The start_frame thing is a minor oversight;
> I don't think any in-tree drivers ever used that field.
>
That was my poor contribution to your work ;)
>
> > Why bandwith allocation is not done ?
>
> Because the bandwidth was already allocated; allocations apply to
> the entire time that the endpoint stays scheduled. Allocation
> is on-demand, where "demand" == "an URB is submitted".
>
>
> > Now "URB1" is processed and
> > "finish_request" is called. "URB2" is the next periodic transfer in
> > the queue and so is the next transfer for this endpoint. it seems to
> > be started in the same frame as "URB1", shouldn't it be started for
> > the next period ?
>
> You may be confusing the async schedule (which always takes the next
> transfer from a ring, any number of times before end-of-frame) with
> the periodic schedule (which scans a fixed list of transfers for each
> frame). The periodic schedule can't do multiple transfers to a given
> endpoint in one frame. (High speed is a bit different, of course.)
>
yeah, and I'm still confused :)
Just to be sure, you mean if "URB1" is done at frameX then "URB2" must
be done at frameX + URB2->intervall ? Can you point out the section of
USB spec that explains this, please ?
BTW, in "balance" function, why does index "i" start to 0 and not to
current frame number ?
>
> > In "finish_request", if the endpoint has not more transaction in its
> > queue, when is "ep" variable freed ?
>
> Endpoints are freed when usbcore disables endpoints.
> (After all pending URBs have first completed...)
> They're not coupled to URBs in the way you imply.
oh ok, usbcore calls hcd's "disable_endpoint" function when an
endpoint has no more pending URBs. So why endpoint deschedule is not
done in this function ? It seems to appear in "finish_request" when no
more (periodic and async) transfers are pending.
Thanks !!
--
Franck
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
