Hi, Bin Liu <b-liu@xxxxxx> writes: >> >> >> > 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. >> >> Seems like dwc3-omap doesn't like ID-only boards. I remember that used >> to work just fine. Maybe track down the regression? > > Do you mean this DRA7-EVM used to work? This is the only AM57x board I can > find which has SS device port. :-( yeah, it used to work. >> >> >> 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. >> >> Then you should use ID event to *also* fiddle with VBUSVALID bit. That >> used to work just fine, I guess commit below broke it: >> >> commit d2728fb3e01f9265571a5f7a5feeac4493d2a365 >> Author: Roger Quadros <rogerq@xxxxxx> >> Date: Wed May 11 17:36:45 2016 +0300 >> >> usb: dwc3: omap: Pass VBUS and ID events transparently >> >> Don't make any decisions regarding VBUS session based on ID >> status. That is best left to the OTG core. >> >> Pass ID and VBUS events independent of each other so that OTG >> core knows exactly what to do. >> >> This makes dual-role with extcon work with OTG irq on OMAP platforms. >> >> Signed-off-by: Roger Quadros <rogerq@xxxxxx> >> Signed-off-by: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> >> > > Just reviewed this patch, it seems to be the regression. But SS should > not generate ID pin event either, right? SS uses far-end termination, it > does not have ID pin as USB2.0. I will try to revert this patch to find > out... it's not about speed :-) ID pin is used nevertheless to choose role, but some TI boards didn't provide any methods for VBUS sampling, so ID pin was used to tell DWC3 if it should be host/device AND if VBUS_VALID or not. Note that we end up lying to the controller because we could set VBUS_VALID before VBUS really is valid, but it's better than never seeing a connection at all ;-) -- balbi
Attachment:
signature.asc
Description: PGP signature
