> Any example of INT OUT endpoint writing would be nice.

Be aware that it's hard to do that portably just now,
and that the interrupt transfer API (with "automagic
resubmission") isn't really that well suited for this.

The basic issue is that while IN transfers can, on the
receiving side, work passably well with automagic
resubmit (unless the transfer interval is so short that
it runs into interrupt latency issues), the OUT side
doesn't work since the URB model is merging two rather
disparate concepts:  (a) reserving bandwidth for a given
INTR-OUT endpoint, and (b) having data to transfer.

For the INTR-IN case those are somewhat separated, since
the host side reserves the bandwidth while the device
side controls data availability.  Data is presented one
packet at a time, and drivers reassemble it into larger
chunks as needed, but that can be worked with.

But for the INTR-OUT case, this doesn't work so well
because there's no way to reserve the bandwidth without
also providing data:  submitting an URB does both.
When there's no more data to send, you've got to unlink
the urb ... giving up the bandwidth reservation.


The portable way to mostly work around that is to submit
an INTR-OUT transfer with your data, possibly using the
completion callbacks to refill your one-packet transfer
buffer until all your data is sent, then unlinking that
URB when all the data is sent.  Two problems there:  no
clean way to send the last packet "short" (many devices
behave reasonably if the rest is zeroed out) except by
submitting a new URB just for that packet; and then later
when you have more data to send, you have to manually
ensure you delay long enough to obey the transfer rate
restriction of the endpoint ... assuming (not always safe)
that the bandwidth is still available.

There's a nonportable (UHCI-only) workaround which is to
use a "one shot" interrupt transfer -- and which punts on
the requirement for scheduling the bandwidth, one transfer
every N frames.

I'm expecting 2.5 to fix this issue, with a better model
in all the HCDs, sometime after we get to having just one
UHCI driver.

- Dave






-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to