public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
To: keithp@keithp.com
Cc: linux-usb@vger.kernel.org, dan.j.williams@intel.com,
	linux-kernel@vger.kernel.org,
	Mathias Nyman <mathias.nyman@linux.intel.com>
Subject: Re: [RFC 00/10] xhci: re-work command queue management
Date: Mon, 27 Jan 2014 15:58:18 -0800	[thread overview]
Message-ID: <20140127235818.GF2860@xanatos> (raw)
In-Reply-To: <1389625559-32414-1-git-send-email-mathias.nyman@linux.intel.com>

Hi Keith,

You've told me in the past that you've run into an issue where you can
hang the xHCI driver when one of your TeleMetrum boards refuses to
respond to a Set Address command.

Can you test the following patchset, and see if it fixes your problem?
I've applied the patchset against 3.13 here:

https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/log/?h=for-usb-next-command-queue

Thanks,
Sarah Sharp

On Mon, Jan 13, 2014 at 05:05:49PM +0200, Mathias Nyman wrote:
> This is an attempt to re-work and solve the issues in xhci command
> queue management that Sarah has descibed earlier: 
> 
> Right now, the command management in the xHCI driver is rather ad-hock.  
> Different parts of the driver all submit commands, including interrupt 
> handling routines, functions called from the USB core (with or without the
> bus bandwidth mutex held).
> Some times they need to wait for the command to complete, and sometimes 
> they just issue the command and don't care about the result of the command.
> 
> The places that wait on a command all time the command for five seconds,
> and then attempt to cancel the command.  
> Unfortunately, that means if several commands are issued at once, and one of
> them times out, all the commands timeout, even though the host hasn't gotten
> a chance to service them yet.
> 
> This is apparent with some devices that take a long time to respond to the 
> Set Address command during device enumeration (when the device is plugged in).
> If a driver for a different device attempts to change alternate interface
> settings at the same time (causing a Configure Endpoint command to be issued),
> both commands timeout.
> 
> Instead of having each command timeout after five seconds, the driver should
> wait indefinitely in an uninterruptible sleep on the command completion.  
> A global command queue manager should time whatever command is currently
> running, and cancel that command after five seconds.
> 
> If the commands were in a list, like TDs currently are, it may be easier to keep
> track of where the command ring dequeue pointer is, and avoid racing with events.
> We may need to have parts of the driver that issue commands without waiting on
> them still put the commands in the command list.
> 
> The Implementation:
> -------------------
> 
> First step is to create a list of the commands submitted to the command queue.
> To accomplish this each command is required to be submitted with a properly
> filled command structure containing completion, status variable and a pointer to
> the command TRB that will be used.
> 
> The first 7 patches are all about creating these command structures and
> submitting them when we queue commands.
> The command structures are allocated on the fly, the commands that are submitted
> in interrupt context are allocated with GFP_ATOMIC.
> 
> Next, the global command queue is introduced. Commands are added to the queue
> when trb's are queued, and remove when the commad completes. 
> Also switch to use the status variable and completion in the command struct.
> 
> A new timer handles command timeout, the timer is kicked every time when a 
> command finishes and there's a new command waiting in the queue, or when a new
> command is submitted to an _empty_ command queue.
> Timer is deleted when the the last command on the queue finishes (empty queue)
> 
> The old cancel_cmd_list is removed. 
> When the timer expires we simply tag the current command as "ABORTED" and start
> the ring abortion process. Functions waiting for an aborted command to finish are
> called after the command abortion is completed.
> 
> Mathias Nyman (10):
>   xhci: Use command structures when calling xhci_configure_endpoint
>   xhci: use a command structure internally in xhci_address_device()
>   xhci: use command structures for xhci_queue_slot_control()
>   xhci: use command structures for xhci_queue_stop_endpoint()
>   xhci: use command structure for xhci_queue_new_dequeue_state()
>   xhci: use command structures for xhci_queue_reset_ep()
>   xhci: Use command structured when queuing commands
>   xhci: Add a global command queue
>   xhci: Use completion and status in global command queue
>   xhci: rework command timeout and cancellation,
> 
>  drivers/usb/host/xhci-hub.c  |  42 ++--
>  drivers/usb/host/xhci-mem.c  |  22 +-
>  drivers/usb/host/xhci-ring.c | 532 ++++++++++++++-----------------------------
>  drivers/usb/host/xhci.c      | 264 +++++++++++----------
>  drivers/usb/host/xhci.h      |  43 ++--
>  5 files changed, 373 insertions(+), 530 deletions(-)
> 
> -- 
> 1.8.1.2
> 

      parent reply	other threads:[~2014-01-27 23:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-13 15:05 [RFC 00/10] xhci: re-work command queue management Mathias Nyman
2014-01-13 15:05 ` [RFC 01/10] xhci: Use command structures when calling xhci_configure_endpoint Mathias Nyman
2014-01-13 15:05 ` [RFC 02/10] xhci: use a command structure internally in xhci_address_device() Mathias Nyman
2014-01-13 15:05 ` [RFC 03/10] xhci: use command structures for xhci_queue_slot_control() Mathias Nyman
2014-01-13 15:05 ` [RFC 04/10] xhci: use command structures for xhci_queue_stop_endpoint() Mathias Nyman
2014-01-13 15:05 ` [RFC 05/10] xhci: use command structure for xhci_queue_new_dequeue_state() Mathias Nyman
2014-01-13 15:05 ` [RFC 06/10] xhci: use command structures for xhci_queue_reset_ep() Mathias Nyman
2014-01-13 15:05 ` [RFC 07/10] xhci: Use command structured when queuing commands Mathias Nyman
2014-01-13 15:05 ` [RFC 08/10] xhci: Add a global command queue Mathias Nyman
2014-01-13 15:05 ` [RFC 09/10] xhci: Use completion and status in " Mathias Nyman
2014-01-13 15:05 ` [RFC 10/10] xhci: rework command timeout and cancellation, Mathias Nyman
2014-01-13 16:58 ` [RFC 00/10] xhci: re-work command queue management David Laight
2014-01-14 12:05   ` Mathias Nyman
2014-01-14 12:37     ` David Laight
2014-01-15 15:43       ` Mathias Nyman
2014-01-27 23:58 ` Sarah Sharp [this message]

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=20140127235818.GF2860@xanatos \
    --to=sarah.a.sharp@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=keithp@keithp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    /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