Hi Mathias,
...
How about a different approach?
If the issue is only with transfers starting on the last TRB before
the link TRB, we could turn that TRB to a no-op.
Does something like the code below help?
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 6cdea0d00d19..0ffda8127640 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3181,6 +3181,12 @@ static int prepare_ring(struct xhci_hcd *xhci,
struct xhci_ring *ep_ring,
}
}
+ if (ep_ring != xhci->cmd_ring &&
+ !trb_is_link(ep_ring->enqueue) &&
+ trb_is_link(ep_ring->enqueue + 1))
+ queue_trb(xhci, ep_ring, 0, 0, 0, 0,
+ TRB_TYPE(TRB_TR_NOOP) | ep_ring->cycle_state);
+
while (trb_is_link(ep_ring->enqueue)) {
/* If we're not dealing with 0.95 hardware or isoc rings
* on AMD 0.96 host, clear the chain bit.
Your patch seems to work. I can record video with this and it seems
stable so far.
But there is still something off (as with my patch): If I stop the video
recording and try to record again, the camera does not give me any
frames. Maybe this is an unrelated issue but it works fine on the two
other host controllers that I tested.
If you are interested you can find a trace here:
https://stuff.salscheider.org/dmesg_second
https://stuff.salscheider.org/trace_second
In this trace I recorded a few seconds of video with ffmpeg, killed it
(at second 108) and restarted it (at second 116). Can you see anything
suspicious in the trace?
I guess this second issue is unrelated. The cameras have worked stable
so far with your patch. It might be good to include this workaround in
mainline. Will you take care of it or should I send something to the list?
Thanks and best regards,
Ole
