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

[Felipe Balbi]

Hi,

Ran Wang <ran.wang_1@xxxxxxx> 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: signature.asc
Description: PGP signature