RESEND: About VBUS glitch happen on DWC3 host mode enabling process.

RESEND: About VBUS glitch happen on DWC3 host mode enabling process.

[Ran Wang]

Resend this mail in plain text.

Hello Felipe,
　We’ve found on some Layerscape platforms which integrating DWC3 USB3.0 DRD controller, VBUS glitch happened and caused some USB drives enumeration fail, like to discuss the details as below.
　
　Story is that, we found once function dwc3_core_init_mode() got called and enabled host mode by calling dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST) which would write register [DWC3_GCTL] bit 12~13, so the pin (such as USB_DRVVBUS) which control VBUS driving chip’s EN pin would be pulled high immediately, so did the VBUS (up to +5V). Then, DWC3 core driver continued to call function dwc3_host_init()->platform_device_add(xhci)… xhci_plat_probe()->usb_add_hcd()->xhci_plat_setup()->xhci_gen_setup-> xhci_reset(), which would reset xHCI controller. At this point, the VBUS EN pin (USB_DRVVBUS) was pulled low for about 15us, causing the VBUS did the same drop too, then back to normal voltage when HW reset complete. We have confirmed this whole process according to scope waveform with test code on DWC3 driver. Impact is that VBUS glitch has let some USB drives (such as Transcend 4GB USB2.0 (jetflash) and Kingston 16GB USB2.0 DTGE9) malfunction during enumeration (particularly happen when drive is connected to root-hub port prior to Linux boot).
　
　Per my understanding, VBUS need to keep +5V once enabled without any drop/unstable. And above glitch looks like caused by the gap between DWC3 design and driver init procedure. 
　
　One of probably workaround come to my mind is to program all root-hub ports’ PORTSC[PP] to 0b immediately after enabling host mode (calling dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST)), so VBUS will keep 0V till xhci is reset by xhci driver like above. I have test this and it works.
　
　I know it is not an good fix because DWC3 core driver would touch xHCI controller which ought to be handled by xHCI driver instead, so like to send out this mail for discussion first, see if anyone has better solution on this issue.
　Thanks for your time.

Regards,
Ran

Re: RESEND: About VBUS glitch happen on DWC3 host mode enabling process.

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3401 bytes --]


Hi,

Ran Wang <ran.wang_1@nxp.com> writes:
> Hello Felipe,
>
> We’ve found on some Layerscape platforms which integrating DWC3

which platform is that? Is it supported upstream? Which kernel version
are you using?

> USB3.0 DRD controller, VBUS glitch happened and caused some USB drives

what do you mean by glitch?

> enumeration fail, like to discuss the details as below.
> 　
> Story is that, we found once function dwc3_core_init_mode() got called
> and enabled host mode by calling dwc3_set_prtcap(dwc,
> DWC3_GCTL_PRTCAP_HOST) which would write register [DWC3_GCTL] bit
> 12~13, so the pin (such as USB_DRVVBUS) which control VBUS driving
> chip’s EN pin would be pulled high immediately, so did the VBUS (up to
> +5V).

this seems specific to your platform. Please clarify a little more? Do
you have a discrete charge pump tied to some output signal from dwc3?

> Then, DWC3 core driver continued to call function
> dwc3_host_init()->platform_device_add(xhci)…
> xhci_plat_probe()->usb_add_hcd()->xhci_plat_setup()->xhci_gen_setup->
> xhci_reset(), which would reset xHCI controller. At this point, the
> VBUS EN pin (USB_DRVVBUS) was pulled low for about 15us, causing the

why is that pin pulled low? XHCI reset shouldn't be a global reset. Did
your HW engineer tie all reset lines together? If so, there's nothing I
can do to help.

> VBUS did the same drop too, then back to normal voltage when HW reset
> complete. We have confirmed this whole process according to scope
> waveform with test code on DWC3 driver. Impact is that VBUS glitch has
> let some USB drives (such as Transcend 4GB USB2.0 (jetflash) and
> Kingston 16GB USB2.0 DTGE9) malfunction during enumeration
> (particularly happen when drive is connected to root-hub port prior to
> Linux boot).

okay

> Per my understanding, VBUS need to keep +5V once enabled without any
> drop/unstable. And above glitch looks like caused by the gap between
> DWC3 design and driver init procedure.

why are you blaming the driver here? We don't know of any such platform
that has problems with this. Do you mean to say that because your HW
engineer made a choice of tying host reset to global reset, you end up
having an issue? That's something else entirely that SW can't help you
with.

