Felipe,
On Thu, Feb 26, 2015 at 10:31 AM, Felipe Balbi <balbi@xxxxxx> wrote:
> On Thu, Feb 26, 2015 at 10:21:38AM -0600, Bin Liu wrote:
>> Felipe,
>>
>> On Thu, Feb 26, 2015 at 9:07 AM, Felipe Balbi <balbi@xxxxxx> wrote:
>> > There was already a proper place where we were
>> > checking for babble interrupts, move babble
>> > recovery there.
>> >
>> > Signed-off-by: Felipe Balbi <balbi@xxxxxx>
>> > ---
>> > drivers/usb/musb/musb_core.c | 13 ++++++-------
>> > 1 file changed, 6 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>> > index 2767ce1bf016..0569b24719e6 100644
>> > --- a/drivers/usb/musb/musb_core.c
>> > +++ b/drivers/usb/musb/musb_core.c
>> > @@ -892,6 +892,12 @@ b_host:
>> > } else {
>> > ERR("Stopping host session -- babble\n");
>> > musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
>> > +
>> > + if (is_host_active(musb)) {
>> > + musb_generic_disable(musb);
>> > + schedule_delayed_work(&musb->recover_work,
>> > + msecs_to_jiffies(100));
>> > + }
>>
>> This change breaks babble recovery, because the following lines above here
>>
>> 873 if (devctl & (MUSB_DEVCTL_FSDEV |
>> MUSB_DEVCTL_LSDEV)) {
>> 874 dev_dbg(musb->controller, "BABBLE
>> devctl: %02x\n", devctl);
>>
>> have a bug - DEVCTL_FSDEV bit will be set for high-speed too, so this
>> 'if' traps babble handling for all cases, never hit on 'else'.
>
> We might as well drop that check altogether. Let me see what happens
> here.
It is good to clean it up, but I guess the babble storm you see is
caused by something else. I debugged the storm last year in an older
kernel, it was due to the babble recovery routine does not maintain a
bit in MUSB_BABBLE_CTL, though I forgot the details now. I am looking
at this part in the upstream kernel right now.
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
