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. > 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. -- balbi
Attachment:
signature.asc
Description: Digital signature
