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

[George Cherian]

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@xxxxxxxxx> wrote:
> > 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?
> 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
> 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@xxxxxxxxxxxxxxx
> > > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> > >
> > > --
> > > -George


--
-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/