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

[George Cherian <george.cherian@ti.com>]

On 5/14/2014 12:07 AM, Bin Liu wrote:
> Hi,
>
> On Tue, May 13, 2014 at 8:24 AM, George Cherian <george.cherian@ti.com> 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.
> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
-George