Message-ID: <AM5PR0402MB2865F6C77B7338F3959FECB4F1D40@AM5PR0402MB2865.eurprd04.prod.outlook.com>
Date:   Fri, 23 Nov 2018 07:31:16 +0000
From:   Ran Wang <ran.wang_1@....com>
To:     Felipe Balbi <balbi@...nel.org>
CC:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: RESEND: About VBUS glitch happen on DWC3 host mode enabling
 process.

Hello Felipe,

Felipe Balbi <balbi@...nel.org> wrote:
> Hi,
> 
> Ran Wang <ran.wang_1@....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

Powered by blists - more mailing lists