devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Ran Wang <ran.wang_1@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Felipe Balbi <balbi@kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset
Date: Mon, 21 Jan 2019 19:03:10 -0600	[thread overview]
Message-ID: <20190122010310.GA5165@bogus> (raw)
In-Reply-To: <20190116064820.20007-2-ran.wang_1@nxp.com>

On Wed, Jan 16, 2019 at 06:48:06AM +0000, Ran Wang wrote:
> When DWC3 is set to host mode by programming register DWC3_GCTL, VUBS

s/VUBS/VBUS/

> (or its control signal) will on immediately on related Root Hub ports.

/will on/will turn on/

> Then the VUBS will be de-asserted for a little while during xhci
> reset (conducted by xhci driver) for a little while and back to normal.
> 
> This VBUS glitch might cause some USB devices emuration fail if kernel boot
> with them connected. One SW workaround which can fix this is to program
> all PORTSC[PP] to 0 to turn off VBUS immediately after setting host mode
> in DWC3 driver(per signal measurement result, it will be too late to do
> it in xhci-plat.c or xhci.c).
> 
> Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> ---
>  Documentation/devicetree/bindings/usb/dwc3.txt |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index 8e5265e..dadb530 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -106,6 +106,9 @@ Optional properties:
>  			When just one value, which means INCRX burst mode enabled. When
>  			more than one value, which means undefined length INCR burst type
>  			enabled. The values can be 1, 4, 8, 16, 32, 64, 128 and 256.
> + - snps,avoid-vbus-glitch-when-set-host: Power off all Root Hub ports immediately
> +			after setting host mode to avoid vbus (negative) glitch happen in later
> +			xhci reset. And the vbus will back to 5V automatically when reset done.

Can't you imply this from the compatible string. You should have an SoC 
specific compatible.

Does this even need to be conditional? What would be the harm in doing 
this unconditionally for all DWC3 hosts? 

Rob

  parent reply	other threads:[~2019-01-22  1:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16  6:48 [PATCH 0/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset Ran Wang
2019-01-16  6:48 ` [PATCH 1/2] " Ran Wang
2019-01-16  7:05   ` Ran Wang
2019-01-22  1:03   ` Rob Herring [this message]
2019-01-22  2:38     ` Ran Wang
2019-01-22 13:45       ` Rob Herring
2019-01-16  6:48 ` [PATCH 2/2] usb: dwc3: Add workaround for host mode VBUS glitch when boot Ran Wang
2019-01-16  8:21   ` Felipe Balbi
2019-01-16 13:11   ` kbuild test robot
2019-02-15  8:39     ` Ran Wang

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=20190122010310.GA5165@bogus \
    --to=robh@kernel.org \
    --cc=balbi@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ran.wang_1@nxp.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;
as well as URLs for NNTP newsgroup(s).