On Tuesday 01 February 2005 1:16 pm, Chris Clayton wrote:
> So the "offending" patch is the one
> that took ohci-q.c to revision 1.48. Would it help if I tried to work out
> which hunk, or hunks, of that patch cause me the problem? Or is it not
> possible to have part(s) of the patch without the rest? I'm afraid I simply
> don't have the knowledge to answer that.
Given how simple 1.48 was, there's not a lot that can be removed!
What I think happened is that patch missed something. Specifically,
it didn't prevent the driver from setting the CLF or BLF bits while
the queue is empty because its only endpoint is being descheduled,
but a new transaction is submitted against it(*). Most hardware
evidently doesn't care; yours may. Certainly those bits were left
set, when they shouldn't have been.
Please see if this patch makes a difference.
- Dave
(*) EHCI has similar cases, where those new transactions will
often be started -- and maybe even completed!! -- by the time
the endpoint gets fully descheduled. OHCI isn't as fast;
and EHCI doesn't have analogues of CLF or BLF.
--- 1.74/drivers/usb/host/ohci-q.c 2005-01-10 12:51:55 -08:00
+++ edited/drivers/usb/host/ohci-q.c 2005-02-01 14:29:35 -08:00
@@ -644,7 +644,8 @@
cnt++;
}
/* maybe kickstart bulk list */
- if (urb_priv->ed->type == PIPE_BULK) {
+ if (ohci->hc_control & OHCI_CTRL_BLE
+ && urb_priv->ed->type == PIPE_BULK) {
wmb ();
ohci_writel (ohci, OHCI_BLF, &ohci->regs->cmdstatus);
}
@@ -667,8 +668,10 @@
: TD_CC | TD_DP_OUT | TD_T_DATA1;
td_fill (ohci, info, data, 0, urb, cnt++);
/* maybe kickstart control list */
- wmb ();
- ohci_writel (ohci, OHCI_CLF, &ohci->regs->cmdstatus);
+ if (ohci->hc_control & OHCI_CTRL_CLE) {
+ wmb ();
+ ohci_writel (ohci, OHCI_CLF, &ohci->regs->cmdstatus);
+ }
break;
/* ISO has no retransmit, so no toggle; and it uses special TDs.