I have no idea about anything nxp has done, no access to documentation,
nothing at all. I need you to do a better job at explaining the
situation starting with kernel version you're using, if platform is
supported upstream, etc.



> One of probably workaround come to my mind is to program all root-hub
> ports’ PORTSC[PP] to 0b immediately after enabling host mode (calling
> dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST)), so VBUS will keep 0V
> till xhci is reset by xhci driver like above. I have test this and it
> works.

dwc3 will _not_ touch xHCI registers, sorry. If you need something like
that, you need to do it as a quirk in xhci-plat.c

> I know it is not an good fix because DWC3 core driver would touch xHCI
> controller which ought to be handled by xHCI driver instead, so like
> to send out this mail for discussion first, see if anyone has better
> solution on this issue.

please answer my other questions first, after we fully understand the
scenario and the problem, then we can discuss implementation details.

cheers

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

RE: RESEND: About VBUS glitch happen on DWC3 host mode enabling process.

[Ran Wang]

Hello Felipe,

Felipe Balbi <balbi@kernel.org> wrote:
> Hi,
> 
> Ran Wang <ran.wang_1@nxp.com> writes:
> > Hello Felipe,
> >
> > We’ve found on some Layerscape platforms which integrating DWC3
> 
> which platform is that? Is it supported upstream? Which kernel version are
> you using?

We reproduced this issue on board LS1043ARDB with latest upstream code 
(git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git, HEAD: 651022382c7("Linux 4.20-rc1")).

> > USB3.0 DRD controller, VBUS glitch happened and caused some USB drives
> 
> what do you mean by glitch?

Please see below simple diagram:
                       Here DWC3 enable host mode, VBUS on
+5V                   /--------------------\   /---------------------------....
0V  ________/                              \/
                                                         Here do xhci reset, VBUS drop for 15us, then back to +5V again

> > enumeration fail, like to discuss the details as below.
> >
> > Story is that, we found once function dwc3_core_init_mode() got called
> > and enabled host mode by calling dwc3_set_prtcap(dwc,
> > DWC3_GCTL_PRTCAP_HOST) which would write register [DWC3_GCTL] bit
> > 12~13, so the pin (such as USB_DRVVBUS) which control VBUS driving
> > chip’s EN pin would be pulled high immediately, so did the VBUS (up to
> > +5V).
> 
> this seems specific to your platform. Please clarify a little more? Do you have
> a discrete charge pump tied to some output signal from dwc3?

Actually we have observed other Layerscape platforms (such as LS1012AFRWY,
LS1088ARDB-PB) have the same issue. They all integrate DWC3 IP as a USB3.0
controller (please see arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi as example,
search 'snps,dwc3'). About the discrete charge pump, we do have some for VBUS side,
but seems no help on this.

As to the more information of LS1043ARDB bard, please download it from https://www.nxp.com/webapp/Download?colCode=LS1043ARDBRM&Parent_nodeId=1441121579998719223109&Parent_pageType=product&Parent_nodeId=1441121579998719223109&Parent_pageType=product&Parent_nodeId=1441121579998719223109&Parent_pageType=product  . 

