Message-ID: <CADYTM3YU_oXq64xWuR+3Tah_52cJsU0AMRK4oZDJWp6NZqmkpg@mail.gmail.com>
Date:	Mon, 19 May 2014 08:53:10 -0500
From:	Bin Liu <binmlist@...il.com>
To:	George Cherian <george.cherian@...com>
Cc:	Daniel Mack <zonque@...il.com>, linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-omap@...r.kernel.org,
	balbi@...com, gregkh@...uxfoundation.org, "Liu, Bin" <b-liu@...com>
Subject: Re: [PATCH v3 0/5] Add support for SW babble Control

Hi George,

On Mon, May 19, 2014 at 3:40 AM, George Cherian <george.cherian@...com> wrote:
> Hi Bin,
>
>
> On 5/15/2014 8:49 PM, Bin Liu wrote:
>>
>> George,
>>
>> On Thu, May 15, 2014 at 1:28 AM, George Cherian <george.cherian@...com>
>> wrote:
>>>
>>> Hi Bin,
>>>
>>>
>>> On 5/14/2014 10:13 PM, Bin Liu wrote:
>>>>
>>>> George,
>>>>
>>>> On Wed, May 14, 2014 at 9:34 AM, Bin Liu <binmlist@...il.com> wrote:
>>>>>
>>>>> George,
>>>>>
>>>>> On Wed, May 14, 2014 at 12:37 AM, George Cherian
>>>>> <george.cherian@...com>
>>>>> 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@...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.
>>>>>
>>>>> Sure, but could you please re-send those patches to my corporate email
>>>>> so that I can apply them from Thunderbird?
>>>>
>>>> You don't have to resend the patches. Nishanth Menon showed me a way
>>>> to extract the patch from Gmail - Thanks Nishanth.
>>>>
>>>> But which repo do you want to me test with? The first patch ([PATCH v2
>>>> 1/5] usb: musb: core: Convert babble recover work to delayed work)
>>>> does not apply to v3.15-rc4 tag. the current musb_core.c does not have
>>>> the recovery work for musb. Please let me know what I missed.
>>>
>>> Oops I missed to mention the same.
>>> Please try on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
>>
>> The test is done. The babble always causes STUCK_J is reset,
>> MUSB_BABBLE_CTL is 0x44 or 0x4. MUSB reset happens.
>
> Thankyou Bin for the help.
>
> Can I get a Tested-by from you?

Yes, sure.

>
>> Do you think when re-start happens the driver should print a message
>> on console saying re-start due to babble? It would help debug the
>> babble problems while the dynamic debug is off.
>
>
> It prints  out a message saying babble condition occured.

That is good, but I think we also want to know the babble type - the
controller is reset or not.

> More over, it re-enumerates all the devices connected  as part of Musb
> re-start.

Sometimes the custom board has hw or sw issue, for example USB
basically does not functional, maybe after babble there is no
re-enumeration, then we cannot tell if controller reset happened or
not from the log. I think a specific message telling that will
helpful.

Regards,
-Bin.

> Don't you think that is sufficient enough ?
>
>> Thanks,
>> -Bin.
>>
>>>> Thanks,
>>>> -Bin.
>>>>
>>>>> 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@...r.kernel.org
>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -George
>>>>>>
>>>
>>> --
>>> -George
>>>
>
>
> --
> -George
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists