On Thursday November 10, [EMAIL PROTECTED] wrote:
> >
> > I'll let you know how it goes.
>
> Good luck,
Thanks. It didn't go as well as I hoped, but I've made progress.
I tried:
- disabling the return channel, so input requests aren't sent
- forcing depth-first rather than breadth first traversal
- removing the FR-control queue altogether
- removing the isochronous queues all together
and each of these seemed to make a small improvement (though given the
normal variance, I didn't do enough tests to give precise results).
It seems that by giving the HC less work to do walking pointers in
QHs, the better it gets. This sounds weird, but I reduced the time for
my test job from 5 minutes to 55 seconds, and the last drop from about
1:10 to 55 was through removing the isochronous queues
(setting
uhci->frame[i] = uhci->skel_int1_qh->link;
for all i).
Maybe the printer is very sensitive to timing and the extra time it
takes the HC to walk this pointers makes a difference??? I'm not sure
I believe that, but it is the only explanation I can come up with so
far. Unfortunately it doesn't help me solve the real problem...
Is it possible to make fine adjustments to the clock that the HC uses?
(I know the USB is self clocked, and the gadget should just sync with
that, but something is definitely wrong, so I'm making wild guesses).
During my explorations I think I found another typo.
As I understand the code, if a URB takes longer than 50ms to complete,
it is switched to use depth-first traversal, presumably to give it more
bandwidth. I gather from the comments that it is meant to arrange for
5 transactions to go for every loop around the QHs, rather than the
normal one. However this isn't what the code does. It actually
arranges for 2 to go out instead of 1 every 5 times around the loop.
Also, I'm not sure the 50ms is actually effective. It seems that the
timeout is implemented by the root-hub timer calling hub_status_data,
which it only does every 250ms. So it looks to me like it is really a
250ms timeout before switching to depth-first.
However, I don't completely understand the code, so I'm probably
missing something.
One bit I don't understand is why FSBR is switched of for URBs which
have changed to depth-first. I cannot see any benefit in switching
off FSBE if there are any outstanding bulk URBs at all.
Anyway, the code where I think there is a typo, and my proposed
correction, is below.
Thanks,
NeilBrown
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/usb/host/uhci-q.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff ./drivers/usb/host/uhci-q.c~current~ ./drivers/usb/host/uhci-q.c
--- ./drivers/usb/host/uhci-q.c~current~ 2005-11-12 15:31:52.000000000
+1100
+++ ./drivers/usb/host/uhci-q.c 2005-11-12 15:31:57.000000000 +1100
@@ -1416,7 +1416,7 @@ static int uhci_fsbr_timeout(struct uhci
* TERM bit set) as well as we skip every so many TD's to
* make sure it doesn't hog the bandwidth
*/
- if (td->list.next != head && (count % DEPTH_INTERVAL) ==
+ if (td->list.next != head && (count % DEPTH_INTERVAL) !=
(DEPTH_INTERVAL - 1))
td->link |= UHCI_PTR_DEPTH;
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