In a simple word, the USB VBUS related part look like below(datasheet of VBUS
switch chip NX5P3090 can be downloaded at https://www.nxp.com/docs/en/data-sheet/NX5P3090.pdf):
SoC LS1043A pin USB_DRVVBUS ---> discrete VBUS switch chip NX5P3090 pin EN, chip NX5P3090 pin VBUS ---> USB physical connector pin VBUS (with some discrete charge pump connected)

> > Then, DWC3 core driver continued to call function
> > dwc3_host_init()->platform_device_add(xhci)…
> > xhci_plat_probe()->usb_add_hcd()->xhci_plat_setup()->xhci_gen_setup->
> > xhci_reset(), which would reset xHCI controller. At this point, the
> > VBUS EN pin (USB_DRVVBUS) was pulled low for about 15us, causing the
> 
> why is that pin pulled low? XHCI reset shouldn't be a global reset. Did your
> HW engineer tie all reset lines together? If so, there's nothing I can do to
> help.

That's the point I also want to make clear: do you mean that the VBUS control
signal come from DWC3 IP should not be pulled down when xHCI controller
conduct reset? 
And sorry that I am not quite sure about the 'global reset' you mentioned. Do
you mean to a DWC3 global reset or SoC reset? 

My understanding is that since VBUS control signal only be meaningful in USB
host mode (xHCI), so it might be in the scope/control of xHCI controller, meaning
that xHCI reset trigger VBUS/USB_DRVVBUS(EN) pulled low might make sense,
am I right? And the information come from DWC3 IP design has confirmed that
PORTSC[PP] will be de-asserted during HCRST, it seems this is native behavior on
DWC3 IP.

> > VBUS did the same drop too, then back to normal voltage when HW reset
> > complete. We have confirmed this whole process according to scope
> > waveform with test code on DWC3 driver. Impact is that VBUS glitch has
> > let some USB drives (such as Transcend 4GB USB2.0 (jetflash) and
> > Kingston 16GB USB2.0 DTGE9) malfunction during enumeration
> > (particularly happen when drive is connected to root-hub port prior to
> > Linux boot).
> 
> okay
> 
> > Per my understanding, VBUS need to keep +5V once enabled without any
> > drop/unstable. And above glitch looks like caused by the gap between
> > DWC3 design and driver init procedure.
> 
> why are you blaming the driver here? We don't know of any such platform
> that has problems with this. Do you mean to say that because your HW
> engineer made a choice of tying host reset to global reset, you end up having
> an issue? That's something else entirely that SW can't help you with.

I didn't mean to blame driver alone, just found the time interval between host
mode enabling and host reset causing a observable VBUS control signal glitch
happen we didn't expected. And experiments proved that VBUS on between host
mode enabling and host reset might not be necessary and can avoid this potential risk.

> I have no idea about anything nxp has done, no access to documentation,
> nothing at all. I need you to do a better job at explaining the situation
> starting with kernel version you're using, if platform is supported upstream,
> etc.

Please see my above answer. 
These Layerscape platforms are support upstream, I can run them with pure upstream
build directly.

> 
> > One of probably workaround come to my mind is to program all root-hub
> > ports’ PORTSC[PP] to 0b immediately after enabling host mode (calling
> > dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST)), so VBUS will keep 0V
> > till xhci is reset by xhci driver like above. I have test this and it
> > works.
> 
> dwc3 will _not_ touch xHCI registers, sorry. If you need something like that,
> you need to do it as a quirk in xhci-plat.c

Thanks for pointing out a direction for me. If we do it as a quirk in xhci-plat.c, how
can we control it by some kind of DTS property in board level config?
 
> > I know it is not an good fix because DWC3 core driver would touch xHCI
> > controller which ought to be handled by xHCI driver instead, so like
> > to send out this mail for discussion first, see if anyone has better
> > solution on this issue.
> 
> please answer my other questions first, after we fully understand the
> scenario and the problem, then we can discuss implementation details.

Agree, I will try to provide the information you require, thank you for the help.

Regards,
Ran

> cheers
> 
> --
> balbi

RE: RESEND: About VBUS glitch happen on DWC3 host mode enabling process.

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 4229 bytes --]


Hi Ran,

Ran Wang <ran.wang_1@nxp.com> writes:
>> > Then, DWC3 core driver continued to call function
>> > dwc3_host_init()->platform_device_add(xhci)…
>> > xhci_plat_probe()->usb_add_hcd()->xhci_plat_setup()->xhci_gen_setup->
>> > xhci_reset(), which would reset xHCI controller. At this point, the
>> > VBUS EN pin (USB_DRVVBUS) was pulled low for about 15us, causing the
>> 
>> why is that pin pulled low? XHCI reset shouldn't be a global reset. Did your
>> HW engineer tie all reset lines together? If so, there's nothing I can do to
>> help.
>
> That's the point I also want to make clear: do you mean that the VBUS control
> signal come from DWC3 IP should not be pulled down when xHCI controller
> conduct reset? 
> And sorry that I am not quite sure about the 'global reset' you mentioned. Do
> you mean to a DWC3 global reset or SoC reset? 
>
> My understanding is that since VBUS control signal only be meaningful in USB
> host mode (xHCI), so it might be in the scope/control of xHCI controller, meaning
> that xHCI reset trigger VBUS/USB_DRVVBUS(EN) pulled low might make sense,
> am I right? And the information come from DWC3 IP design has confirmed that
> PORTSC[PP] will be de-asserted during HCRST, it seems this is native behavior on
> DWC3 IP.

