Re: [PATCH v3 0/5] Add support for SW babble Control

[Bin Liu]

George,

On Wed, May 14, 2014 at 12:37 AM, George Cherian <george.cherian@xxxxxx> wrote:
> On 5/14/2014 12:07 AM, Bin Liu wrote:
>>
>> Hi,
>>
>> On Tue, May 13, 2014 at 8:24 AM, George Cherian <george.cherian@xxxxxx>
>> wrote:
>>>
>>> Hi Daniel,
>>>
>>>
>>> On 5/13/2014 6:44 PM, Daniel Mack wrote:
>>>>
>>>> Hi George,
>>>>
>>>> On 05/13/2014 02:57 PM, George Cherian wrote:
>>>>>
>>>>> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
>>>>> reg.
>>>>> can you try with the following patch.
>>>>>
>>>>> diff --git a/drivers/usb/musb/musb_dsps.c
>>>>> b/drivers/usb/musb/musb_dsps.c
>>>>> index 1ae6681..1160cd1 100644
>>>>> --- a/drivers/usb/musb/musb_dsps.c
>>>>> +++ b/drivers/usb/musb/musb_dsps.c
>>>>> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>>>>>           * logic enabled.
>>>>>           */
>>>>>          val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
>>>>> -       if (val == MUSB_BABBLE_RCV_DISABLE)
>>>>> +       if (val == MUSB_BABBLE_RCV_DISABLE) {
>>>>>                  glue->sw_babble_enabled = true;
>>>>> +               val |= MUSB_BABBLE_SW_SESSION_CTRL;
>>>>> +               dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
>>>>> +       }
>>>>>          ret = dsps_musb_dbg_init(musb, glue);
>>>>>          if (ret)
>>>>
>>>> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
>>>> without the patch: a full glue reset is conducted. Do I get you right
>>>> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
>>>> MUSB_BABBLE_SW_SESSION_CTRL is set?
>>>>
>>> Basically, there are 2 types of babble conditions.
>>> 1) Transient babble condition - which could be recovered from without an
>>> IP
>>> reset .
>>> 2) Babble condition - which could be recovered from only by doing an IP
>>> reset.
>>>
>>> Looks like you are always hitting case 2 (Most times am also hitting the
>>> same).
>>> Case 1 is really hard to reproduce. I don't have a reliable method as of
>>> now
>>> to
>>> reproduce this case consistently.
>>>
>>>> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
>>>> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
>>>> (a_wait_bcon)
>>>> [   19.685815] usb 1-1: USB disconnect, device number 3
>>>> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
>>>> 44
>>>> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>>>>
>>>>
>>>> I don't quite follow, especially as I lack documentation of the IP core.
>>>> How do you test babble errors, is there any way to force them to happen
>>>> reliably?
>>>
>>>
>>> There is no 100% reliable method to force it to happen. Following is
>>
>> I have a way to force babble happen reliably - shorting DP or DM to
>> VBUS. I opened the far-end plug of the USB cable, so I can easily
>> short DP or DM to VBUS.
>
> Good to know that you have a reliable way to test babble condition.
> Can you please do a quick test on 3.15.0-rc4 with the series applied?
> In case of any assistance please do let me know.

Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?

I read these linux-usb emails in Gmail, and  am not aware of any easy
way to extract patches from Gmail.

BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.

Thanks,
-Bin.

>
>> But the interesting thing is that with TI 3.2 kernel, shorting DP or
>> DM to VBUS causes MISC register to be 0x4, but the result is
>> completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
>>
>> So in the 3.2 kernel, the babble handing resets the controller, but
>> the 3.12.10 does not.
>>
>> Regards,
>> -Bin.
>>
>>> my setup ,
>>> I have a HUB with 4 devices connected , which gives me a Babble interrupt
>>> on both connects and disconnects ( Not always though).
>>>
>>>> Anyway, the full glue layer solves this rare condition quite well for
>>>> me. Is there any downside of this?
>>>>
>>>>
>>>> Daniel
>>>>
>>>
>>> --
>>> -George
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> -George
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/