On Wed, Oct 26, 2016 at 04:35:29PM +0300, Felipe Balbi wrote: > > Hi, > > Bin Liu <b-liu@xxxxxx> writes: > > On Wed, Oct 26, 2016 at 04:13:11PM +0300, Felipe Balbi wrote: > >> > >> Hi, > >> > >> Bin Liu <b-liu@xxxxxx> writes: > >> >> >> >> > 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: > >> >> > > >> >> > I don't understand how this dra7-evm worked before. dwc3 is in SS device > >> >> > mode, microB cable does not ground ID pin, so there is ID event when > >> >> > attach/detach dwc3 to the host. I am confused... > >> >> > >> >> Please read about the mailbox in your SoC. Try to figure out how it > >> >> works and what it does. What happens, internally, when you write > >> >> VBUS_VALID and/or IDGND bits. What does that mean to dwc3? When can dwc3 > >> >> connect its data pullups? What information does it need in order to do > >> >> that? Many of these questions will be answered ;-) > >> > > >> > Yes, got the issue figured out, it is missing hardware trigger to the > >> > mailbox. > >> > >> you can verify that by writing to UTMI mailbox with devmem2 ;-) > > > > Yes, I did that. That is how I got the conclusion. > > > > dwc3 only generates disconnect interrupt when the mailbox clears the > > VBUS bits, for both SS and HS. > > Well, the truth is the following: > > DWC3, as with any USB Device controller, needs to know about VBUS level > if it wants to follow the USB spec. The de-facto way of telling UDCs > about VBUS level is UTMI or ULPI. When silicon vendors started > integrating USB2 PHYs in the SoC, VBUS comparators ended up being left > out. I speculate the reason for that is that mixed signal processes are > more complex and/or expensive but, regardless of the reason, VBUS > comparators were left out. > > So then we needed a new way of generating the UTMI message that the USB2 > PHY can't generate. Hence the UTMI mailbox. > > What you see happening here is DWC3 not having the information it needs > to tell SW that VBUS is gone. From DWC3's perspective, VBUS is still > valid. DWC3 can't sample VBUS level by itself, it needs to trust what > comes over UTMI/ULPI. > > hope this clears it out Yes, this is all understood now. Initially I was puzzled by the fact that high-speed seems to work, at least from what it looks like. Then it turned out that is cause of LPM. The issue is clear now. 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
