All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@intel.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH v2 RFT] usb: xhci: Add to check CRR bit in xhci_suspend()
Date: Tue, 26 May 2015 11:44:31 +0000	[thread overview]
Message-ID: <55645C9F.4010207@intel.com> (raw)
In-Reply-To: <1431596357-4460-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>

On 14.05.2015 12:39, Yoshihiro Shimoda wrote:
> The STS_HALT is not set until the CRR (CMD_RING_RUNNING) is cleared
> on specific xHCI controllers (e.g. R-Car SoCs) after this driver set
> the R/S (CMD_RUN) to 0. So, to avoid using a quirks XHCI_SLOW_SUSPEND,
> this patch adds to wait for the CRR to clear.
> 
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
>  My environment (R-Car H2) could work correctly. I would like to know
>  that this patch causes side effect or not. Also I'd like to know
>  this patch can avoid the XHCI_SLOW_SUSPEND quirk on other environment
>  (Fresco Logic XHCI controller).
> 
>  Changes from v1:
>   - Remove a abort code.
>   - Wait for the CRR to clear after this driver set the R/S to 0.
>   - Rebase on the usb.git / usb-next branch.
>     (commit id = aa519be34f45954f33a6c20430deac8e544a180f)
> 
>  drivers/usb/host/xhci.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index ec8ac16..a357917 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -923,6 +923,15 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
>  	command &= ~CMD_RUN;
>  	writel(command, &xhci->op_regs->command);
>  
> +	/*
> +	 * The STS_HALT is not set until the CRR is cleared on specific
> +	 * xHCI controllers (e.g. R-Car SoCs) after this driver set the R/S
> +	 * to 0. So, to avoid using a quirks XHCI_SLOW_SUSPEND, this driver
> +	 * waits for the CRR to clear.
> +	 */
> +	xhci_handshake(&xhci->op_regs->cmd_ring, CMD_RING_RUNNING, 0,
> +		       5 * 1000 * 1000);
> +
>  	/* Some chips from Fresco Logic need an extraordinary delay */
>  	delay *= (xhci->quirks & XHCI_SLOW_SUSPEND) ? 10 : 1;
>  
> 

Hi, sorry about the delay.

Does polling for the command ring running bit really help?
We are anyway polling for the HCHalted (STS_HALT) status bit right after this,
and it should indicate the command ring was halted as well.

Is it possible that the R-Car xhci host controller halts just a tiny bit slower
than the default delay value, and the additional CRR check gives it
just enough time to HALT before timeout?

Any chance you could compare the actual halt time using your patch against 
the XHCI_SLOW_SUSPEND quirk?  (time from clearing CMD_RUN until STS_HALT is set)

-Mathias

  reply	other threads:[~2015-05-26 11:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14  9:39 [PATCH v2 RFT] usb: xhci: Add to check CRR bit in xhci_suspend() Yoshihiro Shimoda
2015-05-26 11:44 ` Mathias Nyman [this message]
2015-06-03 10:14 ` Yoshihiro Shimoda

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=55645C9F.4010207@intel.com \
    --to=mathias.nyman@intel.com \
    --cc=linux-sh@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.