[lkml]   [2014]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
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
> More majordomo info at

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
if (ep->ep_state & EP_HAS_STREAMS) {
struct xhci_stream_ctx *ctx =
- state->new_cycle_state = 0x1 &
+ 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?


 \ /
  Last update: 2014-04-15 14:41    [W:0.050 / U:50.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site