Dears,
the patch you provide: but the one line does not patch for mine:
do you have any idea about any side effect if I ignore the line?
=====================================================
I have an experimental patch, below. It hasn't been tested. Let me
know what happens when you try it.
Alan Stern
Index: usb-2.6/drivers/usb/host/ehci.h
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci.h
+++ usb-2.6/drivers/usb/host/ehci.h
@@ -117,6 +117,7 @@ struct ehci_hcd { /* one per controlle
struct timer_list watchdog;
unsigned long actions;
unsigned stamp;
+ unsigned periodic_stamp;
unsigned random_frame;
unsigned long next_statechange;
ktime_t last_periodic_enable;
Index: usb-2.6/drivers/usb/host/ehci-q.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-q.c
+++ usb-2.6/drivers/usb/host/ehci-q.c
@@ -838,6 +838,7 @@ qh_make (
is_input, 0,
hb_mult(maxp) * max_packet(maxp)));
qh->start = NO_FRAME;
+ qh->stamp = ehci->periodic_stamp;
if (urb->dev->speed == USB_SPEED_HIGH) {
qh->c_usecs = 0;
Index: usb-2.6/drivers/usb/host/ehci-sched.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-sched.c
+++ usb-2.6/drivers/usb/host/ehci-sched.c
@@ -2261,6 +2261,7 @@ scan_periodic (struct ehci_hcd *ehci)
}
clock &= mod - 1;
clock_frame = clock >> 3;
+ ++ehci->periodic_stamp;
for (;;) {
union ehci_shadow q, *q_p;
@@ -2289,10 +2290,14 @@ restart:
temp.qh = qh_get (q.qh);
type = Q_NEXT_TYPE(ehci, q.qh->hw->hw_next);
q = q.qh->qh_next;
- modified = qh_completions (ehci, temp.qh);
- if (unlikely(list_empty(&temp.qh->qtd_list) ||
- temp.qh->needs_rescan))
- intr_deschedule (ehci, temp.qh);
+ if (temp.qh->stamp != ehci->periodic_stamp) {
+ modified = qh_completions(ehci, temp.qh);
+ if (!modified)
+ temp.qh->stamp = ehci->periodic_stamp;
+ if (unlikely(list_empty(&temp.qh->qtd_list) ||
+ temp.qh->needs_rescan))
+ intr_deschedule(ehci, temp.qh);
+ }
qh_put (temp.qh);
break;
case Q_TYPE_FSTN:
@@ -2427,6 +2432,7 @@ restart:
free_cached_lists(ehci);
ehci->clock_frame = clock_frame;
}
+ ++ehci->periodic_stamp; -------------------> this line does not applied
} else {
now_uframe++;
now_uframe &= mod - 1;
--
________________________________________
From: Alan Stern [stern@xxxxxxxxxxxxxxxxxxx]
Sent: Friday, March 25, 2011 11:11 PM
To: BradHuang
Cc: USB list
Subject: RE: ehci scan_periodic loop time
Please use Reply-to-All so that your messages get sent to the mailing
list as well as to me.
On Fri, 25 Mar 2011, bradhuang wrote:
> Dears,
>
> Could you kindly help to explain the meaning of your patch again?
> Since I do a test, it seems the watchdog reset issue has fixed.
> When I apply your patch, but there is a lack for scan_periodic(), in the
> line below:
>
> // FIXME: this assumes we won't get lapped when
> // latencies climb; that should be rare, but...
> // detect it, and just go all the way around.
> // FLR might help detect this case, so long as latencies
> // don't exceed periodic_size msec (default 1.024 sec).
>
> // FIXME: likewise assumes HC doesn't halt mid-scan
>
> if (now_uframe == clock) {
> unsigned now;
>
> if (!HC_IS_RUNNING (ehci_to_hcd(ehci)->state)
> || ehci->periodic_sched == 0)
> break;
> ehci->next_uframe = now_uframe;
> //now = ehci_readl(ehci, &ehci->regs->frame_index) %
> mod; //brad
> now = ehci_readl(ehci, &ehci->regs->frame_index) &
> (mod - 1); //brad
> if (now_uframe == now)
> break;
>
> /* rescan the rest of this frame, then ... */
> clock = now;
> clock_frame = clock >> 3;
> if (ehci->clock_frame != clock_frame) {
> free_cached_lists(ehci);
> ehci->clock_frame = clock_frame;
> }
> ++ehci->periodic_stamp; ==============> I do not
> patch this line
> } else {
> now_uframe++;
> //now_uframe %= mod;//brad
> now_uframe &= mod - 1;
> }
Where is the problem? In the current version of the kernel,
ehci->periodic_stamp has been removed completely.
What version of the kernel are you using? Can you try using 2.6.38?
Alan Stern--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
