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