okay, so the thing is about PP being dropped. Right, that should happen
indeed. However, this still shouldn't cause any problems, since
peripheral side shouldn't connect its pull-ups until VBUS is above
session valid threshold.

For how long is VBUS dropped in this case?

>> > VBUS did the same drop too, then back to normal voltage when HW reset
>> > complete. We have confirmed this whole process according to scope
>> > waveform with test code on DWC3 driver. Impact is that VBUS glitch has
>> > let some USB drives (such as Transcend 4GB USB2.0 (jetflash) and
>> > Kingston 16GB USB2.0 DTGE9) malfunction during enumeration
>> > (particularly happen when drive is connected to root-hub port prior to
>> > Linux boot).
>> 
>> okay
>> 
>> > Per my understanding, VBUS need to keep +5V once enabled without any
>> > drop/unstable. And above glitch looks like caused by the gap between
>> > DWC3 design and driver init procedure.
>> 
>> why are you blaming the driver here? We don't know of any such platform
>> that has problems with this. Do you mean to say that because your HW
>> engineer made a choice of tying host reset to global reset, you end up having
>> an issue? That's something else entirely that SW can't help you with.
>
> I didn't mean to blame driver alone, just found the time interval between host
> mode enabling and host reset causing a observable VBUS control signal glitch
> happen we didn't expected. And experiments proved that VBUS on between host
> mode enabling and host reset might not be necessary and can avoid this potential risk.
>
>> I have no idea about anything nxp has done, no access to documentation,
>> nothing at all. I need you to do a better job at explaining the situation
>> starting with kernel version you're using, if platform is supported upstream,
>> etc.
>
> Please see my above answer. 
> These Layerscape platforms are support upstream, I can run them with pure upstream
> build directly.

that's good, then we can debug this. Can you collect xhci tracepoints of
when the problem happens?

>> > One of probably workaround come to my mind is to program all root-hub
>> > ports’ PORTSC[PP] to 0b immediately after enabling host mode (calling
>> > dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST)), so VBUS will keep 0V
>> > till xhci is reset by xhci driver like above. I have test this and it
>> > works.
>> 
>> dwc3 will _not_ touch xHCI registers, sorry. If you need something like that,
>> you need to do it as a quirk in xhci-plat.c
>
> Thanks for pointing out a direction for me. If we do it as a quirk in xhci-plat.c, how
> can we control it by some kind of DTS property in board level config?

If, indeed, there is a quirk here, then a quirk can be passed from dwc3
to xhci-plat, yes.

cheers

ps: Mathias, did you see any behavior like this? A drop in VBUS voltage
causing issues during enumeration?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

RE: RESEND: About VBUS glitch happen on DWC3 host mode enabling process.

[Ran Wang]

