> 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 sketched out (API change #2) ...
you might look at that a bit more, and share comments on
that part of the original RFC.
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.
- I'd suggested that the bandwidth would stay scheduled until
after an interrupt transfer completed, there was no transfer
queued.
Yes, I tend to think that it might be worth breaking existing
interrupt transfer code in this way to get an improved API.
But it'd be work...
- Dave
p.s. I have similar comments about ISO transfers... :)
Apart from some wire-level differences, the main
structural difference between INTR and ISO is
supposed to be that (a) no lowspeed ISO, (b) for
fullspeed, INTR has a smaller maxpacket (64 bytes
vs 1023 for ISO), (c) at all speeds, errors on INTR
transfers are supposed to get retried, but ISO ones
get reported. Both are supposed to respect the
endpoint poll period, and "high bandwidth" mode
(up to 24 MByte/sec, highspeed) works much the same.
In short, we may want to consider corresponding
updates to the ISO transfer model, since it's not
intended to be as different from the INTR one as
it is today in Linux.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
