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