On Tue, Oct 25, 2016 at 02:07:09PM +0300, Felipe Balbi wrote: > > Hi, > > Bin Liu <b-liu@xxxxxx> writes: > > On Mon, Oct 24, 2016 at 12:35:11PM +0300, Felipe Balbi wrote: > >> > >> Hi, > >> > >> Bin Liu <b-liu@xxxxxx> writes: > >> > Hi, > >> > > >> > I run into a link state problem when dwc3 is in supper-speed device > >> > mode. > >> > > >> > Modprobe g_zero, link state is U3 (checked in DSTS). > >> > > >> > After dwc3 is enumerated by the host, the trace on the bus is as: > >> > > >> > [both Device and Host are in U0 now] > >> > D->H: LGO_U1 > >> > H->D: LAU > >> > D->H: LPMA > >> > > >> > but actually dwc3 goes to U2. Is this expected? > >> > >> That's host putting the bus to U2 due to inactivity. No problems there. > >> > >> > Now remove the cable from the host, but dwc3 does not generate any > >> > change, link state is still in U2, no any ftrace log either from the > >> > point when removing the cable. > >> > >> Are you missing a disconnect interrupt? Which revision of dwc3 are you > > > > Yes, no disconnect interrupt in the first detach. > > yeah, that confuses dwc3 quite a bit :-) This controller won't do > anything if it doesn't know about voltage levels. > > >> dealing with? Which SoC is this? Do you have that TI mailbox to generate > > > > This is TI AM57x on DRA7-EVM. dwc3 version is 2.02a. > > Why aren't you using the UTMI mailbox? There's even a driver written for > it already. Yes, the driver is there. Right now mailbox is only used for ID pin. But the board does not register extcon for VBUS detect, so the mailbox is not used for VBUS events. > > >> UTMI messages about VBUS levels? Are you programming that correctly to > >> tell dwc3 VBUS is not valid anymore? > > > > There is no VBUS detection on this device and board. Is the VBUS > > detection needed for dwc3 to work in device mode? > > In the case of DRA7x, you don't *really* need detection. All you need to > do is correctly update UTMI mailbox. But the UTMI mailbox is driven by extcon events, right? The board doesn't have external circuit or gpio to detect VBUS. > > > The problem only happens in supper-speed, not high-speed mode. > > Now idea what to make of this, really. It's not a matter of speed, it's > a matter of how UTMI behaves. Yeah, this confuses me too. I could modify the board to add a GPIO to detect VBUS so that I can use the UTMI mailbox. But I wanted to really know the problem before fixing it... HS works without using the mailbox, but SS doesn't... > > >> > Now connect the cable again, dwc3 goes to SS.Inactive, shown in ftrace. > >> > Of cause the host does not detect the attach at this point. > > > > Here when attach again, SS.Inactive happens, which should happen during > > the first detach, which seems telling VBUS detect is not required for > > disconnect interrupt. > > It _is_ required. This SS.Inactive is probably due to some timeout > somewhere. Or the fact that we reset the device's address. If you don't > see an event for "Disconnect" on tracepoints, then you don't have a > disconnect interrupt. Ok. > > >> > Then remove the cable, dwc3 changes as follows in ftrace: > >> > > >> > RX.Detect > >> > U0 > >> > U0 > >> > RX.Detect > >> > U3 > >> > > >> > Basically the host does not enumerate dwc3 in every another attach. > >> > > >> > Any comments about this problem? BTY, I checked with kernel v4.9-rc1, > >> > v4.8, v4.4, v3.14 if it matters... > >> > >> Sounds like a problem outside dwc3. Which SoC and which dwc3 revision? > > > > Inside dwc3, what makes dwc3 to generate the disconnect evt? rx/tx > > remote termination or vbus disconnect? > > VBUS valid being sent over UTMI, hence TI's UTMI mailbox ;-) Ok, I will modify the board to use the mailbox. Thanks, -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