[-- Attachment #1: Type: text/plain, Size: 6542 bytes --]

Hello Felipe,

Felipe Balbi <balbi@kernel.org> wrote: 
> 
> Hi Ran,
> 
> Ran Wang <ran.wang_1@nxp.com> writes:
> >> > Then, DWC3 core driver continued to call function
> >> > dwc3_host_init()->platform_device_add(xhci)…
> >> > xhci_plat_probe()->usb_add_hcd()->xhci_plat_setup()->xhci_gen_setup
> >> > -> xhci_reset(), which would reset xHCI controller. At this point,
> >> > the VBUS EN pin (USB_DRVVBUS) was pulled low for about 15us,
> >> > causing the
> >>
> >> why is that pin pulled low? XHCI reset shouldn't be a global reset.
> >> Did your HW engineer tie all reset lines together? If so, there's
> >> nothing I can do to help.
> >
> > That's the point I also want to make clear: do you mean that the VBUS
> > control signal come from DWC3 IP should not be pulled down when xHCI
> > controller conduct reset?
> > And sorry that I am not quite sure about the 'global reset' you
> > mentioned. Do you mean to a DWC3 global reset or SoC reset?
> >
> > My understanding is that since VBUS control signal only be meaningful
> > in USB host mode (xHCI), so it might be in the scope/control of xHCI
> > controller, meaning that xHCI reset trigger VBUS/USB_DRVVBUS(EN)
> > pulled low might make sense, am I right? And the information come from
> > DWC3 IP design has confirmed that PORTSC[PP] will be de-asserted
> > during HCRST, it seems this is native behavior on
> > DWC3 IP.
> 
> okay, so the thing is about PP being dropped. Right, that should happen
> indeed. However, this still shouldn't cause any problems, since peripheral
> side shouldn't connect its pull-ups until VBUS is above session valid
> threshold.
> 
> For how long is VBUS dropped in this case?

The duration of VBUS drop is about 7.5ms (for USB_DRVVBUS is about 22us)
I have to admitted only that 2 brands of USB drives encountered failures, others are
fine, according my test results. Just thinking that this glitch properly trigger those
potential defect of that USB drives on the market which might not totally
follow USB spec, so like to do something in SW side to make host more robust.
> 
> >> > VBUS did the same drop too, then back to normal voltage when HW
> >> > reset complete. We have confirmed this whole process according to
> >> > scope waveform with test code on DWC3 driver. Impact is that VBUS
> >> > glitch has let some USB drives (such as Transcend 4GB USB2.0
> >> > (jetflash) and Kingston 16GB USB2.0 DTGE9) malfunction during
> >> > enumeration (particularly happen when drive is connected to
> >> > root-hub port prior to Linux boot).
> >>
> >> okay
> >>
> >> > Per my understanding, VBUS need to keep +5V once enabled without
> >> > any drop/unstable. And above glitch looks like caused by the gap
> >> > between
> >> > DWC3 design and driver init procedure.
> >>
> >> why are you blaming the driver here? We don't know of any such
> >> platform that has problems with this. Do you mean to say that because
> >> your HW engineer made a choice of tying host reset to global reset,
> >> you end up having an issue? That's something else entirely that SW can't
> help you with.
> >
> > I didn't mean to blame driver alone, just found the time interval
> > between host mode enabling and host reset causing a observable VBUS
> > control signal glitch happen we didn't expected. And experiments
> > proved that VBUS on between host mode enabling and host reset might
> not be necessary and can avoid this potential risk.
> >
> >> I have no idea about anything nxp has done, no access to
> >> documentation, nothing at all. I need you to do a better job at
> >> explaining the situation starting with kernel version you're using,
> >> if platform is supported upstream, etc.
> >
> > Please see my above answer.
> > These Layerscape platforms are support upstream, I can run them with
> > pure upstream build directly.
> 
> that's good, then we can debug this. Can you collect xhci tracepoints of
> when the problem happens?
 
Sorry, did you mean open xhci dynamic printk support for xhci? 

Actually I have debugged this for a while, the enumeration failure is due
to that USB drive reported another USB device descriptor once encounter
VBUS glitch. It's interesting. Look like it suddenly become another USB drive
and finally fail at SCSI protocol communication (TEST UNIT READY feedback),
I attach the snapshot pic of USB trace log to this mail, not sure if you can
receive it.

My judgement on this is that USB drive might has multiple device config
information stored in EPROM and report the wrong one in some corner
case (like encounter VBUS glitch) by accidently. And obviously that chosen
device config is not ready to behave as a Mass Storage/SCSI device. I have
checked these 2 different brand of drives and they both have the same issue
(even the wrong device descriptors are different!), it make me wondering
It's possible that there are any other drives have same issue existing on the market.

> >> > One of probably workaround come to my mind is to program all
> >> > root-hub ports’ PORTSC[PP] to 0b immediately after enabling host
> >> > mode (calling dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST)), so
> VBUS
> >> > will keep 0V till xhci is reset by xhci driver like above. I have
> >> > test this and it works.
> >>
> >> dwc3 will _not_ touch xHCI registers, sorry. If you need something
> >> like that, you need to do it as a quirk in xhci-plat.c
> >
> > Thanks for pointing out a direction for me. If we do it as a quirk in
> > xhci-plat.c, how can we control it by some kind of DTS property in board
> level config?
> 
> If, indeed, there is a quirk here, then a quirk can be passed from dwc3 to
> xhci-plat, yes.

For this I just did a experiment on xhci-plat, it did can fix this issue but the timing
seems too late: make VBUS waveform look like a square wave as below:

                         Here DWC3 enable host mode, VBUS on
+5V                   /---------\    40ms   /---------------------------....
0V  ________/   90ms   \______/
                                           |           Here do xhci reset, VBUS back to +5V again
                                           Here set all PORTSC[PP] to 0
