On 04/03/2014 12:29 AM, Julius Werner wrote:
Hi Mathias,
The patch looks fine. Mathias is taking over for xHCI driver
maintainership in 3.15. He's currently handling queuing bug fix patches
for 3.14 while I finish queueing feature patches for 3.15. Mathias,
will you test and queue this up for 3.14?
Did you pick this patch up anywhere yet or are there still issues with
it? I just want to make sure it doesn't slip through the cracks.
(Maybe I just didn't see it yet... are you still queueing patches in
sarah/xhci.git or do you have your own repository somewhere?)
--
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
I tried to apply this patch on top of 3.15-rc1, but it fails because of
the streams support added to xhci_find_new_dequeue_state()
After some manual editing the interesting parts of
xhci_find_new_dequeue_state() looks like this:
@@ -577,46 +568,57 @@ void xhci_find_new_dequeue_state(struct xhci_hcd
*xhci,
if (ep->ep_state & EP_HAS_STREAMS) {
struct xhci_stream_ctx *ctx =
&ep->stream_info->stream_ctx_array[stream_id];
- state->new_cycle_state = 0x1 &
le64_to_cpu(ctx->stream_ring);
+ hw_dequeue = le64_to_cpu(ctx->stream_ring);
} else {
struct xhci_ep_ctx *ep_ctx
= xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
- state->new_cycle_state = 0x1 & le64_to_cpu(ep_ctx->deq);
+ hw_dequeue = le64_to_cpu(ep_ctx->deq);
}
+ /* Find virtual address and segment of hardware dequeue pointer */
+ state->new_deq_seg = ep_ring->deq_seg;
+ state->new_deq_ptr = ep_ring->dequeue;
+ while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
+ != (dma_addr_t)(hw_dequeue & ~0x1)) {
+ next_trb(xhci, ep_ring, &state->new_deq_seg,
+ &state->new_deq_ptr);
+ if (state->new_deq_ptr == ep_ring->dequeue) {
+ WARN_ON(1);
+ return;
+ }
+ }
But I'm still concerned about the dequeue pointer in the streams case.
streams may be nested, we might be pointing at another stream context
instead of the dequeue pointer.
Also the comparison of the dequeue pointers, using (hw_dequeue & ~0x1)
might have some troubles with streams. Endpoint context TR dequeue
pointer LO field has bits 3:1 reserved (probably zero) but stream
context uses those bits. Would it make sense to use (hw_dequeue & ~0xf)
here instead?
So there's still some work needed. Are you interested in re-working this
to fit on top of 3.15-rc1 or should I add it to my todo list?
-Mathias
--
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
