> >One difference between that and what Roman sketched
> >was that I did was in the model for schedule management:
> >
> >- He suggested a new HCD level "set_endpoint_properties"
> > call (perhaps coupled to set_config and set_interface?)
> > to schedule the bandwidth.
> >
> This is just the old
Dan Streetman wrote:
>On Tue, 26 Feb 2002, Roman Weissgaerber wrote:
>
>>>- I'd suggested that the bandwidth would stay scheduled until
>>> after an interrupt transfer completed, there was no transfer
>>> queued.
>>>
>>If I understand you right here, I think you lose the offset (or phase)
>>infor
On Tue, 26 Feb 2002, Roman Weissgaerber wrote:
>>- I'd suggested that the bandwidth would stay scheduled until
>> after an interrupt transfer completed, there was no transfer
>> queued.
>>
>If I understand you right here, I think you lose the offset (or phase)
>information
>of the interrupt sc
I guess I should have read that more closely ;-)
Yep, your #2 part (1) is certainly what sounds the best to me.
And as you said, it would remove any need for special handling of
int-outs. And the BW should certainly be allocated while any URBs are
in the queue.
Also, this would be a good oppor
David Brownell wrote:
>>If INTs could be queued, there would not really even be a need to
>>'resubmit' the URBs. The completion handler can simply resubmit a
>>completed URB (if desired) without any loss of data or polling time.
>>
>
>For the record, this is going down the path of the "support
>
> If INTs could be queued, there would not really even be a need to
> 'resubmit' the URBs. The completion handler can simply resubmit a
> completed URB (if desired) without any loss of data or polling time.
For the record, this is going down the path of the "support
multi-buffering" proposal I s
Dan Streetman wrote a lot of stuff about interrupt transfer model...
> So, if my opinion counts for anything, I would vote for (first) allow
> INT URBs to be queued and (second) remove URB
> auto-resubmission entirely.
I was too lazy to write up such a detailed discussion, but I agree 100%
w
I _really_ like usb-ohci's behavior, and I wish usb-uhci/uhci behaved
the same way. In particular, I think queueing INTs is essential.
Allowing queueing (could) lead to not auto-resubmitting.
If INTs could be queued, there would not really even be a need to
'resubmit' the URBs. The completion
David Brownell wrote:
>
>GOAL: support INTR-OUT and INTR-IN transfers with
>one API model which could also be used for a device
>controller API using an URB-like model.
>
>
>CURRENT MODEL: all interrupt transfers are specified
>with using an URB with transfer_buffer_length set to a
>fixed packe
I thought the first suggestion here made the most sense,
allowing you to change the size of the URB buffer.
I agree that a new function is the best way to do this (as
opposed to allowing people to change the size themselves
directly in the urb and picking up the change on resubmission)
for the fo
Hello David,
> API CHANGE #1: Let INTR completion handlers change
> the transfer_buffer_length. A value of "-1" (it's not
> a size_t!!) would mean "don't transfer anything". Any
> other value, up to the maximum allowed by the endpoint
> descriptor (which is what would control the bandwidth
> a
Given the discussion on INTR-OUT transfers, I thought it'd
be useful to write out my current thoughts on how we should
resolve this ... since it involves driver API changes as well as
changes to each of the host controller drivers.
Here's a quick writeup, including rationale and some sketches
of
12 matches
Mail list logo
