On Wed, Oct 26, 2016 at 10:20:11AM +0300, Roger Quadros wrote: > Hi, > > On 25/10/16 23:55, Bin Liu wrote: > > Felipe, > > > > On Tue, Oct 25, 2016 at 08:57:26AM -0500, Bin Liu wrote: > >> On Tue, Oct 25, 2016 at 04:44:13PM +0300, Felipe Balbi wrote: > >> > >> [snip] > >> > >>>> 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 > >> > >> Yeah, you are right. I messed it up with type-C, somehow thought ID pin > >> is not required for SS :-( > >> > >>> 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 ;-) > >> > >> Make more sense now :-) I will play with the patch mentioned, and ensure > >> any future boards have vbus sampling so we can decouple it with ID pin > >> events in the UTMI mailbox. > >> > >> Still need to figure out why highspeed is not affected... > > > > Ok, I think I understand most part of the problems now. > > > > VBUS detect is required for disconnect event, so AM57x board design > > should have a GPIO for VBUS detect to feed to extcon. > > > > 1. why only SS is affected on dra7-evm? > > > > This is because of USB3.0 LPM. With g_zero, dwc3 SS in device mode goes > > to U2 after been enumerated, in which state dwc3 is unable to detect any > > change other than link change. But dwc3 HS stays in U0 after been > > enumerated, so the link goes to RX.Detect after detach from the host. So > > dwc3 HS can still detect the connect to host even with lack of > > disconnect interrupt. > > > > 2. why dra7-evm used to work? > > > > Very likely the kernel at that time does not support LPM, so > > dwc3 SS is still in U0 after been enumerated, the same case as in HS > > above. At least this is what I see with kernel 3.14, in which dwc3 SS > > doesn't go to U2. > > So does this mean that it still won't work with the suspected patch > removed? As there is no way of telling about VBUS status on dra7-evm. I didn't revert the suspected patch, as I don't think it will make it work. microB cable doesn't ground ID pin, so detaching the cable won't trigger the UTMI mailbox at all, the patch is not in the path. I verified the mailbox notifier is not called when remove the cable. > > How can we workaround this on that evm? is disabling LPM on dra7-evm possible? I don't think there is any workaround, other than a board change. I tried to disable LPM, and it did solve the issue, but it generates new problem - USB3 LPM compliance. Regards, -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