So I am afraid the solution might have to be added in DWC3 core driver
where just after host mode enabling code if want fix this :(

Regards,
Ran
> 
> ps: Mathias, did you see any behavior like this? A drop in VBUS voltage
> causing issues during enumeration?
> 
> --
> balbi

[-- Attachment #2: fail.png --]
[-- Type: image/png, Size: 121545 bytes --]

RE: RESEND: About VBUS glitch happen on DWC3 host mode enabling process.

[Ran Wang]

Hi Felipe & Mathias,
    It seems that my below reply mail failed to be shown on lkml.org.
   So I have to resend it. Like to have your comment/suggestion before I begin the
solution implement work. Thanks

Ran Wang <ran.wang_1@nxp.com> wrote:
> 
> Hello Felipe,
> 
> Felipe Balbi <balbi@kernel.org> wrote:
> >
> > Hi Ran,
> >
> > Ran Wang <ran.wang_1@nxp.com> writes:
> > >> > Then, DWC3 core driver continued to call function
> > >> > dwc3_host_init()->platform_device_add(xhci)…
> > >> > xhci_plat_probe()->usb_add_hcd()->xhci_plat_setup()->xhci_gen_set
> > >> > up
> > >> > -> xhci_reset(), which would reset xHCI controller. At this
> > >> > -> point,
> > >> > the VBUS EN pin (USB_DRVVBUS) was pulled low for about 15us,
> > >> > causing the
> > >>
> > >> why is that pin pulled low? XHCI reset shouldn't be a global reset.
> > >> Did your HW engineer tie all reset lines together? If so, there's
> > >> nothing I can do to help.
> > >
> > > That's the point I also want to make clear: do you mean that the
> > > VBUS control signal come from DWC3 IP should not be pulled down when
> > > xHCI controller conduct reset?
> > > And sorry that I am not quite sure about the 'global reset' you
> > > mentioned. Do you mean to a DWC3 global reset or SoC reset?
> > >
> > > My understanding is that since VBUS control signal only be
> > > meaningful in USB host mode (xHCI), so it might be in the
> > > scope/control of xHCI controller, meaning that xHCI reset trigger
> > > VBUS/USB_DRVVBUS(EN) pulled low might make sense, am I right? And
> > > the information come from
> > > DWC3 IP design has confirmed that PORTSC[PP] will be de-asserted
> > > during HCRST, it seems this is native behavior on
> > > DWC3 IP.
> >
> > okay, so the thing is about PP being dropped. Right, that should
> > happen indeed. However, this still shouldn't cause any problems, since
> > peripheral side shouldn't connect its pull-ups until VBUS is above
> > session valid threshold.
> >
> > For how long is VBUS dropped in this case?
> 
> The duration of VBUS drop is about 7.5ms (for USB_DRVVBUS is about 22us) I
> have to admitted only that 2 brands of USB drives encountered failures,
> others are fine, according my test results. Just thinking that this glitch
> properly trigger those potential defect of that USB drives on the market
> which might not totally follow USB spec, so like to do something in SW side
> to make host more robust.
> >
> > >> > VBUS did the same drop too, then back to normal voltage when HW
> > >> > reset complete. We have confirmed this whole process according to
> > >> > scope waveform with test code on DWC3 driver. Impact is that VBUS
> > >> > glitch has let some USB drives (such as Transcend 4GB USB2.0
> > >> > (jetflash) and Kingston 16GB USB2.0 DTGE9) malfunction during
> > >> > enumeration (particularly happen when drive is connected to
> > >> > root-hub port prior to Linux boot).
> > >>
> > >> okay
> > >>
> > >> > Per my understanding, VBUS need to keep +5V once enabled without
> > >> > any drop/unstable. And above glitch looks like caused by the gap
> > >> > between
> > >> > DWC3 design and driver init procedure.
> > >>
> > >> why are you blaming the driver here? We don't know of any such
> > >> platform that has problems with this. Do you mean to say that
> > >> because your HW engineer made a choice of tying host reset to
> > >> global reset, you end up having an issue? That's something else
> > >> entirely that SW can't
> > help you with.
> > >
> > > I didn't mean to blame driver alone, just found the time interval
> > > between host mode enabling and host reset causing a observable VBUS
> > > control signal glitch happen we didn't expected. And experiments
> > > proved that VBUS on between host mode enabling and host reset might
> > not be necessary and can avoid this potential risk.
> > >
> > >> I have no idea about anything nxp has done, no access to
> > >> documentation, nothing at all. I need you to do a better job at
> > >> explaining the situation starting with kernel version you're using,
> > >> if platform is supported upstream, etc.
> > >
> > > Please see my above answer.
> > > These Layerscape platforms are support upstream, I can run them with
> > > pure upstream build directly.
> >
> > that's good, then we can debug this. Can you collect xhci tracepoints
> > of when the problem happens?
> 
> Sorry, did you mean open xhci dynamic printk support for xhci?
> 
> Actually I have debugged this for a while, the enumeration failure is due to
> that USB drive reported another USB device descriptor once encounter VBUS
> glitch. It's interesting. Look like it suddenly become another USB drive and
> finally fail at SCSI protocol communication (TEST UNIT READY feedback), I
> attach the snapshot pic of USB trace log to this mail, not sure if you can
> receive it.
> 
> My judgement on this is that USB drive might has multiple device config
> information stored in EPROM and report the wrong one in some corner case
> (like encounter VBUS glitch) by accidently. And obviously that chosen device
> config is not ready to behave as a Mass Storage/SCSI device. I have checked
> these 2 different brand of drives and they both have the same issue (even
> the wrong device descriptors are different!), it make me wondering It's
> possible that there are any other drives have same issue existing on the
> market.
> 
> > >> > One of probably workaround come to my mind is to program all
> > >> > root-hub ports’ PORTSC[PP] to 0b immediately after enabling host
> > >> > mode (calling dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST)), so
> > VBUS
> > >> > will keep 0V till xhci is reset by xhci driver like above. I have
> > >> > test this and it works.
> > >>
> > >> dwc3 will _not_ touch xHCI registers, sorry. If you need something
> > >> like that, you need to do it as a quirk in xhci-plat.c
> > >
> > > Thanks for pointing out a direction for me. If we do it as a quirk
> > > in xhci-plat.c, how can we control it by some kind of DTS property
> > > in board
> > level config?
> >
> > If, indeed, there is a quirk here, then a quirk can be passed from
> > dwc3 to xhci-plat, yes.
> 
> For this I just did a experiment on xhci-plat, it did can fix this issue but the
> timing seems too late: make VBUS waveform look like a square wave as
> below:
> 
>                          Here DWC3 enable host mode, VBUS on
> +5V                   /---------\    40ms   /---------------------------....
> 0V  ________/   90ms   \______/
>                                            |           Here do xhci reset, VBUS back to +5V again
>                                            Here set all PORTSC[PP] to 0 So I am afraid the
> solution might have to be added in DWC3 core driver where just after host
> mode enabling code if want fix this :(
> 
> Regards,
> Ran
> >
> > ps: Mathias, did you see any behavior like this? A drop in VBUS
> > voltage causing issues during enumeration?
> >
> > --
> > Balbi

Regards,
Ran

RE: RESEND: About VBUS glitch happen on DWC3 host mode enabling process.

[Ran Wang]

Hello Felipe,

Felipe Balbi <balbi@kernel.org> wrote: 
> 
> Hi Ran,
> 
> Ran Wang <ran.wang_1@nxp.com> writes:
> >> > Then, DWC3 core driver continued to call function 
> >> > dwc3_host_init()->platform_device_add(xhci)…
> >> > xhci_plat_probe()->usb_add_hcd()->xhci_plat_setup()->xhci_gen_set
> >> > up
> >> > -> xhci_reset(), which would reset xHCI controller. At this 
> >> > -> point,
> >> > the VBUS EN pin (USB_DRVVBUS) was pulled low for about 15us, 
> >> > causing the
> >>
> >> why is that pin pulled low? XHCI reset shouldn't be a global reset.
> >> Did your HW engineer tie all reset lines together? If so, there's 
> >> nothing I can do to help.
> >
> > That's the point I also want to make clear: do you mean that the 
> > VBUS control signal come from DWC3 IP should not be pulled down when 
> > xHCI controller conduct reset?
> > And sorry that I am not quite sure about the 'global reset' you 
> > mentioned. Do you mean to a DWC3 global reset or SoC reset?
> >
> > My understanding is that since VBUS control signal only be 
> > meaningful in USB host mode (xHCI), so it might be in the 
> > scope/control of xHCI controller, meaning that xHCI reset trigger 
> > VBUS/USB_DRVVBUS(EN) pulled low might make sense, am I right? And 
> > the information come from
> > DWC3 IP design has confirmed that PORTSC[PP] will be de-asserted 
> > during HCRST, it seems this is native behavior on
> > DWC3 IP.
> 
> okay, so the thing is about PP being dropped. Right, that should 
> happen indeed. However, this still shouldn't cause any problems, since 
> peripheral side shouldn't connect its pull-ups until VBUS is above 
> session valid threshold.
> 
> For how long is VBUS dropped in this case?

The duration of VBUS drop is about 7.5ms (for USB_DRVVBUS is about 22us) I have to admitted only that 2 brands of USB drives encountered failures, others are fine, according my test results. Just thinking that this glitch properly trigger those potential defect of that USB drives on the market which might not totally follow USB spec, so like to do something in SW side to make host more robust.
> 
> >> > VBUS did the same drop too, then back to normal voltage when HW 
> >> > reset complete. We have confirmed this whole process according to 
> >> > scope waveform with test code on DWC3 driver. Impact is that VBUS 
> >> > glitch has let some USB drives (such as Transcend 4GB USB2.0
> >> > (jetflash) and Kingston 16GB USB2.0 DTGE9) malfunction during 
> >> > enumeration (particularly happen when drive is connected to 
> >> > root-hub port prior to Linux boot).
> >>
> >> okay
> >>
> >> > Per my understanding, VBUS need to keep +5V once enabled without 
> >> > any drop/unstable. And above glitch looks like caused by the gap 
> >> > between
> >> > DWC3 design and driver init procedure.
> >>
> >> why are you blaming the driver here? We don't know of any such 
> >> platform that has problems with this. Do you mean to say that 
> >> because your HW engineer made a choice of tying host reset to 
> >> global reset, you end up having an issue? That's something else 
> >> entirely that SW can't
> help you with.
> >
> > I didn't mean to blame driver alone, just found the time interval 
> > between host mode enabling and host reset causing a observable VBUS 
> > control signal glitch happen we didn't expected. And experiments 
> > proved that VBUS on between host mode enabling and host reset might
> not be necessary and can avoid this potential risk.
> >
> >> I have no idea about anything nxp has done, no access to 
> >> documentation, nothing at all. I need you to do a better job at 
> >> explaining the situation starting with kernel version you're using, 
> >> if platform is supported upstream, etc.
> >
> > Please see my above answer.
> > These Layerscape platforms are support upstream, I can run them with 
> > pure upstream build directly.
> 
> that's good, then we can debug this. Can you collect xhci tracepoints 
> of when the problem happens?
 
Sorry, did you mean open xhci dynamic printk support for xhci? 

Actually I have debugged this for a while, the enumeration failure is due to that USB drive reported another USB device descriptor once encounter VBUS glitch. It's interesting. Look like it suddenly become another USB drive and finally fail at SCSI protocol communication (TEST UNIT READY feedback).

My judgement on this is that USB drive might has multiple device config information stored in EPROM and report the wrong one in some corner case (like encounter VBUS glitch) by accidently. And obviously that chosen device config is not ready to behave as a Mass Storage/SCSI device. I have checked these 2 different brand of drives and they both have the same issue (even the wrong device descriptors are different!), it make me wondering It's possible that there are any other drives have same issue existing on the market.

> >> > One of probably workaround come to my mind is to program all 
> >> > root-hub ports’ PORTSC[PP] to 0b immediately after enabling host 
> >> > mode (calling dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST)), so
> VBUS
> >> > will keep 0V till xhci is reset by xhci driver like above. I have 
> >> > test this and it works.
> >>
> >> dwc3 will _not_ touch xHCI registers, sorry. If you need something 
> >> like that, you need to do it as a quirk in xhci-plat.c
> >
> > Thanks for pointing out a direction for me. If we do it as a quirk 
> > in xhci-plat.c, how can we control it by some kind of DTS property 
> > in board
> level config?
> 
> If, indeed, there is a quirk here, then a quirk can be passed from 
> dwc3 to xhci-plat, yes.

For this I just did a experiment on xhci-plat, it did can fix this issue but the timing seems too late: make VBUS waveform look like a square wave as below:

                         Here DWC3 enable host mode, VBUS on
+5V                   /---------\    40ms   /---------------------------....
0V  ________/   90ms   \______/
                                           |           Here do xhci reset, VBUS back to +5V again
                                           Here set all PORTSC[PP] to 0 So I am afraid the solution might have to be added in DWC3 core driver where just after host mode enabling code if want fix this :(

Regards,
Ran
> 
> ps: Mathias, did you see any behavior like this? A drop in VBUS 
> voltage causing issues during enumeration?
> 
> --
> balbi