public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Julius Werner <jwerner@chromium.org>
Cc: "Nyman, Mathias" <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Sarah Sharp <sarah.a.sharp@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Vincent Palatin <vpalatin@chromium.org>,
	Luigi Semenzato <semenzato@chromium.org>
Subject: Re: [PATCH] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
Date: Tue, 15 Apr 2014 15:39:53 +0300	[thread overview]
Message-ID: <534D2899.3030503@linux.intel.com> (raw)
In-Reply-To: <CAODwPW9ziqrT2THof7D6Y6_AVbk9Mvo9YteLJp7-KstAKoSzSA@mail.gmail.com>

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@vger.kernel.org
> 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




  parent reply	other threads:[~2014-04-15 12:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-21  5:12 [PATCH] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb Julius Werner
2014-02-28 20:53 ` Sarah Sharp
2014-04-02 21:29   ` Julius Werner
2014-04-03  8:38     ` Mathias Nyman
2014-04-15 12:39     ` Mathias Nyman [this message]
2014-04-15 19:42       ` Julius Werner
2014-04-15 20:41         ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=534D2899.3030503@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jwerner@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=sarah.a.sharp@linux.intel.com \
    --cc=semenzato@chromium.org \
    --cc=vpalatin@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox