On 20/08/2015 18:46, Felipe Balbi wrote: > On Thu, Aug 20, 2015 at 06:35:17PM +0200, Gregory CLEMENT wrote: >> Hi Felipe, >> >> On 18/08/2015 16:13, Felipe Balbi wrote: >>> Hi, >>> >>> On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote: >>>> Hi again Felipe, >>>> >>>> I sent this email again without the capture because it prevented to be delivered >>>> to the mailing lists. >>>> >>>> On 04/08/2015 21:32, Felipe Balbi wrote: >>>>> On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote: >>>>>> Hi again, >>>>>> On 04/08/2015 15:08, Gregory CLEMENT wrote: >>>>>>> Hi Bin, >>>>>>> >>>>>>> On 02/07/2015 19:05, Bin Liu wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT >>>>>>>> <gregory.clement@xxxxxxxxxxxxxxxxxx> wrote: >>>>>>>>> Hi Felipe, >>>>>>>>> >>>>>>>>> On 27/05/2015 11:42, Alexandre Belloni wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : >>>>>>>>>>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: >>>>>>>>>>>> Alexandre, >>>>>>>>>>>> >>>>>>>>>>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni >>>>>>>>>>>> <alexandre.belloni@xxxxxxxxxxxxxxxxxx> wrote: >>>>>>>>>>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : >>>>>>>>>>>>>> I think I found the root cause of the problem: board design issue - I >>>>>>>>>>>>>> bet the custom board has too much cap on VBUS line. It should be < >>>>>>>>>>>>>> 10uF. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> We have a custom board that exhibits the issue but it only has a 100nF >>>>>>>>>>>>> cap on VBUS. >>>>>>>>>>>> >>>>>>>>>>>> Have you measured the VBUS discharging? Is there any way to share your >>>>>>>>>>>> schematics? >>>>>>>>>>> >>>>>>>>>>> Alexandre, any further comments ? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yeah, I have just got more info. >>>>>>>>>> >>>>>>>>>> This is the relevant part of the schematic: >>>>>>>>>> http://free-electrons.com/~alexandre/usb.png >>>>>>>>>> >>>>>>>>>> The total VBUS capacitance is 200nF and the USB0 pins are connected >>>>>>>>>> directly to the AM3358 pins. U1 is actually not fitted. >>>>>>>>>> >>>>>>>>>> We didn't measure VBUS discharging but we observe the OTG pin sensing >>>>>>>>>> stops when plugging an OTG cable without any device. >>>>>>>>> >>>>>>>>> Do you have any news about this topic? >>>>>>>>> >>>>>>>>> >>>>>>>>> Is there something else that we can do to help solving this issue? >>>>>>>> >>>>>>>> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the >>>>>>>> gadget driver configured? It has to be a module not built-in. >>>>>>> >>>>>>> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m >>>>>>> it worked seamless. >>>>>>> >>>>>> >>>>>> Actually it didn't worked. And now sometimes I even received continuously >>>>>> the following message: >>>>>> >>>>>> musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active >>>>> >>>>> this is likely because your VBUS hasn't dropped below 0.8V fast enough. >>>>> >>>>> I could only trigger this message in that situation. Use a scope to poke >>>>> at VBUS and see how long is takes to reach 0.8V, this could all be cause >>>>> by too much capacitance on VBUS line. >>>> >>>> We got some news: >>>> "The capacitance on VBUS due to components is 200nF and the additional parasitic >>>> capacitance will be much smaller than this" >>>> >>>> The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter. >>>> I attached a capture of this. >>>> >>>> What do you think about these values? >>>> >>>> >>>> However, "there appears to be a considerable delay between the removal of a usb >>>> drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able >>>> to measure this time)." >>> >>> yeah, this is really weird. I can't think of anything that would make >>> VBUS discharge slower from a SW point of view. Once you remove the >>> cable, VBUS is physically removed and there's nothing else charging it. >> >> I have more feedback about it: "When I look at it on the oscilloscope >> this isn't a 'slow discharge' like a slowly draining capacitor, it is >> a delay between the removal of a device and the initiation of the >> discharge. The discharge itself is quite fast once it begins, it just >> seems as if the SOC/driver is taking a long time to notice the cable >> is disconnected. At this stage, this isn't actually a problem, just >> odd." >> >> While working on this issue we found that the >> tg_state_a_wait_vrise_timeout case seemed not managed by musb_dsps >> driver. I've just submitted a patch for it: >> https://lkml.org/lkml/2015/8/20/507 > > cool, I'll test it next week. Good finding btw. Thanks, however it seemed already needs to be amended. > >> I made most of my test on a 3.17 kernel and today by using a 4.1 >> kernel with the patch I have submitted I didn't manage to reproduce >> the issue. I saw that since 3.17, there were some patches related to >> the babble interrupts; so maybe it was enough to fix the issue we saw. >> It is still weird because one month ago I also tested with a 4.1 >> kernel and I had issues... >> >> It needs more testing to see if it is really fixed because the issue >> comes only time to time. I will keep you inform about our last tests. > > all right. Seems like we really need to turn some of those states > handling into a reusable (musb-specific) library. There is something in drivers/usb/common/usb-otg-fsm.c. First I thought it was handle until I realized that this file was nit used at all for musb driver. Thanks, Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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
