Message-ID: <87tvk8yysc.fsf@linux.intel.com>
Date:   Fri, 23 Nov 2018 10:37:55 +0200
From:   Felipe Balbi <balbi@...nel.org>
To:     Ran Wang <ran.wang_1@....com>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>
Cc:     "gregkh\@linuxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb\@vger.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: RESEND: About VBUS glitch happen on DWC3 host mode enabling process.


Hi Ran,

Ran Wang <ran.wang_1@....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

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)

Powered by blists - more mailing lists