[1/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset

[1/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset

[Ran Wang]

When DWC3 is set to host mode by programming register DWC3_GCTL, VUBS
(or its control signal) will on immediately on related Root Hub ports.
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.
 
  - in addition all properties from usb-xhci.txt from the current directory are
    supported as well

[1/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset

[Ran Wang]

Hi,

On 16, 2019 14:48 Ran Wang wrote:
>

It seems the preface patch (0/2) failed to be accepted by patchwork (could
anyone tell me how to generate it properly with some sommand?), 
I paste its content here for your reference :

This to fix USB enumeration compatibility issue found on DWC3 (host mode)
IP only.

Some pre-discussion mails can be referred from:
https://lkml.org/lkml/2018/11/23/387
https://lkml.org/lkml/2018/11/22/683

As to the workaround, I know programming xhci register in DWC3 dirver
(probe function) is not good from perspective of SW stack, but it seems
to be the only place to fix this real existing problem (test result show
that doing this in xhci-plat.c or xhci.c would not hlep on this kind of
failure). If who have better idea, please let me know, thanks in advanced.

Ran Wang (2):
 dt-bindings: Add workaround for host mode VBUS glitch when boot
 dwc3 core driver: Add avoiding vbus glitch happen during xhci reset

 Documentation/devicetree/bindings/usb/dwc3.txt |    3 +++
 drivers/usb/dwc3/core.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/usb/dwc3/core.h |   10 +++++++++-
 3 files changed, 60 insertions(+), 0 deletions(-)
 
> When DWC3 is set to host mode by programming register DWC3_GCTL, VUBS
> (or its control signal) will on immediately on related Root Hub ports.
> 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.
> 
>   - in addition all properties from usb-xhci.txt from the current directory are
>     supported as well
> --
> 1.7.1

Regards,
Ran

[1/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset

[Rob Herring]

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

[1/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset

[Ran Wang]

Hi Rob,

On January 22, 2019 09:03, Rob Herring wrote:
> 
> 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/

Yes, will fix it in next version.
 
> > (or its control signal) will on immediately on related Root Hub ports.
> 
> /will on/will turn on/

Got it. Thanks.

> > 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.

Sorry, not quite get your point here? Actually I have discussed with Soc design guys
and Felipe, it seems to be DWC3 native behavior rather than SoC specific issue.
https://lkml.org/lkml/2018/11/23/387
https://lkml.org/lkml/2018/12/12/140

I think there could be 2 reasons why we got no report for a long time till now:
1. Most USB devices are not so sensitive to this VBUS glitch, they would works fine.
2. A proper VBUS pump circuit design can successfully filter this glitch out. I have
confirmed this with scope, which means some platforms might resolve issue in
this way already (some might not, of cause).

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

From the logic level, I don't see a harm to DWC3 hosts if unconditionally apply this.
However, since this is not a only solution (can fix it in HW way), I prefer to let it
controlled by property in DTS node for those questionable board already existing
in market. 

Regards,
Ran

[1/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset

[Rob Herring]

On Mon, Jan 21, 2019 at 8:38 PM Ran Wang <ran.wang_1@nxp.com> wrote:
>
> Hi Rob,
>
> On January 22, 2019 09:03, Rob Herring wrote:
> >
> > 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/
>
> Yes, will fix it in next version.
>
> > > (or its control signal) will on immediately on related Root Hub ports.
> >
> > /will on/will turn on/
>
> Got it. Thanks.
>
> > > 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.
>
> Sorry, not quite get your point here? Actually I have discussed with Soc design guys
> and Felipe, it seems to be DWC3 native behavior rather than SoC specific issue.
> https://lkml.org/lkml/2018/11/23/387
> https://lkml.org/lkml/2018/12/12/140
>
> I think there could be 2 reasons why we got no report for a long time till now:
> 1. Most USB devices are not so sensitive to this VBUS glitch, they would works fine.
> 2. A proper VBUS pump circuit design can successfully filter this glitch out. I have
> confirmed this with scope, which means some platforms might resolve issue in
> this way already (some might not, of cause).
>
> > Does this even need to be conditional? What would be the harm in doing
> > this unconditionally for all DWC3 hosts?
>
> From the logic level, I don't see a harm to DWC3 hosts if unconditionally apply this.
> However, since this is not a only solution (can fix it in HW way), I prefer to let it
> controlled by property in DTS node for those questionable board already existing
> in market.

Okay, sounds fine.

I would shorten the name a bit: snps,host-vbus-glitches

Rob