Hi,
It looks as if I somehow contrived to send a blank email yesterday, sorry about
that.
> > Mmm, spoke a bit too soon. Trying to find the sweet spot between 5 and 10
> > millisecs, I'm currently at ...... 20 milliseconds. I had done some testing
> > yesterday, copying 5-6MB files to and from compact flash and over the
> > wireless network, and all was OK. However, tonight I've been copying a
> > kernel tarball around and getting timeouts again, so it looks like I've
> > got some more work to do. Sorry for the noise :)
>
> That suggests a timeout isn't exactly the issue here ... it'd be more at
> the level of that (old) silicon wanting to get some register written, or
> maybe cleared.
>
> Random notion: before writing a new control or bulk list head, write a
> zero into that register and spin (up to a millisecond) until the next frame
> has started. One of the more subtle changes in that group of patches
> changed some behavior in that area, getting rid of a race. It's possible
> that the reason some earler code clobbered that register was because it
> was trying to run on hardware that misbehaved otherwise.
>
I'm pretty certain I've got the solution now and a patch against 2.6.11-rc4
follows. The problem was that I needed to add two more delays around the
area where I had already added two. The effect of adding these two is that
the duration of the delays now needs to be only 1 millisecond in each case.
Furthermore, the msleep(10) that was added to core/message.c early on in
this adventure is now no longer needed.
I've tested this much more thoroughly this time copying a kernel tarball
between
my laptop and other machines on my wireless lan and, on and off compact
flash. I've done this extensively over the last couple of evenings and haven't
suffered a single failure. I've also used a USB mouse with no problems. What's
more these tests have been with devices plugged directly into the USB port
and via an unpowered hub. Finally, I have tested with both 2.6.10 and
2.6.11-rc4
>
> > I would still value guidance on the questions I asked yetserday though.
>
> If you can find some approach that works reliably, I think the right way
> to package it would be by defining a new quirk flag and kicking in the
> logic that's needed on your chip. Then set that flag when the PCI probe
> detects this particular PCI vendor/product and this revision (or older).
Wow, you're taking me deeper and deeper into uncharted waters here, but what
the hell, I'll give it a go :-)
Thanks for the guidance so far.
Chris
--- linux-2.6.11-rc4/drivers/usb/host/ohci-q.c.orig 2005-02-13
03:07:40.000000000 +0000
+++ linux-2.6.11-rc4/drivers/usb/host/ohci-q.c 2005-02-23 21:16:16.000000000
+0000
@@ -1018,6 +1018,8 @@
if (ohci->ed_controltail) {
command |= OHCI_CLF;
+ /* give old and slow silicon a little time */
+ mdelay(1);
if (!(ohci->hc_control & OHCI_CTRL_CLE)) {
control |= OHCI_CTRL_CLE;
ohci_writel (ohci, 0,
@@ -1026,6 +1028,8 @@
}
if (ohci->ed_bulktail) {
command |= OHCI_BLF;
+ /* give old and slow silicon a little time */
+ mdelay(1);
if (!(ohci->hc_control & OHCI_CTRL_BLE)) {
control |= OHCI_CTRL_BLE;
ohci_writel (ohci, 0,
@@ -1036,12 +1040,17 @@
/* CLE/BLE to enable, CLF/BLF to (maybe) kickstart */
if (control) {
ohci->hc_control |= control;
+ /* give old and slow silicon a little time */
+ mdelay(1);
ohci_writel (ohci, ohci->hc_control,
&ohci->regs->control);
}
- if (command)
+ if (command) {
+ /* give old and slow silicon a little time */
+ mdelay(1);
ohci_writel (ohci, command, &ohci->regs->cmdstatus);
- }
+ }
+ }
}
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
