MUSB dual-role on AM335x behaving weirdly

[gregory.clement@free-electrons.com (Gregory CLEMENT)]

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@free-electrons.com> 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@free-electrons.com> 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