Hi Ran, Ran Wang <ran.wan...@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
signature.asc
Description: PGP signature
