Mostly just making urb->interval work right:
Full/low speed: urb->interval = desc->bInterval;
High speed: urb->interval = (1 << desc->bInterval);
I am doing this, except it is
urb->interval = 1 << (desc->bInterval - 1);
right?
Yes, that's what I meant. What's a factor of
Dave --
> The general rule of thumb is that full (and low) speed
> transfers haven't changed interpretation -- except that
> as of 2.6, full speed iso periods may be multiple frames.
> High speed is (as above) in microframes.
Full speed interrupt transfers work for me, but high speed
do not. Thi
Borchers, Al (C)(STP) wrote:
Dave --
If you have a driver for a dual-speed device, the
driver needs to pay attention to high speed interrupt
transfers.
Can you elaborate? What do I need to pay attention to?
Mostly just making urb->interval work right:
Full/low speed: urb->interval = de
Dave --
> If you have a driver for a dual-speed device, the
> driver needs to pay attention to high speed interrupt
> transfers.
Can you elaborate? What do I need to pay attention to?
Thanks,
-- Al
---
This sf.net email is sponsored by:Thin
Borchers, Al (C)(STP) wrote:
How should the interval field in an urb for USB 2.0
interpretted? Is it microframes (125 micro-seconds)
as the ehci code seems to assume? Or should it be
interpretted like the bInterval field in an endpoint
descriptor?
In the urb, it's never a logarithmic encoding; i
