All of lore.kernel.org
 help / color / mirror / Atom feed
* MUSB dual-role on AM335x behaving weirdly
@ 2015-01-21 16:06 Maxime Ripard
  2015-01-21 18:53 ` Bin Liu
  0 siblings, 1 reply; 42+ messages in thread
From: Maxime Ripard @ 2015-01-21 16:06 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Felipe,

I'm currently working on a custom AM335x-based board, that has a OTG
connector wired to one of the musb controlers, and Linux 3.17

This OTG connector seems to behave in a weird way when it comes to
switching from one role to another:

  - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if
    the dr_mode is set to host in the DT, and only if we plug the USB
    device after the kernel has booted. Otherwise, even though the
    controller seems to be set up as host in the kernel logs, it
    doesn't work. When DR-mode is set to otg, DRVVBUS is not high
    which surely doesn't help, but there might be some other issues.

  - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode
    is set to otg and not host (obviously), and only if we plug the
    USB cable after the kernel has booted.

  - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with
    dr_mode set to otg, even if we cold plug the device.

  - As you might expect from the two first items, the runtime
    switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is
    set and dr_mode is set in otg doesn't work either.

It looks like it's only waiting for an interrupt to occur to read the
ID pin state, without reading its initial value, which would explain
why both the host and gadget enumerate only when a device/cable is
hotplugged, and that there's some configuration bits that differ
whenever dr_mode changes, but I couldn't really see anything standing
out in the driver nor the datasheet.

Have you already experienced something alike with that driver?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150121/01f9c534/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-01-21 16:06 MUSB dual-role on AM335x behaving weirdly Maxime Ripard
@ 2015-01-21 18:53 ` Bin Liu
  2015-01-22  7:37   ` Yegor Yefremov
  0 siblings, 1 reply; 42+ messages in thread
From: Bin Liu @ 2015-01-21 18:53 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Felipe,
>
> I'm currently working on a custom AM335x-based board, that has a OTG
> connector wired to one of the musb controlers, and Linux 3.17
>
> This OTG connector seems to behave in a weird way when it comes to
> switching from one role to another:
>
>   - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if
>     the dr_mode is set to host in the DT, and only if we plug the USB
>     device after the kernel has booted. Otherwise, even though the
>     controller seems to be set up as host in the kernel logs, it
>     doesn't work. When DR-mode is set to otg, DRVVBUS is not high
>     which surely doesn't help, but there might be some other issues.
>
>   - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode
>     is set to otg and not host (obviously), and only if we plug the
>     USB cable after the kernel has booted.
>
>   - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with
>     dr_mode set to otg, even if we cold plug the device.
>
>   - As you might expect from the two first items, the runtime
>     switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is
>     set and dr_mode is set in otg doesn't work either.
>
> It looks like it's only waiting for an interrupt to occur to read the
> ID pin state, without reading its initial value, which would explain
> why both the host and gadget enumerate only when a device/cable is
> hotplugged, and that there's some configuration bits that differ
> whenever dr_mode changes, but I couldn't really see anything standing
> out in the driver nor the datasheet.
>
> Have you already experienced something alike with that driver?

I don't use vanilla mainline kernel very often, but I don't have such
hotplug issues with TI 3.12/14 kernels [1]. I only use
CONFIG_USB_MUSB_DUAL_ROLE though.

[1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch
remote/origin/linux-3.14.y

Regards,
-Bin.

>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-01-21 18:53 ` Bin Liu
@ 2015-01-22  7:37   ` Yegor Yefremov
  2015-01-22 10:43     ` Maxime Ripard
  2015-02-05 13:21     ` Maxime Ripard
  0 siblings, 2 replies; 42+ messages in thread
From: Yegor Yefremov @ 2015-01-22  7:37 UTC (permalink / raw)
  To: linux-arm-kernel

On 21.01.2015 19:53, Bin Liu wrote:
> Hi,
> 
> On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>> Hi Felipe,
>>
>> I'm currently working on a custom AM335x-based board, that has a OTG
>> connector wired to one of the musb controlers, and Linux 3.17
>>
>> This OTG connector seems to behave in a weird way when it comes to
>> switching from one role to another:
>>
>>   - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if
>>     the dr_mode is set to host in the DT, and only if we plug the USB
>>     device after the kernel has booted. Otherwise, even though the
>>     controller seems to be set up as host in the kernel logs, it
>>     doesn't work. When DR-mode is set to otg, DRVVBUS is not high
>>     which surely doesn't help, but there might be some other issues.
>>
>>   - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode
>>     is set to otg and not host (obviously), and only if we plug the
>>     USB cable after the kernel has booted.
>>
>>   - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with
>>     dr_mode set to otg, even if we cold plug the device.
>>
>>   - As you might expect from the two first items, the runtime
>>     switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is
>>     set and dr_mode is set in otg doesn't work either.
>>
>> It looks like it's only waiting for an interrupt to occur to read the
>> ID pin state, without reading its initial value, which would explain
>> why both the host and gadget enumerate only when a device/cable is
>> hotplugged, and that there's some configuration bits that differ
>> whenever dr_mode changes, but I couldn't really see anything standing
>> out in the driver nor the datasheet.
>>
>> Have you already experienced something alike with that driver?
> 
> I don't use vanilla mainline kernel very often, but I don't have such
> hotplug issues with TI 3.12/14 kernels [1]. I only use
> CONFIG_USB_MUSB_DUAL_ROLE though.
> 
> [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch
> remote/origin/linux-3.14.y

I have the same experience with 3.15. The switching is working when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 it seems to be broken. Still had no time to bisect this.

Yegor

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-01-22  7:37   ` Yegor Yefremov
@ 2015-01-22 10:43     ` Maxime Ripard
  2015-01-22 11:01       ` Markus Pargmann
  2015-02-05 13:21     ` Maxime Ripard
  1 sibling, 1 reply; 42+ messages in thread
From: Maxime Ripard @ 2015-01-22 10:43 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Yegor,

On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> On 21.01.2015 19:53, Bin Liu wrote:
> > Hi,
> > 
> > On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> >> Hi Felipe,
> >>
> >> I'm currently working on a custom AM335x-based board, that has a OTG
> >> connector wired to one of the musb controlers, and Linux 3.17
> >>
> >> This OTG connector seems to behave in a weird way when it comes to
> >> switching from one role to another:
> >>
> >>   - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if
> >>     the dr_mode is set to host in the DT, and only if we plug the USB
> >>     device after the kernel has booted. Otherwise, even though the
> >>     controller seems to be set up as host in the kernel logs, it
> >>     doesn't work. When DR-mode is set to otg, DRVVBUS is not high
> >>     which surely doesn't help, but there might be some other issues.
> >>
> >>   - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode
> >>     is set to otg and not host (obviously), and only if we plug the
> >>     USB cable after the kernel has booted.
> >>
> >>   - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with
> >>     dr_mode set to otg, even if we cold plug the device.
> >>
> >>   - As you might expect from the two first items, the runtime
> >>     switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is
> >>     set and dr_mode is set in otg doesn't work either.
> >>
> >> It looks like it's only waiting for an interrupt to occur to read the
> >> ID pin state, without reading its initial value, which would explain
> >> why both the host and gadget enumerate only when a device/cable is
> >> hotplugged, and that there's some configuration bits that differ
> >> whenever dr_mode changes, but I couldn't really see anything standing
> >> out in the driver nor the datasheet.
> >>
> >> Have you already experienced something alike with that driver?
> > 
> > I don't use vanilla mainline kernel very often, but I don't have such
> > hotplug issues with TI 3.12/14 kernels [1]. I only use
> > CONFIG_USB_MUSB_DUAL_ROLE though.
> > 
> > [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch
> > remote/origin/linux-3.14.y
> 
> I have the same experience with 3.15. The switching is working when
> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> it seems to be broken. Still had no time to bisect this.

I just gave 3.15 a quick try, and it looks like it can now detect when
the device is acting as a gadget, but the host mode is not working at
all.

That's a good lead though, I'll dig more into the older versions and
see if some are working better than others.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150122/e9c37ade/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-01-22 10:43     ` Maxime Ripard
@ 2015-01-22 11:01       ` Markus Pargmann
  2015-01-22 14:00         ` Maxime Ripard
  0 siblings, 1 reply; 42+ messages in thread
From: Markus Pargmann @ 2015-01-22 11:01 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Thu, Jan 22, 2015 at 11:43:30AM +0100, Maxime Ripard wrote:
> Hi Yegor,
> 
> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > On 21.01.2015 19:53, Bin Liu wrote:
> > > Hi,
> > > 
> > > On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard
> > > <maxime.ripard@free-electrons.com> wrote:
> > >> Hi Felipe,
> > >>
> > >> I'm currently working on a custom AM335x-based board, that has a OTG
> > >> connector wired to one of the musb controlers, and Linux 3.17
> > >>
> > >> This OTG connector seems to behave in a weird way when it comes to
> > >> switching from one role to another:
> > >>
> > >>   - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if
> > >>     the dr_mode is set to host in the DT, and only if we plug the USB
> > >>     device after the kernel has booted. Otherwise, even though the
> > >>     controller seems to be set up as host in the kernel logs, it
> > >>     doesn't work. When DR-mode is set to otg, DRVVBUS is not high
> > >>     which surely doesn't help, but there might be some other issues.
> > >>
> > >>   - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode
> > >>     is set to otg and not host (obviously), and only if we plug the
> > >>     USB cable after the kernel has booted.
> > >>
> > >>   - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with
> > >>     dr_mode set to otg, even if we cold plug the device.
> > >>
> > >>   - As you might expect from the two first items, the runtime
> > >>     switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is
> > >>     set and dr_mode is set in otg doesn't work either.
> > >>
> > >> It looks like it's only waiting for an interrupt to occur to read the
> > >> ID pin state, without reading its initial value, which would explain
> > >> why both the host and gadget enumerate only when a device/cable is
> > >> hotplugged, and that there's some configuration bits that differ
> > >> whenever dr_mode changes, but I couldn't really see anything standing
> > >> out in the driver nor the datasheet.
> > >>
> > >> Have you already experienced something alike with that driver?
> > > 
> > > I don't use vanilla mainline kernel very often, but I don't have such
> > > hotplug issues with TI 3.12/14 kernels [1]. I only use
> > > CONFIG_USB_MUSB_DUAL_ROLE though.
> > > 
> > > [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch
> > > remote/origin/linux-3.14.y
> > 
> > I have the same experience with 3.15. The switching is working when
> > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> > it seems to be broken. Still had no time to bisect this.
> 
> I just gave 3.15 a quick try, and it looks like it can now detect when
> the device is acting as a gadget, but the host mode is not working at
> all.
> 
> That's a good lead though, I'll dig more into the older versions and
> see if some are working better than others.

This issue may be related to the fact that the musb controller does not
have an ID pin interrupt. Last year I sent a RFC for a soft detection in
OTG mode. It has a poll loop which toggles the SESSION bit of the
controller to detect devices as host and drops back to device otherwise.
This is far away from a good solution.

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/204519.html

Best Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150122/0a823516/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-01-22 11:01       ` Markus Pargmann
@ 2015-01-22 14:00         ` Maxime Ripard
  2015-01-22 14:52           ` Bin Liu
  0 siblings, 1 reply; 42+ messages in thread
From: Maxime Ripard @ 2015-01-22 14:00 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Markus,

On Thu, Jan 22, 2015 at 12:01:13PM +0100, Markus Pargmann wrote:
> Hi,
> 
> On Thu, Jan 22, 2015 at 11:43:30AM +0100, Maxime Ripard wrote:
> > Hi Yegor,
> > 
> > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > > On 21.01.2015 19:53, Bin Liu wrote:
> > > > Hi,
> > > > 
> > > > On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard
> > > > <maxime.ripard@free-electrons.com> wrote:
> > > >> Hi Felipe,
> > > >>
> > > >> I'm currently working on a custom AM335x-based board, that has a OTG
> > > >> connector wired to one of the musb controlers, and Linux 3.17
> > > >>
> > > >> This OTG connector seems to behave in a weird way when it comes to
> > > >> switching from one role to another:
> > > >>
> > > >>   - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if
> > > >>     the dr_mode is set to host in the DT, and only if we plug the USB
> > > >>     device after the kernel has booted. Otherwise, even though the
> > > >>     controller seems to be set up as host in the kernel logs, it
> > > >>     doesn't work. When DR-mode is set to otg, DRVVBUS is not high
> > > >>     which surely doesn't help, but there might be some other issues.
> > > >>
> > > >>   - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode
> > > >>     is set to otg and not host (obviously), and only if we plug the
> > > >>     USB cable after the kernel has booted.
> > > >>
> > > >>   - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with
> > > >>     dr_mode set to otg, even if we cold plug the device.
> > > >>
> > > >>   - As you might expect from the two first items, the runtime
> > > >>     switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is
> > > >>     set and dr_mode is set in otg doesn't work either.
> > > >>
> > > >> It looks like it's only waiting for an interrupt to occur to read the
> > > >> ID pin state, without reading its initial value, which would explain
> > > >> why both the host and gadget enumerate only when a device/cable is
> > > >> hotplugged, and that there's some configuration bits that differ
> > > >> whenever dr_mode changes, but I couldn't really see anything standing
> > > >> out in the driver nor the datasheet.
> > > >>
> > > >> Have you already experienced something alike with that driver?
> > > > 
> > > > I don't use vanilla mainline kernel very often, but I don't have such
> > > > hotplug issues with TI 3.12/14 kernels [1]. I only use
> > > > CONFIG_USB_MUSB_DUAL_ROLE though.
> > > > 
> > > > [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch
> > > > remote/origin/linux-3.14.y
> > > 
> > > I have the same experience with 3.15. The switching is working when
> > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> > > it seems to be broken. Still had no time to bisect this.
> > 
> > I just gave 3.15 a quick try, and it looks like it can now detect when
> > the device is acting as a gadget, but the host mode is not working at
> > all.
> > 
> > That's a good lead though, I'll dig more into the older versions and
> > see if some are working better than others.
> 
> This issue may be related to the fact that the musb controller does not
> have an ID pin interrupt. Last year I sent a RFC for a soft detection in
> OTG mode. It has a poll loop which toggles the SESSION bit of the
> controller to detect devices as host and drops back to device otherwise.
> This is far away from a good solution.
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/204519.html

I guess it was a combination of two issues: after giving your patch a
try, I found out that (even without your patch), in OTG mode, the
gadget device is properly attached even if plugged before the kernel
boots. I don't really know how I missed that, but anyway...

I also tested to force the ID pin to the ground when a USB device was
plugged in, and it then enumerates properly, both when cold and hot
plugging. It's a bit weird because the adapter I'm using is working
fine on other boards, but maybe the AM335x controller is a bit more
picky with the ID pin, or that the other SoC I was testing it on
(Atmel's sama5d4) is quite relaxed about it.

I'm guessing that when forced in the host mode, the driver ignores
completely the ID pin, hence why it was working properly with that
setup.

Thanks a lot,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150122/078ecda9/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-01-22 14:00         ` Maxime Ripard
@ 2015-01-22 14:52           ` Bin Liu
  0 siblings, 0 replies; 42+ messages in thread
From: Bin Liu @ 2015-01-22 14:52 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Thu, Jan 22, 2015 at 8:00 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Markus,
>
> On Thu, Jan 22, 2015 at 12:01:13PM +0100, Markus Pargmann wrote:
>> Hi,
>>
>> On Thu, Jan 22, 2015 at 11:43:30AM +0100, Maxime Ripard wrote:
>> > Hi Yegor,
>> >
>> > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
>> > > On 21.01.2015 19:53, Bin Liu wrote:
>> > > > Hi,
>> > > >
>> > > > On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard
>> > > > <maxime.ripard@free-electrons.com> wrote:
>> > > >> Hi Felipe,
>> > > >>
>> > > >> I'm currently working on a custom AM335x-based board, that has a OTG
>> > > >> connector wired to one of the musb controlers, and Linux 3.17
>> > > >>
>> > > >> This OTG connector seems to behave in a weird way when it comes to
>> > > >> switching from one role to another:
>> > > >>
>> > > >>   - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if
>> > > >>     the dr_mode is set to host in the DT, and only if we plug the USB
>> > > >>     device after the kernel has booted. Otherwise, even though the
>> > > >>     controller seems to be set up as host in the kernel logs, it
>> > > >>     doesn't work. When DR-mode is set to otg, DRVVBUS is not high
>> > > >>     which surely doesn't help, but there might be some other issues.
>> > > >>
>> > > >>   - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode
>> > > >>     is set to otg and not host (obviously), and only if we plug the
>> > > >>     USB cable after the kernel has booted.
>> > > >>
>> > > >>   - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with
>> > > >>     dr_mode set to otg, even if we cold plug the device.
>> > > >>
>> > > >>   - As you might expect from the two first items, the runtime
>> > > >>     switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is
>> > > >>     set and dr_mode is set in otg doesn't work either.
>> > > >>
>> > > >> It looks like it's only waiting for an interrupt to occur to read the
>> > > >> ID pin state, without reading its initial value, which would explain
>> > > >> why both the host and gadget enumerate only when a device/cable is
>> > > >> hotplugged, and that there's some configuration bits that differ
>> > > >> whenever dr_mode changes, but I couldn't really see anything standing
>> > > >> out in the driver nor the datasheet.
>> > > >>
>> > > >> Have you already experienced something alike with that driver?
>> > > >
>> > > > I don't use vanilla mainline kernel very often, but I don't have such
>> > > > hotplug issues with TI 3.12/14 kernels [1]. I only use
>> > > > CONFIG_USB_MUSB_DUAL_ROLE though.
>> > > >
>> > > > [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch
>> > > > remote/origin/linux-3.14.y
>> > >
>> > > I have the same experience with 3.15. The switching is working when
>> > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
>> > > it seems to be broken. Still had no time to bisect this.
>> >
>> > I just gave 3.15 a quick try, and it looks like it can now detect when
>> > the device is acting as a gadget, but the host mode is not working at
>> > all.
>> >
>> > That's a good lead though, I'll dig more into the older versions and
>> > see if some are working better than others.
>>
>> This issue may be related to the fact that the musb controller does not
>> have an ID pin interrupt. Last year I sent a RFC for a soft detection in
>> OTG mode. It has a poll loop which toggles the SESSION bit of the
>> controller to detect devices as host and drops back to device otherwise.
>> This is far away from a good solution.
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/204519.html
>
> I guess it was a combination of two issues: after giving your patch a
> try, I found out that (even without your patch), in OTG mode, the
> gadget device is properly attached even if plugged before the kernel
> boots. I don't really know how I missed that, but anyway...
>
> I also tested to force the ID pin to the ground when a USB device was
> plugged in, and it then enumerates properly, both when cold and hot
> plugging. It's a bit weird because the adapter I'm using is working
> fine on other boards, but maybe the AM335x controller is a bit more
> picky with the ID pin, or that the other SoC I was testing it on

On the hw side, for AM335x MUSB controller to work in host mode, the
ID pin has to be grounded directly or via a resister which is less
than 10 Ohms.

So, for dr_mode = host, the ID pin is normally grounded directly on
the board; for dr_mode = org, a micro-A cable should be used to ensure
the ID pin is properly grounded.

Regards,
-Bin.

> (Atmel's sama5d4) is quite relaxed about it.
>
> I'm guessing that when forced in the host mode, the driver ignores
> completely the ID pin, hence why it was working properly with that
> setup.
>
> Thanks a lot,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-01-22  7:37   ` Yegor Yefremov
  2015-01-22 10:43     ` Maxime Ripard
@ 2015-02-05 13:21     ` Maxime Ripard
  2015-02-24 10:39       ` Maxime Ripard
  2015-04-14 15:46       ` Maxime Ripard
  1 sibling, 2 replies; 42+ messages in thread
From: Maxime Ripard @ 2015-02-05 13:21 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> I have the same experience with 3.15. The switching is working when
> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> it seems to be broken. Still had no time to bisect this.

I've been giving a few versions (from v3.15 to Tuesday's linux-next) a
try, and I always see the same behaviour now:

  - Booting as a gadget (ie, with a USB cable plugged in), and
    swapping the cable for a (real, this time) USB OTG cable with a
    USB key never works. When the device is plugged, all I get is

[  262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc
[  278.064748] usb 1-1: device descriptor read/64, error -110

    Putting in back in gadget results with a load of continuous:
[  315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active

  - Booting as a host, or with nothing connected to it actually work,
    up to a few plug-a-device-then-plug-a-host cycles, where you end
    up with the following logs when disconnecting the device (somehow,
    it always happens when it is set in host mode).

[   12.969075] CAUTION: musb: Babble Interrupt Occurred
[   12.974445] CAUTION: musb: Babble Interrupt Occurred
[   12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon)
[   12.988498] usb 1-1: USB disconnect, device number 2
[   13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble

    Plugging back our USB cable, with the AM335x acting as a device
    work once. Then, when it switches to the host mode, we end up with
    the same scenario than in the coldplug as gadget case: USB read
    error, before then having all the a_wait_vfall messages.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150205/2d577670/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-02-05 13:21     ` Maxime Ripard
@ 2015-02-24 10:39       ` Maxime Ripard
  2015-02-24 14:54         ` Felipe Balbi
  2015-04-14 15:46       ` Maxime Ripard
  1 sibling, 1 reply; 42+ messages in thread
From: Maxime Ripard @ 2015-02-24 10:39 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > I have the same experience with 3.15. The switching is working when
> > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> > it seems to be broken. Still had no time to bisect this.
> 
> I've been giving a few versions (from v3.15 to Tuesday's linux-next) a
> try, and I always see the same behaviour now:
> 
>   - Booting as a gadget (ie, with a USB cable plugged in), and
>     swapping the cable for a (real, this time) USB OTG cable with a
>     USB key never works. When the device is plugged, all I get is
> 
> [  262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc
> [  278.064748] usb 1-1: device descriptor read/64, error -110
> 
>     Putting in back in gadget results with a load of continuous:
> [  315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
> 
>   - Booting as a host, or with nothing connected to it actually work,
>     up to a few plug-a-device-then-plug-a-host cycles, where you end
>     up with the following logs when disconnecting the device (somehow,
>     it always happens when it is set in host mode).
> 
> [   12.969075] CAUTION: musb: Babble Interrupt Occurred
> [   12.974445] CAUTION: musb: Babble Interrupt Occurred
> [   12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon)
> [   12.988498] usb 1-1: USB disconnect, device number 2
> [   13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble
> 
>     Plugging back our USB cable, with the AM335x acting as a device
>     work once. Then, when it switches to the host mode, we end up with
>     the same scenario than in the coldplug as gadget case: USB read
>     error, before then having all the a_wait_vfall messages.

Guys, any ideas/hints?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150224/432a844e/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-02-24 10:39       ` Maxime Ripard
@ 2015-02-24 14:54         ` Felipe Balbi
  2015-02-24 16:50           ` Maxime Ripard
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-02-24 14:54 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > > I have the same experience with 3.15. The switching is working when
> > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> > > it seems to be broken. Still had no time to bisect this.
> > 
> > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a
> > try, and I always see the same behaviour now:
> > 
> >   - Booting as a gadget (ie, with a USB cable plugged in), and
> >     swapping the cable for a (real, this time) USB OTG cable with a
> >     USB key never works. When the device is plugged, all I get is
> > 
> > [  262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc
> > [  278.064748] usb 1-1: device descriptor read/64, error -110
> > 
> >     Putting in back in gadget results with a load of continuous:
> > [  315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
> > 
> >   - Booting as a host, or with nothing connected to it actually work,
> >     up to a few plug-a-device-then-plug-a-host cycles, where you end
> >     up with the following logs when disconnecting the device (somehow,
> >     it always happens when it is set in host mode).
> > 
> > [   12.969075] CAUTION: musb: Babble Interrupt Occurred
> > [   12.974445] CAUTION: musb: Babble Interrupt Occurred
> > [   12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon)
> > [   12.988498] usb 1-1: USB disconnect, device number 2
> > [   13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble
> > 
> >     Plugging back our USB cable, with the AM335x acting as a device
> >     work once. Then, when it switches to the host mode, we end up with
> >     the same scenario than in the coldplug as gadget case: USB read
> >     error, before then having all the a_wait_vfall messages.
> 
> Guys, any ideas/hints?

which platform are you using ? I guess the only way to move here would
be to bisect between 3.15 and 3.16 to find the offending commit.

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150224/2214b21b/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-02-24 14:54         ` Felipe Balbi
@ 2015-02-24 16:50           ` Maxime Ripard
  2015-02-24 17:33             ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Maxime Ripard @ 2015-02-24 16:50 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Felipe,

On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
> > On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > > > I have the same experience with 3.15. The switching is working when
> > > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> > > > it seems to be broken. Still had no time to bisect this.
> > > 
> > > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a
> > > try, and I always see the same behaviour now:
> > > 
> > >   - Booting as a gadget (ie, with a USB cable plugged in), and
> > >     swapping the cable for a (real, this time) USB OTG cable with a
> > >     USB key never works. When the device is plugged, all I get is
> > > 
> > > [  262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc
> > > [  278.064748] usb 1-1: device descriptor read/64, error -110
> > > 
> > >     Putting in back in gadget results with a load of continuous:
> > > [  315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
> > > 
> > >   - Booting as a host, or with nothing connected to it actually work,
> > >     up to a few plug-a-device-then-plug-a-host cycles, where you end
> > >     up with the following logs when disconnecting the device (somehow,
> > >     it always happens when it is set in host mode).
> > > 
> > > [   12.969075] CAUTION: musb: Babble Interrupt Occurred
> > > [   12.974445] CAUTION: musb: Babble Interrupt Occurred
> > > [   12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon)
> > > [   12.988498] usb 1-1: USB disconnect, device number 2
> > > [   13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble
> > > 
> > >     Plugging back our USB cable, with the AM335x acting as a device
> > >     work once. Then, when it switches to the host mode, we end up with
> > >     the same scenario than in the coldplug as gadget case: USB read
> > >     error, before then having all the a_wait_vfall messages.
> > 
> > Guys, any ideas/hints?
> 
> which platform are you using ? I guess the only way to move here would
> be to bisect between 3.15 and 3.16 to find the offending commit.

3.15 didn't work either unfortunately. I had the behaviour described
above on all kernel between 3.15 and a 4.0-rc1-ish.

This is on an custom design based on the am335x.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150224/1e7f76f6/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-02-24 16:50           ` Maxime Ripard
@ 2015-02-24 17:33             ` Felipe Balbi
  2015-02-25 11:11               ` Maxime Ripard
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-02-24 17:33 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
> Hi Felipe,
> 
> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
> > Hi,
> > 
> > On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
> > > On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> > > > Hi,
> > > > 
> > > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > > > > I have the same experience with 3.15. The switching is working when
> > > > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16

since 3.16 ?

> > > > > it seems to be broken. Still had no time to bisect this.
> > > > 
> > > > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a
> > > > try, and I always see the same behaviour now:
> > > > 
> > > >   - Booting as a gadget (ie, with a USB cable plugged in), and
> > > >     swapping the cable for a (real, this time) USB OTG cable with a
> > > >     USB key never works. When the device is plugged, all I get is
> > > > 
> > > > [  262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc
> > > > [  278.064748] usb 1-1: device descriptor read/64, error -110
> > > > 
> > > >     Putting in back in gadget results with a load of continuous:
> > > > [  315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
> > > > 
> > > >   - Booting as a host, or with nothing connected to it actually work,
> > > >     up to a few plug-a-device-then-plug-a-host cycles, where you end
> > > >     up with the following logs when disconnecting the device (somehow,
> > > >     it always happens when it is set in host mode).
> > > > 
> > > > [   12.969075] CAUTION: musb: Babble Interrupt Occurred
> > > > [   12.974445] CAUTION: musb: Babble Interrupt Occurred
> > > > [   12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon)
> > > > [   12.988498] usb 1-1: USB disconnect, device number 2
> > > > [   13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble
> > > > 
> > > >     Plugging back our USB cable, with the AM335x acting as a device
> > > >     work once. Then, when it switches to the host mode, we end up with
> > > >     the same scenario than in the coldplug as gadget case: USB read
> > > >     error, before then having all the a_wait_vfall messages.
> > > 
> > > Guys, any ideas/hints?
> > 
> > which platform are you using ? I guess the only way to move here would
> > be to bisect between 3.15 and 3.16 to find the offending commit.
> 
> 3.15 didn't work either unfortunately. I had the behaviour described
> above on all kernel between 3.15 and a 4.0-rc1-ish.
> 
> This is on an custom design based on the am335x.

has it ever worked ? I don't have a board here which can do dual role.
BBB has a mini-B only on the peripheral port.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150224/94530cd6/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-02-24 17:33             ` Felipe Balbi
@ 2015-02-25 11:11               ` Maxime Ripard
  2015-02-25 12:11                 ` Yegor Yefremov
  0 siblings, 1 reply; 42+ messages in thread
From: Maxime Ripard @ 2015-02-25 11:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
> > Hi Felipe,
> > 
> > On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
> > > > On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> > > > > Hi,
> > > > > 
> > > > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > > > > > I have the same experience with 3.15. The switching is working when
> > > > > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> 
> since 3.16 ?

That's what Yegor said. I never saw it working with 3.15 either.

> > > > > > it seems to be broken. Still had no time to bisect this.
> > > > > 
> > > > > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a
> > > > > try, and I always see the same behaviour now:
> > > > > 
> > > > >   - Booting as a gadget (ie, with a USB cable plugged in), and
> > > > >     swapping the cable for a (real, this time) USB OTG cable with a
> > > > >     USB key never works. When the device is plugged, all I get is
> > > > > 
> > > > > [  262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc
> > > > > [  278.064748] usb 1-1: device descriptor read/64, error -110
> > > > > 
> > > > >     Putting in back in gadget results with a load of continuous:
> > > > > [  315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
> > > > > 
> > > > >   - Booting as a host, or with nothing connected to it actually work,
> > > > >     up to a few plug-a-device-then-plug-a-host cycles, where you end
> > > > >     up with the following logs when disconnecting the device (somehow,
> > > > >     it always happens when it is set in host mode).
> > > > > 
> > > > > [   12.969075] CAUTION: musb: Babble Interrupt Occurred
> > > > > [   12.974445] CAUTION: musb: Babble Interrupt Occurred
> > > > > [   12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon)
> > > > > [   12.988498] usb 1-1: USB disconnect, device number 2
> > > > > [   13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble
> > > > > 
> > > > >     Plugging back our USB cable, with the AM335x acting as a device
> > > > >     work once. Then, when it switches to the host mode, we end up with
> > > > >     the same scenario than in the coldplug as gadget case: USB read
> > > > >     error, before then having all the a_wait_vfall messages.
> > > > 
> > > > Guys, any ideas/hints?
> > > 
> > > which platform are you using ? I guess the only way to move here would
> > > be to bisect between 3.15 and 3.16 to find the offending commit.
> > 
> > 3.15 didn't work either unfortunately. I had the behaviour described
> > above on all kernel between 3.15 and a 4.0-rc1-ish.
> > 
> > This is on an custom design based on the am335x.
> 
> has it ever worked ? I don't have a board here which can do dual role.
> BBB has a mini-B only on the peripheral port.

I don't know if it ever worked.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150225/a871dc57/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-02-25 11:11               ` Maxime Ripard
@ 2015-02-25 12:11                 ` Yegor Yefremov
  2015-05-14 17:07                   ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Yegor Yefremov @ 2015-02-25 12:11 UTC (permalink / raw)
  To: linux-arm-kernel

On 25.02.2015 12:11, Maxime Ripard wrote:
> On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
>> Hi,
>>
>> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
>>> Hi Felipe,
>>>
>>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
>>>> Hi,
>>>>
>>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
>>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
>>>>>>> I have the same experience with 3.15. The switching is working when
>>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
>>
>> since 3.16 ?
> 
> That's what Yegor said. I never saw it working with 3.15 either.

I've used 3.15.1 and 3.15.2 with this set of patches: https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15

And it worked so far. The system: http://www.visionsystems.de/produkte/baltos-ir-5221.html

>>>>>>> it seems to be broken. Still had no time to bisect this.
>>>>>>
>>>>>> I've been giving a few versions (from v3.15 to Tuesday's linux-next) a
>>>>>> try, and I always see the same behaviour now:
>>>>>>
>>>>>>   - Booting as a gadget (ie, with a USB cable plugged in), and
>>>>>>     swapping the cable for a (real, this time) USB OTG cable with a
>>>>>>     USB key never works. When the device is plugged, all I get is
>>>>>>
>>>>>> [  262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc
>>>>>> [  278.064748] usb 1-1: device descriptor read/64, error -110
>>>>>>
>>>>>>     Putting in back in gadget results with a load of continuous:
>>>>>> [  315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
>>>>>>
>>>>>>   - Booting as a host, or with nothing connected to it actually work,
>>>>>>     up to a few plug-a-device-then-plug-a-host cycles, where you end
>>>>>>     up with the following logs when disconnecting the device (somehow,
>>>>>>     it always happens when it is set in host mode).
>>>>>>
>>>>>> [   12.969075] CAUTION: musb: Babble Interrupt Occurred
>>>>>> [   12.974445] CAUTION: musb: Babble Interrupt Occurred
>>>>>> [   12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon)
>>>>>> [   12.988498] usb 1-1: USB disconnect, device number 2
>>>>>> [   13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble
>>>>>>
>>>>>>     Plugging back our USB cable, with the AM335x acting as a device
>>>>>>     work once. Then, when it switches to the host mode, we end up with
>>>>>>     the same scenario than in the coldplug as gadget case: USB read
>>>>>>     error, before then having all the a_wait_vfall messages.
>>>>>
>>>>> Guys, any ideas/hints?
>>>>
>>>> which platform are you using ? I guess the only way to move here would
>>>> be to bisect between 3.15 and 3.16 to find the offending commit.
>>>
>>> 3.15 didn't work either unfortunately. I had the behaviour described
>>> above on all kernel between 3.15 and a 4.0-rc1-ish.
>>>
>>> This is on an custom design based on the am335x.
>>
>> has it ever worked ? I don't have a board here which can do dual role.
>> BBB has a mini-B only on the peripheral port.
> 
> I don't know if it ever worked.
> 
> Maxime
> 

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-02-05 13:21     ` Maxime Ripard
  2015-02-24 10:39       ` Maxime Ripard
@ 2015-04-14 15:46       ` Maxime Ripard
  1 sibling, 0 replies; 42+ messages in thread
From: Maxime Ripard @ 2015-04-14 15:46 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > I have the same experience with 3.15. The switching is working when
> > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> > it seems to be broken. Still had no time to bisect this.
> 
> I've been giving a few versions (from v3.15 to Tuesday's linux-next) a
> try, and I always see the same behaviour now:
> 
>   - Booting as a gadget (ie, with a USB cable plugged in), and
>     swapping the cable for a (real, this time) USB OTG cable with a
>     USB key never works. When the device is plugged, all I get is
> 
> [  262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc
> [  278.064748] usb 1-1: device descriptor read/64, error -110
> 
>     Putting in back in gadget results with a load of continuous:
> [  315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
> 
>   - Booting as a host, or with nothing connected to it actually work,
>     up to a few plug-a-device-then-plug-a-host cycles, where you end
>     up with the following logs when disconnecting the device (somehow,
>     it always happens when it is set in host mode).
> 
> [   12.969075] CAUTION: musb: Babble Interrupt Occurred
> [   12.974445] CAUTION: musb: Babble Interrupt Occurred
> [   12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon)
> [   12.988498] usb 1-1: USB disconnect, device number 2
> [   13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble
> 
>     Plugging back our USB cable, with the AM335x acting as a device
>     work once. Then, when it switches to the host mode, we end up with
>     the same scenario than in the coldplug as gadget case: USB read
>     error, before then having all the a_wait_vfall messages.

I gave it some more testing these two days, with next-20150410, with
pretty much the same results.

Dumping the DSPS glue registers doesn't get anywhere, in both cases
(booting as peripheral and then switching to host, or booting as host)
they are identical.

However, the musb registers vary greatly.

In the first case, we boot as host, switch to peripheral, and then
switch back to host, repeatedly until it fails:

http://code.bulix.org/p0d964-88211?raw

We can see that while it still works, value comes back to their
original state when switching back to host, which makes sense.

However, when it fails, some registers are not set back to their
initial values, including TxMaxPp, TxCSRp, RxMaxPp, ConfigData,
DevCtl, TxFIFOadd and RxFIFOadd.

Some registers that were not changing while it was working also now
have a different value: TxMaxPp, RxMaxPp, MISC, TxFIFOsz and RxFIFOsz.

Starting with the device as peripheral, and then switching to host
fails instantly, once again with exotic values for the registers
compared to the configuration set whenever the host mode is working:

http://code.bulix.org/uo8fmu-88210?raw

However, the registers values are quite similar to the one we got
previously when the host mode was failing after a while, which might
indicate that we end up in the same case somehow.

Since I've not been able to find the musb datasheet, I'm unfortunately
unable to make any deduction from these besides that something looks
fishy.

I've also did some runs with the musb glue and core compiled with
debug options:

Booted as host:
http://code.bulix.org/97jz3i-88207?raw

Booted as peripheral:
http://code.bulix.org/vqdqt6-88208?raw

I hope it helps...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150414/60f5fe1e/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-02-25 12:11                 ` Yegor Yefremov
@ 2015-05-14 17:07                   ` Felipe Balbi
  2015-05-14 17:40                     ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-05-14 17:07 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote:
> On 25.02.2015 12:11, Maxime Ripard wrote:
> > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
> >> Hi,
> >>
> >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
> >>> Hi Felipe,
> >>>
> >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
> >>>> Hi,
> >>>>
> >>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
> >>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> >>>>>>> I have the same experience with 3.15. The switching is working when
> >>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> >>
> >> since 3.16 ?
> > 
> > That's what Yegor said. I never saw it working with 3.15 either.
> 
> I've used 3.15.1 and 3.15.2 with this set of patches:
> https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15
> 
> And it worked so far. The system:
> http://www.visionsystems.de/produkte/baltos-ir-5221.html

I've had more time to look into this (thanks Yegor for sponsoring a
test/dev platform) what I noticed is that Connect IRQ takes seconds to
fire up.  Below a tiny log snippet after pluging USB OTG adapter cable
that came with IR5521:

| [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)

Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ

| [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19

MUSB starts to wait for VBUS to reach Session valid threshold

| [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)

3 seconds later connect interrupt happens. Looking at VBUS charge time
with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig
further into this.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150514/6f32602a/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 17:07                   ` Felipe Balbi
@ 2015-05-14 17:40                     ` Felipe Balbi
  2015-05-14 17:49                       ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-05-14 17:40 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, May 14, 2015 at 12:07:00PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote:
> > On 25.02.2015 12:11, Maxime Ripard wrote:
> > > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
> > >> Hi,
> > >>
> > >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
> > >>> Hi Felipe,
> > >>>
> > >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
> > >>>> Hi,
> > >>>>
> > >>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
> > >>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > >>>>>>> I have the same experience with 3.15. The switching is working when
> > >>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> > >>
> > >> since 3.16 ?
> > > 
> > > That's what Yegor said. I never saw it working with 3.15 either.
> > 
> > I've used 3.15.1 and 3.15.2 with this set of patches:
> > https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15
> > 
> > And it worked so far. The system:
> > http://www.visionsystems.de/produkte/baltos-ir-5221.html
> 
> I've had more time to look into this (thanks Yegor for sponsoring a
> test/dev platform) what I noticed is that Connect IRQ takes seconds to
> fire up.  Below a tiny log snippet after pluging USB OTG adapter cable
> that came with IR5521:
> 
> | [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
> 
> Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ
> 
> | [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
> 
> MUSB starts to wait for VBUS to reach Session valid threshold
> 
> | [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
> 
> 3 seconds later connect interrupt happens. Looking at VBUS charge time
> with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig
> further into this.

even more weird. If I disconnect device from OTG adapter, rather than
OTG adapter from IR5521, this leave ID pin grounded, which means DRVVBUS
is still asserted and VBUS remains above session valid threshold.

Even in this case, when I connect the device on the other end of the
cable, I still see some 3 seconds delay from the time device is
connected, to the time connect IRQ fires up.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150514/3ef6f526/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 17:40                     ` Felipe Balbi
@ 2015-05-14 17:49                       ` Felipe Balbi
  2015-05-14 19:04                         ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-05-14 17:49 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, May 14, 2015 at 12:40:31PM -0500, Felipe Balbi wrote:
> On Thu, May 14, 2015 at 12:07:00PM -0500, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote:
> > > On 25.02.2015 12:11, Maxime Ripard wrote:
> > > > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
> > > >> Hi,
> > > >>
> > > >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
> > > >>> Hi Felipe,
> > > >>>
> > > >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
> > > >>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> > > >>>>>> Hi,
> > > >>>>>>
> > > >>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > > >>>>>>> I have the same experience with 3.15. The switching is working when
> > > >>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> > > >>
> > > >> since 3.16 ?
> > > > 
> > > > That's what Yegor said. I never saw it working with 3.15 either.
> > > 
> > > I've used 3.15.1 and 3.15.2 with this set of patches:
> > > https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15
> > > 
> > > And it worked so far. The system:
> > > http://www.visionsystems.de/produkte/baltos-ir-5221.html
> > 
> > I've had more time to look into this (thanks Yegor for sponsoring a
> > test/dev platform) what I noticed is that Connect IRQ takes seconds to
> > fire up.  Below a tiny log snippet after pluging USB OTG adapter cable
> > that came with IR5521:
> > 
> > | [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
> > 
> > Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ
> > 
> > | [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
> > 
> > MUSB starts to wait for VBUS to reach Session valid threshold
> > 
> > | [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
> > 
> > 3 seconds later connect interrupt happens. Looking at VBUS charge time
> > with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig
> > further into this.
> 
> even more weird. If I disconnect device from OTG adapter, rather than
> OTG adapter from IR5521, this leave ID pin grounded, which means DRVVBUS
> is still asserted and VBUS remains above session valid threshold.
> 
> Even in this case, when I connect the device on the other end of the
> cable, I still see some 3 seconds delay from the time device is
> connected, to the time connect IRQ fires up.

seems to be a problem with the USB stick I'm using. Tested two other
devices and they connect right away.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150514/f8328869/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 17:49                       ` Felipe Balbi
@ 2015-05-14 19:04                         ` Felipe Balbi
  2015-05-14 19:19                           ` Bin Liu
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-05-14 19:04 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, May 14, 2015 at 12:49:07PM -0500, Felipe Balbi wrote:
> On Thu, May 14, 2015 at 12:40:31PM -0500, Felipe Balbi wrote:
> > On Thu, May 14, 2015 at 12:07:00PM -0500, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote:
> > > > On 25.02.2015 12:11, Maxime Ripard wrote:
> > > > > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
> > > > >> Hi,
> > > > >>
> > > > >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
> > > > >>> Hi Felipe,
> > > > >>>
> > > > >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
> > > > >>>> Hi,
> > > > >>>>
> > > > >>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
> > > > >>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> > > > >>>>>> Hi,
> > > > >>>>>>
> > > > >>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> > > > >>>>>>> I have the same experience with 3.15. The switching is working when
> > > > >>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> > > > >>
> > > > >> since 3.16 ?
> > > > > 
> > > > > That's what Yegor said. I never saw it working with 3.15 either.
> > > > 
> > > > I've used 3.15.1 and 3.15.2 with this set of patches:
> > > > https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15
> > > > 
> > > > And it worked so far. The system:
> > > > http://www.visionsystems.de/produkte/baltos-ir-5221.html
> > > 
> > > I've had more time to look into this (thanks Yegor for sponsoring a
> > > test/dev platform) what I noticed is that Connect IRQ takes seconds to
> > > fire up.  Below a tiny log snippet after pluging USB OTG adapter cable
> > > that came with IR5521:
> > > 
> > > | [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
> > > 
> > > Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ
> > > 
> > > | [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
> > > 
> > > MUSB starts to wait for VBUS to reach Session valid threshold
> > > 
> > > | [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
> > > 
> > > 3 seconds later connect interrupt happens. Looking at VBUS charge time
> > > with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig
> > > further into this.
> > 
> > even more weird. If I disconnect device from OTG adapter, rather than
> > OTG adapter from IR5521, this leave ID pin grounded, which means DRVVBUS
> > is still asserted and VBUS remains above session valid threshold.
> > 
> > Even in this case, when I connect the device on the other end of the
> > cable, I still see some 3 seconds delay from the time device is
> > connected, to the time connect IRQ fires up.
> 
> seems to be a problem with the USB stick I'm using. Tested two other
> devices and they connect right away.

ok, fixing DRD on AM335x will take longer than I originally expected,
probably won't be ready for v4.2 :-(

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150514/4198f8c7/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 19:04                         ` Felipe Balbi
@ 2015-05-14 19:19                           ` Bin Liu
  2015-05-14 19:21                             ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Bin Liu @ 2015-05-14 19:19 UTC (permalink / raw)
  To: linux-arm-kernel

Felipe,

On Thu, May 14, 2015 at 2:04 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Thu, May 14, 2015 at 12:49:07PM -0500, Felipe Balbi wrote:
>> On Thu, May 14, 2015 at 12:40:31PM -0500, Felipe Balbi wrote:
>> > On Thu, May 14, 2015 at 12:07:00PM -0500, Felipe Balbi wrote:
>> > > Hi,
>> > >
>> > > On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote:
>> > > > On 25.02.2015 12:11, Maxime Ripard wrote:
>> > > > > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
>> > > > >> Hi,
>> > > > >>
>> > > > >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
>> > > > >>> Hi Felipe,
>> > > > >>>
>> > > > >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
>> > > > >>>> Hi,
>> > > > >>>>
>> > > > >>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
>> > > > >>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
>> > > > >>>>>> Hi,
>> > > > >>>>>>
>> > > > >>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
>> > > > >>>>>>> I have the same experience with 3.15. The switching is working when
>> > > > >>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
>> > > > >>
>> > > > >> since 3.16 ?
>> > > > >
>> > > > > That's what Yegor said. I never saw it working with 3.15 either.
>> > > >
>> > > > I've used 3.15.1 and 3.15.2 with this set of patches:
>> > > > https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15
>> > > >
>> > > > And it worked so far. The system:
>> > > > http://www.visionsystems.de/produkte/baltos-ir-5221.html
>> > >
>> > > I've had more time to look into this (thanks Yegor for sponsoring a
>> > > test/dev platform) what I noticed is that Connect IRQ takes seconds to
>> > > fire up.  Below a tiny log snippet after pluging USB OTG adapter cable
>> > > that came with IR5521:
>> > >
>> > > | [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
>> > >
>> > > Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ
>> > >
>> > > | [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
>> > >
>> > > MUSB starts to wait for VBUS to reach Session valid threshold
>> > >
>> > > | [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
>> > >
>> > > 3 seconds later connect interrupt happens. Looking at VBUS charge time
>> > > with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig
>> > > further into this.
>> >
>> > even more weird. If I disconnect device from OTG adapter, rather than
>> > OTG adapter from IR5521, this leave ID pin grounded, which means DRVVBUS
>> > is still asserted and VBUS remains above session valid threshold.
>> >
>> > Even in this case, when I connect the device on the other end of the
>> > cable, I still see some 3 seconds delay from the time device is
>> > connected, to the time connect IRQ fires up.
>>
>> seems to be a problem with the USB stick I'm using. Tested two other
>> devices and they connect right away.
>
> ok, fixing DRD on AM335x will take longer than I originally expected,
> probably won't be ready for v4.2 :-(

Are you able replicate the issue with TI AM335x GP EVM? I am wondering
if the is custom board design problem? have you checked the custom
board schematics?

Regards,
-Bin.

>
> --
> balbi

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 19:19                           ` Bin Liu
@ 2015-05-14 19:21                             ` Felipe Balbi
  2015-05-14 19:29                               ` Bin Liu
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-05-14 19:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, May 14, 2015 at 02:19:28PM -0500, Bin Liu wrote:
> Felipe,
> 
> On Thu, May 14, 2015 at 2:04 PM, Felipe Balbi <balbi@ti.com> wrote:
> > On Thu, May 14, 2015 at 12:49:07PM -0500, Felipe Balbi wrote:
> >> On Thu, May 14, 2015 at 12:40:31PM -0500, Felipe Balbi wrote:
> >> > On Thu, May 14, 2015 at 12:07:00PM -0500, Felipe Balbi wrote:
> >> > > Hi,
> >> > >
> >> > > On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote:
> >> > > > On 25.02.2015 12:11, Maxime Ripard wrote:
> >> > > > > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
> >> > > > >> Hi,
> >> > > > >>
> >> > > > >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
> >> > > > >>> Hi Felipe,
> >> > > > >>>
> >> > > > >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
> >> > > > >>>> Hi,
> >> > > > >>>>
> >> > > > >>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
> >> > > > >>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> >> > > > >>>>>> Hi,
> >> > > > >>>>>>
> >> > > > >>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> >> > > > >>>>>>> I have the same experience with 3.15. The switching is working when
> >> > > > >>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> >> > > > >>
> >> > > > >> since 3.16 ?
> >> > > > >
> >> > > > > That's what Yegor said. I never saw it working with 3.15 either.
> >> > > >
> >> > > > I've used 3.15.1 and 3.15.2 with this set of patches:
> >> > > > https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15
> >> > > >
> >> > > > And it worked so far. The system:
> >> > > > http://www.visionsystems.de/produkte/baltos-ir-5221.html
> >> > >
> >> > > I've had more time to look into this (thanks Yegor for sponsoring a
> >> > > test/dev platform) what I noticed is that Connect IRQ takes seconds to
> >> > > fire up.  Below a tiny log snippet after pluging USB OTG adapter cable
> >> > > that came with IR5521:
> >> > >
> >> > > | [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
> >> > >
> >> > > Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ
> >> > >
> >> > > | [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
> >> > >
> >> > > MUSB starts to wait for VBUS to reach Session valid threshold
> >> > >
> >> > > | [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
> >> > >
> >> > > 3 seconds later connect interrupt happens. Looking at VBUS charge time
> >> > > with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig
> >> > > further into this.
> >> >
> >> > even more weird. If I disconnect device from OTG adapter, rather than
> >> > OTG adapter from IR5521, this leave ID pin grounded, which means DRVVBUS
> >> > is still asserted and VBUS remains above session valid threshold.
> >> >
> >> > Even in this case, when I connect the device on the other end of the
> >> > cable, I still see some 3 seconds delay from the time device is
> >> > connected, to the time connect IRQ fires up.
> >>
> >> seems to be a problem with the USB stick I'm using. Tested two other
> >> devices and they connect right away.
> >
> > ok, fixing DRD on AM335x will take longer than I originally expected,
> > probably won't be ready for v4.2 :-(
> 
> Are you able replicate the issue with TI AM335x GP EVM? I am wondering
> if the is custom board design problem? have you checked the custom
> board schematics?

don't have either AM335x GP EVM nor schematics for this board. But it's
certainly not a problem with the board. It's very easy to replicate the
problem:

Set dr-mode to otg, load g_zero, connect to PC and as quickly as you
can, remove cable and attach otg cable with a mouse or whatever on the
other end.

First time, mouse won't enumerate (no IRQs fire) remove and connect
again. You should see a Babble IRQ.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150514/3f950387/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 19:21                             ` Felipe Balbi
@ 2015-05-14 19:29                               ` Bin Liu
  2015-05-14 19:29                                 ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Bin Liu @ 2015-05-14 19:29 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, May 14, 2015 at 2:21 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Thu, May 14, 2015 at 02:19:28PM -0500, Bin Liu wrote:
>> Felipe,
>>
>> On Thu, May 14, 2015 at 2:04 PM, Felipe Balbi <balbi@ti.com> wrote:
>> > On Thu, May 14, 2015 at 12:49:07PM -0500, Felipe Balbi wrote:
>> >> On Thu, May 14, 2015 at 12:40:31PM -0500, Felipe Balbi wrote:
>> >> > On Thu, May 14, 2015 at 12:07:00PM -0500, Felipe Balbi wrote:
>> >> > > Hi,
>> >> > >
>> >> > > On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote:
>> >> > > > On 25.02.2015 12:11, Maxime Ripard wrote:
>> >> > > > > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
>> >> > > > >> Hi,
>> >> > > > >>
>> >> > > > >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
>> >> > > > >>> Hi Felipe,
>> >> > > > >>>
>> >> > > > >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
>> >> > > > >>>> Hi,
>> >> > > > >>>>
>> >> > > > >>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
>> >> > > > >>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
>> >> > > > >>>>>> Hi,
>> >> > > > >>>>>>
>> >> > > > >>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
>> >> > > > >>>>>>> I have the same experience with 3.15. The switching is working when
>> >> > > > >>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
>> >> > > > >>
>> >> > > > >> since 3.16 ?
>> >> > > > >
>> >> > > > > That's what Yegor said. I never saw it working with 3.15 either.
>> >> > > >
>> >> > > > I've used 3.15.1 and 3.15.2 with this set of patches:
>> >> > > > https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15
>> >> > > >
>> >> > > > And it worked so far. The system:
>> >> > > > http://www.visionsystems.de/produkte/baltos-ir-5221.html
>> >> > >
>> >> > > I've had more time to look into this (thanks Yegor for sponsoring a
>> >> > > test/dev platform) what I noticed is that Connect IRQ takes seconds to
>> >> > > fire up.  Below a tiny log snippet after pluging USB OTG adapter cable
>> >> > > that came with IR5521:
>> >> > >
>> >> > > | [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
>> >> > >
>> >> > > Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ
>> >> > >
>> >> > > | [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
>> >> > >
>> >> > > MUSB starts to wait for VBUS to reach Session valid threshold
>> >> > >
>> >> > > | [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
>> >> > >
>> >> > > 3 seconds later connect interrupt happens. Looking at VBUS charge time
>> >> > > with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig
>> >> > > further into this.
>> >> >
>> >> > even more weird. If I disconnect device from OTG adapter, rather than
>> >> > OTG adapter from IR5521, this leave ID pin grounded, which means DRVVBUS
>> >> > is still asserted and VBUS remains above session valid threshold.
>> >> >
>> >> > Even in this case, when I connect the device on the other end of the
>> >> > cable, I still see some 3 seconds delay from the time device is
>> >> > connected, to the time connect IRQ fires up.
>> >>
>> >> seems to be a problem with the USB stick I'm using. Tested two other
>> >> devices and they connect right away.
>> >
>> > ok, fixing DRD on AM335x will take longer than I originally expected,
>> > probably won't be ready for v4.2 :-(
>>
>> Are you able replicate the issue with TI AM335x GP EVM? I am wondering
>> if the is custom board design problem? have you checked the custom
>> board schematics?
>
> don't have either AM335x GP EVM nor schematics for this board. But it's
> certainly not a problem with the board. It's very easy to replicate the
> problem:
>
> Set dr-mode to otg, load g_zero, connect to PC and as quickly as you
> can, remove cable and attach otg cable with a mouse or whatever on the
> other end.
>
> First time, mouse won't enumerate (no IRQs fire) remove and connect
> again. You should see a Babble IRQ.

And this only happens with 3.16+, not older kernels? I have a GP EVM,
and can try to take a look.

/me just figured out the modem issue, and in a very good mood now ;)

>
> --
> balbi

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 19:29                               ` Bin Liu
@ 2015-05-14 19:29                                 ` Felipe Balbi
  2015-05-14 19:49                                   ` Felipe Balbi
  2015-05-14 21:04                                   ` Bin Liu
  0 siblings, 2 replies; 42+ messages in thread
From: Felipe Balbi @ 2015-05-14 19:29 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, May 14, 2015 at 02:29:20PM -0500, Bin Liu wrote:
> On Thu, May 14, 2015 at 2:21 PM, Felipe Balbi <balbi@ti.com> wrote:
> > On Thu, May 14, 2015 at 02:19:28PM -0500, Bin Liu wrote:
> >> Felipe,
> >>
> >> On Thu, May 14, 2015 at 2:04 PM, Felipe Balbi <balbi@ti.com> wrote:
> >> > On Thu, May 14, 2015 at 12:49:07PM -0500, Felipe Balbi wrote:
> >> >> On Thu, May 14, 2015 at 12:40:31PM -0500, Felipe Balbi wrote:
> >> >> > On Thu, May 14, 2015 at 12:07:00PM -0500, Felipe Balbi wrote:
> >> >> > > Hi,
> >> >> > >
> >> >> > > On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote:
> >> >> > > > On 25.02.2015 12:11, Maxime Ripard wrote:
> >> >> > > > > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
> >> >> > > > >> Hi,
> >> >> > > > >>
> >> >> > > > >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
> >> >> > > > >>> Hi Felipe,
> >> >> > > > >>>
> >> >> > > > >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
> >> >> > > > >>>> Hi,
> >> >> > > > >>>>
> >> >> > > > >>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
> >> >> > > > >>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
> >> >> > > > >>>>>> Hi,
> >> >> > > > >>>>>>
> >> >> > > > >>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
> >> >> > > > >>>>>>> I have the same experience with 3.15. The switching is working when
> >> >> > > > >>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
> >> >> > > > >>
> >> >> > > > >> since 3.16 ?
> >> >> > > > >
> >> >> > > > > That's what Yegor said. I never saw it working with 3.15 either.
> >> >> > > >
> >> >> > > > I've used 3.15.1 and 3.15.2 with this set of patches:
> >> >> > > > https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15
> >> >> > > >
> >> >> > > > And it worked so far. The system:
> >> >> > > > http://www.visionsystems.de/produkte/baltos-ir-5221.html
> >> >> > >
> >> >> > > I've had more time to look into this (thanks Yegor for sponsoring a
> >> >> > > test/dev platform) what I noticed is that Connect IRQ takes seconds to
> >> >> > > fire up.  Below a tiny log snippet after pluging USB OTG adapter cable
> >> >> > > that came with IR5521:
> >> >> > >
> >> >> > > | [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
> >> >> > >
> >> >> > > Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ
> >> >> > >
> >> >> > > | [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
> >> >> > >
> >> >> > > MUSB starts to wait for VBUS to reach Session valid threshold
> >> >> > >
> >> >> > > | [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
> >> >> > >
> >> >> > > 3 seconds later connect interrupt happens. Looking at VBUS charge time
> >> >> > > with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig
> >> >> > > further into this.
> >> >> >
> >> >> > even more weird. If I disconnect device from OTG adapter, rather than
> >> >> > OTG adapter from IR5521, this leave ID pin grounded, which means DRVVBUS
> >> >> > is still asserted and VBUS remains above session valid threshold.
> >> >> >
> >> >> > Even in this case, when I connect the device on the other end of the
> >> >> > cable, I still see some 3 seconds delay from the time device is
> >> >> > connected, to the time connect IRQ fires up.
> >> >>
> >> >> seems to be a problem with the USB stick I'm using. Tested two other
> >> >> devices and they connect right away.
> >> >
> >> > ok, fixing DRD on AM335x will take longer than I originally expected,
> >> > probably won't be ready for v4.2 :-(
> >>
> >> Are you able replicate the issue with TI AM335x GP EVM? I am wondering
> >> if the is custom board design problem? have you checked the custom
> >> board schematics?
> >
> > don't have either AM335x GP EVM nor schematics for this board. But it's
> > certainly not a problem with the board. It's very easy to replicate the
> > problem:
> >
> > Set dr-mode to otg, load g_zero, connect to PC and as quickly as you
> > can, remove cable and attach otg cable with a mouse or whatever on the
> > other end.
> >
> > First time, mouse won't enumerate (no IRQs fire) remove and connect
> > again. You should see a Babble IRQ.
> 
> And this only happens with 3.16+, not older kernels? I have a GP EVM,
> and can try to take a look.

yeah, if you can try with v4.1-rc3, that'd be great. I also see that
disconnect IRQ takes a while to fire, but VBUS drops rather fast on this
board (< 10ms to discharge VBUS).

> /me just figured out the modem issue, and in a very good mood now ;)

hey, congrats :-)

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150514/94dcc393/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 19:29                                 ` Felipe Balbi
@ 2015-05-14 19:49                                   ` Felipe Balbi
  2015-05-14 20:03                                     ` Bin Liu
  2015-05-14 21:04                                   ` Bin Liu
  1 sibling, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-05-14 19:49 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Thu, May 14, 2015 at 02:29:46PM -0500, Felipe Balbi wrote:
> > >> >> > Even in this case, when I connect the device on the other end of the
> > >> >> > cable, I still see some 3 seconds delay from the time device is
> > >> >> > connected, to the time connect IRQ fires up.
> > >> >>
> > >> >> seems to be a problem with the USB stick I'm using. Tested two other
> > >> >> devices and they connect right away.
> > >> >
> > >> > ok, fixing DRD on AM335x will take longer than I originally expected,
> > >> > probably won't be ready for v4.2 :-(
> > >>
> > >> Are you able replicate the issue with TI AM335x GP EVM? I am wondering
> > >> if the is custom board design problem? have you checked the custom
> > >> board schematics?
> > >
> > > don't have either AM335x GP EVM nor schematics for this board. But it's
> > > certainly not a problem with the board. It's very easy to replicate the
> > > problem:
> > >
> > > Set dr-mode to otg, load g_zero, connect to PC and as quickly as you
> > > can, remove cable and attach otg cable with a mouse or whatever on the
> > > other end.
> > >
> > > First time, mouse won't enumerate (no IRQs fire) remove and connect
> > > again. You should see a Babble IRQ.
> > 
> > And this only happens with 3.16+, not older kernels? I have a GP EVM,
> > and can try to take a look.
> 
> yeah, if you can try with v4.1-rc3, that'd be great. I also see that
> disconnect IRQ takes a while to fire, but VBUS drops rather fast on this
> board (< 10ms to discharge VBUS).

Here are some logs:

| # modprobe g_zero
| [   38.941293] udc musb-hdrc.1.auto: registering UDC driver [zero]
| [   39.065822] zero gadget: adding 'source/sink'/ccdab140 to config 'source/sink'/bf19765c
| [   39.074533] zero gadget: dual speed source/sink: IN/ep1in, OUT/ep1out, ISO-IN/ep13, ISO-OUT/ep14
| [   39.083896] zero gadget: adding 'loopback'/cf787640 to config 'loopback'/bf1976d0
| [   39.091834] zero gadget: dual speed loopback: IN/ep1in, OUT/ep1out
| [   39.098349] zero gadget: Gadget Zero, version: Cinco de Mayo 2008
| [   39.104807] zero gadget: zero ready
| [   39.108779] musb-hdrc musb-hdrc.1.auto: <== devctl 80
| [   39.114229] musb-hdrc musb-hdrc.1.auto: Longer idle timer already pending, ignoring...
| [   39.123982] musb-hdrc musb-hdrc.1.auto: gadget D+ pullup on
| [   41.112292] musb-hdrc musb-hdrc.1.auto: Poll devctl 80 (b_idle)
| [   43.111703] musb-hdrc musb-hdrc.1.auto: Poll devctl 80 (b_idle)
| [   45.111680] musb-hdrc musb-hdrc.1.auto: Poll devctl 80 (b_idle)
| [   47.111675] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
| [   47.173434] musb-hdrc musb-hdrc.1.auto: usbintr (1) epintr(0)

cable connected, got Suspend IRQ (??)

| [   47.179518] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0001 tx0000 rx0000
| [   47.187212] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x1
| [   47.193719] musb-hdrc musb-hdrc.1.auto: SUSPEND (b_idle) devctl 99
| [   47.299901] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   47.305988] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   47.313682] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   47.320188] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_idle
| [   47.326055] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   47.410509] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   47.416593] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   47.424292] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   47.431442] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   47.439319] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l64
| [   47.446191] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   47.453255] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
| [   47.460311] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
| [   47.468280] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
| [   47.475530] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   47.481583] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   47.489275] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
| [   47.496896] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   47.502945] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   47.510636] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   47.517141] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   47.523556] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   47.642485] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   47.648570] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   47.656267] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   47.663417] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   47.671294] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0012 i0000 l0
| [   47.678074] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
| [   47.685859] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   47.691913] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   47.699605] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
| [   47.707134] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   47.713184] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   47.720876] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   47.727381] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   47.733795] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   47.815356] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   47.821441] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   47.829136] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   47.835642] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   47.842057] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   48.026508] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   48.032593] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   48.040291] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   48.047442] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   48.055319] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l64
| [   48.062191] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   48.069256] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
| [   48.076312] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
| [   48.084281] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
| [   48.091659] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   48.097717] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   48.105411] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
| [   48.113028] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   48.119078] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   48.126769] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   48.133274] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   48.139689] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   48.258488] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   48.264572] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   48.272269] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   48.279420] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   48.287297] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0014 i0000 l0
| [   48.294077] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
| [   48.301866] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   48.307920] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   48.315612] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
| [   48.323141] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   48.329191] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   48.336883] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   48.343387] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   48.349802] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   48.839062] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   48.845148] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   48.852842] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   48.859347] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   48.865762] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   48.946477] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   48.952563] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   48.960261] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   48.967411] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   48.975288] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0010 i0000 l0
| [   48.982068] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
| [   48.989856] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   48.995910] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.003601] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
| [   49.122453] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.128539] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.136237] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage idle
| [   49.143296] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   49.151173] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l8
| [   49.157953] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   49.165018] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=8
| [   49.171982] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cccdcc00
| [   49.179860] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  8/8
| [   49.187041] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.193099] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.200792] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   49.208394] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   49.216269] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l18
| [   49.223138] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   49.230194] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
| [   49.237248] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
| [   49.245215] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
| [   49.252379] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.258429] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.266120] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   49.273721] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   49.281595] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0200 i0000 l9
| [   49.288373] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   49.295434] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=9
| [   49.302396] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 9 buf cccdcc00
| [   49.310270] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  9/9
| [   49.317251] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.323301] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.330993] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   49.338593] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   49.346467] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0200 i0000 l69
| [   49.353336] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   49.360393] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=69
| [   49.367446] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 64 buf cccdcc00
| [   49.375429] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.381478] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.389170] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in
| [   49.396040] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 5 buf cccdcc40
| [   49.403915] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  69/69
| [   49.411075] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.417125] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.424817] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   49.432417] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   49.440291] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0201 i0000 l9
| [   49.447069] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   49.454124] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=9
| [   49.461087] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 9 buf cccdcc00
| [   49.468960] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  9/9
| [   49.475941] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.481991] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.489682] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   49.497282] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   49.505156] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0201 i0000 l32
| [   49.512025] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   49.519080] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=32
| [   49.526133] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 32 buf cccdcc00
| [   49.534098] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  32/32
| [   49.541260] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.547310] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.555002] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   49.562602] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   49.570477] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0300 i0000 l255
| [   49.577437] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   49.584496] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=4
| [   49.591459] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 4 buf cccdcc00
| [   49.599333] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  4/4
| [   49.606313] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.612363] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.620054] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   49.627654] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   49.635529] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0302 i0409 l255
| [   49.642489] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   49.649548] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=24
| [   49.656602] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 24 buf cccdcc00
| [   49.664568] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  24/24
| [   49.671730] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.677780] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.685472] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   49.693071] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   49.700946] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0301 i0409 l255
| [   49.707906] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   49.714963] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=114
| [   49.722108] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 64 buf cccdcc00
| [   49.730091] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.736140] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.743831] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in
| [   49.750701] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 50 buf cccdcc40
| [   49.758667] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  114/114
| [   49.766019] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.772070] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.779761] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   49.787361] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9cf0
| [   49.795236] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0303 i0409 l255
| [   49.802196] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   49.809252] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=66
| [   49.816305] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 64 buf cccdcc00
| [   49.824289] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.830340] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.838031] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in
| [   49.844902] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 2 buf cccdcc40
| [   49.852776] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  66/66
| [   49.859933] musb-hdrc musb-hdrc.1.auto: Poll devctl 99 (b_peripheral)
| [   49.859955] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   49.872768] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   49.880459] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   49.888060] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9ae0
| [   49.895934] musb-hdrc musb-hdrc.1.auto: SETUP req00.09 v0003 i0000 l0
| [   49.902712] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage wait
| [   49.909950] zero gadget: high-speed config #3: source/sink

Enumerated

| [   49.917388] musb-hdrc periph: enabled ep1in for bulk IN, maxpacket 512
| [   49.924603] musb-hdrc musb-hdrc.1.auto: <== to ep1in request=cf70d6c0
| [   49.931393] musb-hdrc musb-hdrc.1.auto: <== TX/IN request cf70d6c0 len 4096 on hw_ep1
| [   49.939635] musb-hdrc musb-hdrc.1.auto: hw_ep1, maxpacket 512, fifo count 512, txcsr 2000
| [   49.948241] musb-hdrc musb-hdrc.1.auto: TX ep1 fifo d1a82c24 count 512 buf ccc30000
| [   49.956305] musb-hdrc musb-hdrc.1.auto: ep1in TX/IN pio len 512/4096, txcsr 2003, fifo 512/512
| [   49.965368] musb-hdrc periph: enabled ep1out for bulk OUT, maxpacket 512
| [   49.972430] musb-hdrc musb-hdrc.1.auto: <== to ep1out request=ccdab040
| [   49.979302] musb-hdrc musb-hdrc.1.auto: <== RX/OUT request ccdab040 len 4096 on hw_ep1
| [   49.987634] zero gadget: source/sink enabled, alt intf 0

Alternate Setting chosen.

| [   49.993231] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=0
| [   50.000193] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  0/0
| [   50.007194] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   50.013245] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   50.020938] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage in/status
| [   50.028449] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9ae0
| [   50.036325] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0304 i0409 l255
| [   50.043286] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   50.050346] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=42
| [   50.057400] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 42 buf cccdcc00
| [   50.065366] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  42/42
| [   50.072567] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   50.078619] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   50.086310] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
| [   53.156419] musb-hdrc musb-hdrc.1.auto: usbintr (1) epintr(0)

Cable removed, but I got a Suspend IRQ.

| [   53.162507] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0001 tx0000 rx0000
| [   53.170201] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x1
| [   53.176709] musb-hdrc musb-hdrc.1.auto: SUSPEND (b_peripheral) devctl 99
| [   53.183760] musb-hdrc musb-hdrc.1.auto: devctl 99
| [   53.188713] zero gadget: suspend
| [   53.192111] zero gadget: zero_suspend

Gadget driver suspended

| [   59.289314] musb-hdrc musb-hdrc.1.auto: usbintr (20) epintr(0)

6.09 seconds later we get Disconnect IRQ (???????????). No idea what's
going on here. Why 6 seconds for Disconnect IRQ to fire ?

| [   59.295494] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0020 tx0000 rx0000
| [   59.303187] musb-hdrc musb-hdrc.1.auto: <== DevCtl=88, int_usb=0x20
| [   59.309786] musb-hdrc musb-hdrc.1.auto: DISCONNECT (b_peripheral) as Peripheral, devctl 88
| [   59.318482] musb-hdrc musb-hdrc.1.auto: devctl 88
| [   59.323439] zero gadget: reset config
| [   59.327312] musb-hdrc musb-hdrc.1.auto: ep1in request cf70d6c0, 512/4096 fault -108
| [   59.336523] musb-hdrc musb-hdrc.1.auto: ep1in
| [   59.341133] musb-hdrc musb-hdrc.1.auto: ep1out request ccdab040, 0/4096 fault -108
| [   59.349106] musb-hdrc musb-hdrc.1.auto: ep1out

Disconnect IRQ handled. All outstanding requests given back, etc.

| [   61.281706] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)

ID pin polling restarts

| [   63.281681] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)

again

| [   65.281681] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)

again

| [   67.281681] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)

again

| [   69.281682] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)

again

| [   69.340437] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)

ID pin grounded (DRVVBUS changed due to ID going low)

| [   69.346711] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19

VBUS goes on, a_wait_vrise

| [   69.461549] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)

Connect IRQ. We're now HOST.

| [   69.467726] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0010 tx0000 rx0000
| [   69.474874] musb-hdrc musb-hdrc.1.auto: <== DevCtl=3d, int_usb=0x10
| [   69.481531] musb-hdrc musb-hdrc.1.auto: CONNECT (a_host) devctl 3d
| [   69.488158] usb usb2: usb wakeup-resume
| [   69.492361] usb usb2: usb auto-resume
| [   69.496228] musb-hdrc musb-hdrc.1.auto: root port reset stopped
| [   69.502540] hub 2-0:1.0: hub_resume
| [   69.506275] musb-hdrc musb-hdrc.1.auto: port status 00130303
| [   69.544084] usb usb2-port1: status 0303 change 0013
| [   69.549304] musb-hdrc musb-hdrc.1.auto: clear feature 1
| [   69.559573] musb-hdrc musb-hdrc.1.auto: clear feature 16
| [   69.569982] musb-hdrc musb-hdrc.1.auto: clear feature 17
| [   69.580388] musb-hdrc musb-hdrc.1.auto: clear feature 20
| [   69.691853] hub 2-0:1.0: state 7 ports 1 chg 0002 evt 0000
| [   69.697734] musb-hdrc musb-hdrc.1.auto: port status 00000301
| [   69.710670] usb usb2-port1: status 0301, change 0000, 1.5 Mb/s
| [   69.717351] musb-hdrc musb-hdrc.1.auto: set feature 4
| [   69.761823] musb-hdrc musb-hdrc.1.auto: root port reset stopped
| [   69.769125] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   69.775185] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0004 tx0000 rx0000
| [   69.782331] musb-hdrc musb-hdrc.1.auto: <== DevCtl=3d, int_usb=0x4
| [   69.788835] musb-hdrc musb-hdrc.1.auto: Babble
| [   69.793527] musb-hdrc musb-hdrc.1.auto: babble: MUSB_BABBLE_CTL value 44
| [   69.800577] musb-hdrc musb-hdrc.1.auto: STUCK_J is reset
| [   69.806269] musb-hdrc: setup fifo_mode 4
| [   69.810413] musb-hdrc: 28/31 max ep, 16384/16384 memory
| [   69.815915] musb-hdrc musb-hdrc.1.auto: <== devctl 98
| [   69.821249] musb-hdrc musb-hdrc.1.auto: Longer idle timer already pending, ignoring...
| [   69.829815] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(2)
| [   69.835873] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0004 tx0002 rx0000
| [   69.843015] musb-hdrc musb-hdrc.1.auto: <== DevCtl=91, int_usb=0x4
| [   69.849519] musb-hdrc musb-hdrc.1.auto: BUS RESET as a_wait_bcon
| [   69.855841] musb-hdrc musb-hdrc.1.auto: HNP: in a_wait_bcon, 1100 msec timeout
| [   69.863450] musb-hdrc musb-hdrc.1.auto: extra TX1 ready, csr 0020
| [   69.872017] musb-hdrc musb-hdrc.1.auto: port status 00010100
| [   69.892140] musb-hdrc musb-hdrc.1.auto: clear feature 20
| [   69.903680] musb-hdrc musb-hdrc.1.auto: clear feature 1
| [   69.910942] musb-hdrc musb-hdrc.1.auto: clear feature 1
| [   69.932876] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
| [   69.939031] musb-hdrc musb-hdrc.1.auto: port status 00010100
| [   69.962046] musb-hdrc musb-hdrc.1.auto: clear feature 16
| [   69.973216] usb usb2-port1: status 0100, change 0001, 12 Mb/s
| [   69.979790] musb-hdrc musb-hdrc.1.auto: port status 00000100
| [   70.010452] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
| [   70.016727] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
| [   70.042019] musb-hdrc musb-hdrc.1.auto: port status 00000100
| [   70.081874] musb-hdrc musb-hdrc.1.auto: port status 00000100
| [   70.121890] musb-hdrc musb-hdrc.1.auto: port status 00000100
| [   70.131541] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
| [   70.137694] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0010 tx0000 rx0000
| [   70.144839] musb-hdrc musb-hdrc.1.auto: <== DevCtl=3d, int_usb=0x10
| [   70.151455] musb-hdrc musb-hdrc.1.auto: CONNECT (a_host) devctl 3d
| [   70.163281] musb-hdrc musb-hdrc.1.auto: port status 00010301
| [   70.169710] musb-hdrc musb-hdrc.1.auto: clear feature 16
| [   70.221845] musb-hdrc musb-hdrc.1.auto: port status 00000301
| [   70.261889] musb-hdrc musb-hdrc.1.auto: port status 00000301
| [   70.301885] musb-hdrc musb-hdrc.1.auto: port status 00000301
| [   70.341888] musb-hdrc musb-hdrc.1.auto: port status 00000301
| [   70.348089] usb usb2-port1: debounce total 200ms stable 100ms status 0x301
| [   70.355564] musb-hdrc musb-hdrc.1.auto: set feature 4
| [   70.401782] musb-hdrc musb-hdrc.1.auto: root port reset stopped
| [   70.421925] musb-hdrc musb-hdrc.1.auto: port status 00120303
| [   70.481812] musb-hdrc musb-hdrc.1.auto: clear feature 20
| [   70.487656] usb 2-1: new low-speed USB device number 3 using musb-hdrc
| [   70.494695] musb-hdrc musb-hdrc.1.auto: qh ccde8cc0 urb ccdab040 dev0 ep0out, hw_ep 0, cf652340/8
| [   70.504042] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev0 ep0out h_addr00 h_port00 bytes 8
| [   70.513933] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf652340
| [   70.521809] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   70.527255] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   70.533311] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   70.540461] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8cc0, count 0, urb ccdab040, stage 1
| [   70.549886] musb-hdrc musb-hdrc.1.auto: start IN-DATA
| [   70.555311] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   70.561363] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   70.568511] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8cc0, count 8, urb ccdab040, stage 2
| [   70.577939] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cccdb040
| [   70.585956] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   70.592012] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   70.599160] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8cc0, count 8, urb ccdab040, stage 2
| [   70.608586] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cccdb048
| [   70.616555] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   70.622609] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   70.629757] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8cc0, count 2, urb ccdab040, stage 2
| [   70.639184] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 2 buf cccdb050
| [   70.647056] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
| [   70.653137] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   70.659190] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   70.666337] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh ccde8cc0, count 0, urb ccdab040, stage 4
| [   70.675969] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev0 ep0in, 18/64
| [   70.748464] musb-hdrc musb-hdrc.1.auto: set feature 4
| [   70.791839] musb-hdrc musb-hdrc.1.auto: root port reset stopped
| [   70.811925] musb-hdrc musb-hdrc.1.auto: port status 00120303
| [   70.871811] musb-hdrc musb-hdrc.1.auto: clear feature 20
| [   70.877702] musb-hdrc musb-hdrc.1.auto: qh ccde8cc0 urb ccdab040 dev0 ep0out, hw_ep 0, cccdb040/8
| [   70.887051] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev0 ep0out h_addr00 h_port00 bytes 8
| [   70.896943] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cccdb040
| [   70.904818] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   70.910347] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   70.916408] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   70.923558] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8cc0, count 0, urb ccdab040, stage 1
| [   70.932983] musb-hdrc musb-hdrc.1.auto: start no-DATA
| [   70.938300] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0860
| [   70.944365] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   70.950419] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   70.957566] musb-hdrc musb-hdrc.1.auto: <== csr0 0841, qh ccde8cc0, count 0, urb ccdab040, stage 4
| [   70.967197] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev0 ep0out, 0/0
| [   70.980094] musb-hdrc musb-hdrc.1.auto: HNP: Unhandled mode a_host
| [   71.042069] musb-hdrc musb-hdrc.1.auto: qh ccde8ac0 urb ccdab040 dev3 ep0out, hw_ep 0, cf652340/8
| [   71.051442] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
| [   71.061345] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf652340
| [   71.069220] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   71.074759] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.080821] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.087972] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8ac0, count 0, urb ccdab040, stage 1
| [   71.097397] musb-hdrc musb-hdrc.1.auto: start IN-DATA
| [   71.102825] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.108880] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.116029] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8ac0, count 8, urb ccdab040, stage 2
| [   71.125458] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cccdb040
| [   71.133461] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.139516] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.146664] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8ac0, count 8, urb ccdab040, stage 2
| [   71.156090] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cccdb048
| [   71.164055] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.170108] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.177255] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8ac0, count 2, urb ccdab040, stage 2
| [   71.186680] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 2 buf cccdb050
| [   71.194553] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
| [   71.200600] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.206652] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.213798] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh ccde8ac0, count 0, urb ccdab040, stage 4
| [   71.223428] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 18/18
| [   71.304075] musb-hdrc musb-hdrc.1.auto: qh ccde8ac0 urb ccdab040 dev3 ep0out, hw_ep 0, cf571d80/8
| [   71.313389] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
| [   71.323222] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf571d80
| [   71.331056] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   71.336615] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.342676] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.349827] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8ac0, count 0, urb ccdab040, stage 1
| [   71.359252] musb-hdrc musb-hdrc.1.auto: start IN-DATA
| [   71.364678] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.370733] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.377880] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8ac0, count 8, urb ccdab040, stage 2
| [   71.387308] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf652340
| [   71.395273] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.401327] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.408473] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8ac0, count 1, urb ccdab040, stage 2
| [   71.417900] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 1 buf cf652348
| [   71.425772] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
| [   71.431817] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.437871] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.445018] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh ccde8ac0, count 0, urb ccdab040, stage 4
| [   71.454647] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 9/9
| [   71.521002] musb-hdrc musb-hdrc.1.auto: qh cf70d6c0 urb ccdab040 dev3 ep0out, hw_ep 0, cf621b00/8
| [   71.530375] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
| [   71.540268] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf621b00
| [   71.548144] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   71.553738] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.559801] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.566953] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh cf70d6c0, count 0, urb ccdab040, stage 1
| [   71.576378] musb-hdrc musb-hdrc.1.auto: start IN-DATA
| [   71.581803] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.587855] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.595002] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cf70d6c0, count 8, urb ccdab040, stage 2
| [   71.604430] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf571d80
| [   71.612446] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.618503] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.625651] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh cf70d6c0, count 8, urb ccdab040, stage 2
| [   71.635078] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf571d88
| [   71.643083] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.649137] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.656284] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cf70d6c0, count 8, urb ccdab040, stage 2
| [   71.665711] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf571d90
| [   71.673691] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.679744] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.686891] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh cf70d6c0, count 8, urb ccdab040, stage 2
| [   71.696317] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf571d98
| [   71.704281] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.710333] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.717481] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cf70d6c0, count 2, urb ccdab040, stage 2
| [   71.726907] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 2 buf cf571da0
| [   71.734779] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
| [   71.740821] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.746873] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.754020] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh cf70d6c0, count 0, urb ccdab040, stage 4
| [   71.763646] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 34/34
| [   71.857582] usb 2-1: skipped 1 descriptor after interface
| [   71.863555] musb-hdrc musb-hdrc.1.auto: qh cf70d6c0 urb ccdab040 dev3 ep0out, hw_ep 0, cf652340/8
| [   71.872903] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
| [   71.882793] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf652340
| [   71.890669] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   71.896237] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.902298] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.909448] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh cf70d6c0, count 0, urb ccdab040, stage 1
| [   71.918873] musb-hdrc musb-hdrc.1.auto: start IN-DATA
| [   71.924299] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.930352] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.937500] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cf70d6c0, count 4, urb ccdab040, stage 2
| [   71.946928] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 4 buf ccc4c700
| [   71.954802] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
| [   71.960849] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   71.966902] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   71.974048] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh cf70d6c0, count 0, urb ccdab040, stage 4
| [   71.983678] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 4/255
| [   72.042307] usb 2-1: default language 0x0409
| [   72.046898] musb-hdrc musb-hdrc.1.auto: qh ccde8cc0 urb ccdab040 dev3 ep0out, hw_ep 0, cf652340/8
| [   72.056243] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
| [   72.066134] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf652340
| [   72.074009] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   72.079561] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.085622] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.092772] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8cc0, count 0, urb ccdab040, stage 1
| [   72.102196] musb-hdrc musb-hdrc.1.auto: start IN-DATA
| [   72.107624] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.113679] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.120826] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8cc0, count 8, urb ccdab040, stage 2
| [   72.130255] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf ccc4c700
| [   72.138240] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.144295] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.151441] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8cc0, count 8, urb ccdab040, stage 2
| [   72.160866] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf ccc4c708
| [   72.168848] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.174900] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.182047] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8cc0, count 8, urb ccdab040, stage 2
| [   72.191473] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf ccc4c710
| [   72.199471] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.205526] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.212673] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8cc0, count 8, urb ccdab040, stage 2
| [   72.222100] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf ccc4c718
| [   72.230065] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.236118] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.243265] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8cc0, count 4, urb ccdab040, stage 2
| [   72.252691] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 4 buf ccc4c720
| [   72.260563] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
| [   72.266607] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.272659] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.279806] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh ccde8cc0, count 0, urb ccdab040, stage 4
| [   72.289435] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 36/255
| [   72.384380] musb-hdrc musb-hdrc.1.auto: qh ccde8ac0 urb ccdab040 dev3 ep0out, hw_ep 0, cf731e00/8
| [   72.393752] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
| [   72.403644] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf731e00
| [   72.411520] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   72.417101] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.423162] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.430312] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8ac0, count 0, urb ccdab040, stage 1
| [   72.439737] musb-hdrc musb-hdrc.1.auto: start IN-DATA
| [   72.445222] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.451278] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.458426] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8ac0, count 8, urb ccdab040, stage 2
| [   72.467854] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf ccc4c700
| [   72.475825] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.481878] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.489025] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8ac0, count 6, urb ccdab040, stage 2
| [   72.498451] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 6 buf ccc4c708
| [   72.506323] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
| [   72.512369] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.518422] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.525568] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh ccde8ac0, count 0, urb ccdab040, stage 4
| [   72.535198] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 14/255
| [   72.601553] usb 2-1: udev 3, busnum 2, minor = 130
| [   72.606785] usb 2-1: New USB device found, idVendor=17ef, idProduct=602e
| [   72.613929] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
| [   72.621442] usb 2-1: Product: USB Optical Mouse
| [   72.626262] usb 2-1: Manufacturer: PixArt
| [   72.650288] usb 2-1: usb_probe_device
| [   72.654398] usb 2-1: configuration #1 chosen from 1 choice

My mouse gets enumerated.

| [   72.660309] musb-hdrc musb-hdrc.1.auto: qh ccde8ac0 urb cf70d6c0 dev3 ep0out, hw_ep 0, cf697040/8
| [   72.669652] musb-hdrc musb-hdrc.1.auto: --> hw0 urb cf70d6c0 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
| [   72.679544] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf697040
| [   72.687420] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   72.692963] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.699023] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.706173] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8ac0, count 0, urb cf70d6c0, stage 1
| [   72.715598] musb-hdrc musb-hdrc.1.auto: start no-DATA
| [   72.720915] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0860
| [   72.726977] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   72.733031] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   72.740178] musb-hdrc musb-hdrc.1.auto: <== csr0 0841, qh ccde8ac0, count 0, urb cf70d6c0, stage 4
| [   72.749807] musb-hdrc musb-hdrc.1.auto: complete cf70d6c0 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0out, 0/0
| [   72.823728] usb 2-1: adding 2-1:1.0 (config #1, interface 0)
| [   72.845576] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
| [   72.851998] musb-hdrc musb-hdrc.1.auto: port status 00020303
| [   72.885276] usb usb2-port1: enable change, status 00000303
| [   72.891142] musb-hdrc musb-hdrc.1.auto: clear feature 17
| [   73.013128] usbhid 2-1:1.0: usb_probe_interface
| [   73.017944] usbhid 2-1:1.0: usb_probe_interface - got id
| [   73.024791] musb-hdrc musb-hdrc.1.auto: qh cf628240 urb cf65ab40 dev3 ep0out, hw_ep 0, cf670240/8
| [   73.034152] musb-hdrc musb-hdrc.1.auto: --> hw0 urb cf65ab40 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
| [   73.044058] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf670240
| [   73.051934] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   73.057439] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.063501] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.070651] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh cf628240, count 0, urb cf65ab40, stage 1
| [   73.080076] musb-hdrc musb-hdrc.1.auto: start no-DATA
| [   73.085394] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0860
| [   73.091454] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.097510] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.104657] musb-hdrc musb-hdrc.1.auto: <== csr0 0a44, qh cf628240, count 0, urb cf65ab40, stage 4
| [   73.114080] musb-hdrc musb-hdrc.1.auto: STALLING ENDPOINT
| [   73.119760] musb-hdrc musb-hdrc.1.auto: aborting
| [   73.124827] musb-hdrc musb-hdrc.1.auto: complete cf65ab40 usb_api_blocking_completion+0x0/0x14 [usbcore] (-32), dev3 ep0out, 0/0
| [   73.196596] musb-hdrc musb-hdrc.1.auto: qh cccd5cc0 urb cf65ab40 dev3 ep0out, hw_ep 0, cf670240/8
| [   73.205967] musb-hdrc musb-hdrc.1.auto: --> hw0 urb cf65ab40 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
| [   73.215861] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf670240
| [   73.223736] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
| [   73.229329] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.235392] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.242544] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh cccd5cc0, count 0, urb cf65ab40, stage 1
| [   73.251970] musb-hdrc musb-hdrc.1.auto: start IN-DATA
| [   73.257396] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.263451] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.270598] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cccd5cc0, count 8, urb cf65ab40, stage 2
| [   73.280026] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf670280
| [   73.288035] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.294089] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.301237] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh cccd5cc0, count 8, urb cf65ab40, stage 2
| [   73.310663] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf670288
| [   73.318662] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.324716] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.331863] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cccd5cc0, count 8, urb cf65ab40, stage 2
| [   73.341290] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf670290
| [   73.349271] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.355324] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.362471] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh cccd5cc0, count 8, urb cf65ab40, stage 2
| [   73.371897] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf670298
| [   73.379877] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.385930] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.393077] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cccd5cc0, count 8, urb cf65ab40, stage 2
| [   73.402503] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf6702a0
| [   73.410545] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.416602] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.423750] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh cccd5cc0, count 8, urb cf65ab40, stage 2
| [   73.433176] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf6702a8
| [   73.441208] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.447263] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.454411] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cccd5cc0, count 4, urb cf65ab40, stage 2
| [   73.463838] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 4 buf cf6702b0
| [   73.471711] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
| [   73.477766] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   73.483819] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
| [   73.490966] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh cccd5cc0, count 0, urb cf65ab40, stage 4
| [   73.500603] musb-hdrc musb-hdrc.1.auto: complete cf65ab40 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 52/52
| [   73.621582] usbcore: registered new interface driver usbhid
| [   73.627765] usbhid: USB HID core driver
| [   73.673533] usbcore: registered new interface driver usbmouse
| [   73.745972] input: PixArt USB Optical Mouse as /devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb2/2-1/2-1:1.0/0003:17EF:602E.0001/input/input0
| [   73.772055] hid-generic 0003:17EF:602E.0001: input: USB HID v1.11 Mouse [PixArt USB Optical Mouse] on usb-musb-hdrc.1.auto-1/input0

Now I can use.

| [   78.548836] musb-hdrc musb-hdrc.1.auto: usbintr (20) epintr(0)

Disconnect came as soon as cable was disconnected. Host seems to be
behave well.

| [   78.555017] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0020 tx0000 rx0000
| [   78.562162] musb-hdrc musb-hdrc.1.auto: <== DevCtl=19, int_usb=0x20
| [   78.568761] musb-hdrc musb-hdrc.1.auto: DISCONNECT (a_host) as Host, devctl 19
| [   78.576429] musb-hdrc musb-hdrc.1.auto: a_wait_bcon inactive, starting idle timer for 1100 ms
| [   78.585610] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
| [   78.591477] musb-hdrc musb-hdrc.1.auto: port status 00010100
| [   78.608263] musb-hdrc musb-hdrc.1.auto: clear feature 16
| [   78.622870] usb usb2-port1: status 0100, change 0001, 12 Mb/s
| [   78.629228] usb 2-1: USB disconnect, device number 3
| [   78.634631] usb 2-1: unregistering device
| [   78.638863] usb 2-1: unregistering interface 2-1:1.0
| [   78.714884] usb 2-1: usb_disable_device nuking all URBs
| [   78.787528] musb-hdrc musb-hdrc.1.auto: port status 00000100
| [   78.841801] musb-hdrc musb-hdrc.1.auto: port status 00000100
| [   78.881889] musb-hdrc musb-hdrc.1.auto: port status 00000100
| [   78.921897] musb-hdrc musb-hdrc.1.auto: port status 00000100
| [   78.961891] musb-hdrc musb-hdrc.1.auto: port status 00000100
| [   78.968094] usb usb2-port1: debounce total 100ms stable 100ms status 0x100
| [   78.979923] hub 2-0:1.0: hub_suspend
| [   78.988603] usb usb2: bus auto-suspend, wakeup 1
| [   78.993864] musb-hdrc musb-hdrc.1.auto: Root port suspended, power e0
| [   79.000656] musb-hdrc musb-hdrc.1.auto: bogus rh suspend? a_wait_bcon

Looks like we shouldn't be in a_wait_bcon here, but that's minor.

| [   79.641702] musb-hdrc musb-hdrc.1.auto: Poll devctl 19 (a_wait_bcon)
| [   81.641698] musb-hdrc musb-hdrc.1.auto: Poll devctl 90 (a_idle)
| [   83.641708] musb-hdrc musb-hdrc.1.auto: Poll devctl 91 (b_idle)
| [   85.641700] musb-hdrc musb-hdrc.1.auto: Poll devctl 91 (b_idle)
| [   87.641679] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
| [   89.641685] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
| [   91.641705] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
| [   93.167339] musb-hdrc musb-hdrc.1.auto: usbintr (1) epintr(0)

Suspend IRQ. This really doesn't look correct, I'm connecting to my PC,
why do I get a Suspend IRQ ? I should get a RESET!!!

| [   93.173425] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0001 tx0000 rx0000
| [   93.181121] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x1
| [   93.187628] musb-hdrc musb-hdrc.1.auto: SUSPEND (b_idle) devctl 99
| [   93.291687] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   93.297771] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   93.305465] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   93.311972] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_idle

oh, it came later :-)

| [   93.317839] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   93.402227] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   93.408311] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   93.416009] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   93.423159] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   93.431037] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l64
| [   93.437909] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   93.444974] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
| [   93.452030] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
| [   93.459999] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
| [   93.467250] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   93.473304] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   93.480997] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
| [   93.488617] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   93.494668] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   93.502359] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   93.508864] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   93.515278] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   93.582191] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   93.588276] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   93.595974] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   93.603124] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   93.611001] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0003 i0000 l0
| [   93.617782] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
| [   93.625676] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   93.631734] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   93.639427] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
| [   93.647019] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   93.653073] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   93.660764] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   93.667270] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   93.673685] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   93.758996] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   93.765083] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   93.772778] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   93.779284] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   93.785700] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   93.970197] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   93.976283] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   93.983981] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   93.991132] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   93.999010] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l64
| [   94.005882] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   94.012948] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
| [   94.020004] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
| [   94.027973] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
| [   94.035217] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   94.041273] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   94.048964] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
| [   94.056586] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   94.062636] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   94.070327] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   94.076832] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   94.083246] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   94.202208] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   94.208296] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   94.215994] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   94.223144] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   94.231021] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0018 i0000 l0
| [   94.237801] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
| [   94.245587] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   94.251640] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   94.259332] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
| [   94.266861] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   94.272911] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   94.280603] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   94.287107] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   94.293522] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   94.782721] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   94.788806] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   94.796500] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   94.803005] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   94.809421] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   94.890213] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   94.896300] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   94.903998] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   94.911149] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   94.919026] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v001f i0000 l0
| [   94.925807] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
| [   94.933724] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   94.939782] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   94.947476] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
| [   95.070195] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   95.076280] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   95.083979] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage idle
| [   95.091038] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   95.098916] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l8
| [   95.105697] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   95.112762] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=8
| [   95.119727] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cccdcc00
| [   95.127604] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  8/8
| [   95.134681] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   95.140736] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   95.148429] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   95.156030] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   95.163905] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l18
| [   95.170775] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   95.177830] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
| [   95.184884] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
| [   95.192850] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
| [   95.200069] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   95.206123] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   95.213815] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   95.221416] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d30
| [   95.229291] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0200 i0000 l9
| [   95.236069] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   95.243131] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=9
| [   95.250094] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 9 buf cccdcc00
| [   95.257968] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  9/9
| [   95.264950] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   95.271000] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   95.278692] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   95.286293] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d30
| [   95.294168] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0200 i0000 l69
| [   95.301037] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   95.308094] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=69
| [   95.315146] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 64 buf cccdcc00
| [   95.323130] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   95.329180] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   95.336871] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in
| [   95.343741] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 5 buf cccdcc40
| [   95.351615] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  69/69
| [   95.358803] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   95.364855] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   95.372546] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   95.380146] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   95.388021] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0201 i0000 l9
| [   95.394799] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   95.401855] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=9
| [   95.408818] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 9 buf cccdcc00
| [   95.416692] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  9/9
| [   95.423692] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   95.429743] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   95.437435] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   95.445036] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   95.452911] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0201 i0000 l32
| [   95.459780] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   95.466836] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=32
| [   95.473889] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 32 buf cccdcc00
| [   95.481855] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  32/32
| [   95.489019] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   95.495069] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   95.502761] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   95.510361] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   95.518236] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0300 i0000 l255
| [   95.525196] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   95.532256] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=4
| [   95.539219] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 4 buf cccdcc00
| [   95.547094] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  4/4
| [   95.554074] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   95.560124] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   95.567816] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
| [   95.575416] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
| [   95.583291] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0302 i0409 l255
| [   95.590251] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   95.597311] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=24
| [   95.604365] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 24 buf cccdcc00
| [   95.612330] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  24/24
| [   95.619494] musb-hdrc musb-hdrc.1.auto: usbintr (1) epintr(1)
| [   95.625543] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0001 tx0001 rx0000
| [   95.633234] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x1
| [   95.639740] musb-hdrc musb-hdrc.1.auto: SUSPEND (b_peripheral) devctl 99
| [   95.646792] musb-hdrc musb-hdrc.1.auto: devctl 99
| [   95.651742] zero gadget: suspend
| [   95.655140] zero gadget: zero_suspend

Cable removed, got a suspend, not disconnect.

| [   95.659078] musb-hdrc musb-hdrc.1.auto: csr 000a, count 0, ep0stage out/status
| [   95.666705] musb-hdrc musb-hdrc.1.auto: Poll devctl 99 (b_peripheral)
| [   98.115605] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   98.121692] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   98.129387] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   98.135893] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   98.142308] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   98.226208] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   98.232294] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   98.239993] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   98.247144] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   98.255021] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l64
| [   98.261892] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   98.268958] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
| [   98.276014] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
| [   98.283983] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
| [   98.291233] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   98.297286] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   98.304979] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
| [   98.312599] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   98.318649] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   98.326341] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   98.332846] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   98.339261] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   98.458184] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   98.464269] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   98.471967] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   98.479117] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   98.486994] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0007 i0000 l0
| [   98.493773] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
| [   98.501558] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   98.507612] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   98.515304] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
| [   98.522835] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   98.528887] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   98.536578] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   98.543084] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   98.549499] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   98.631016] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   98.637103] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   98.644798] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   98.651304] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   98.657720] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   98.842197] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   98.848279] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   98.855977] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   98.863128] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   98.871006] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l64
| [   98.877878] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
| [   98.884943] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
| [   98.891998] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
| [   98.899967] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
| [   98.907214] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   98.913267] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   98.920960] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
| [   98.928580] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
| [   98.934630] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
| [   98.942321] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
| [   98.948826] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
| [   98.955240] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
| [   99.022183] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
| [   99.028268] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
| [   99.035965] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
| [   99.043116] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
| [   99.050993] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0017 i0000 l0
| [   99.057774] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
| [   99.068569] musb-hdrc musb-hdrc.1.auto: usbintr (1) epintr(0)
| [   99.074650] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0001 tx0000 rx0000
| [   99.082344] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x1
| [   99.088851] musb-hdrc musb-hdrc.1.auto: SUSPEND (b_peripheral) devctl 99
| [   99.095903] musb-hdrc musb-hdrc.1.auto: devctl 99
| [   99.100856] zero gadget: suspend
| [   99.104254] zero gadget: zero_suspend

cable removed.

| [  105.194553] musb-hdrc musb-hdrc.1.auto: usbintr (20) epintr(0)

Again 6 seconds to get Disconnect.

| [  105.200733] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0020 tx0000 rx0000
| [  105.208426] musb-hdrc musb-hdrc.1.auto: <== DevCtl=88, int_usb=0x20
| [  105.215026] musb-hdrc musb-hdrc.1.auto: DISCONNECT (b_peripheral) as Peripheral, devctl 88
| [  105.223721] musb-hdrc musb-hdrc.1.auto: devctl 88
| [  107.191676] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)

Any ideas ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150514/29629e98/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 19:49                                   ` Felipe Balbi
@ 2015-05-14 20:03                                     ` Bin Liu
  2015-05-14 20:10                                       ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Bin Liu @ 2015-05-14 20:03 UTC (permalink / raw)
  To: linux-arm-kernel

Felipe,

I can see the problem with 3.14.42 the current kernel I use right now.
See my other comments below.

On Thu, May 14, 2015 at 2:49 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Thu, May 14, 2015 at 02:29:46PM -0500, Felipe Balbi wrote:
>> > >> >> > Even in this case, when I connect the device on the other end of the
>> > >> >> > cable, I still see some 3 seconds delay from the time device is
>> > >> >> > connected, to the time connect IRQ fires up.
>> > >> >>
>> > >> >> seems to be a problem with the USB stick I'm using. Tested two other
>> > >> >> devices and they connect right away.
>> > >> >
>> > >> > ok, fixing DRD on AM335x will take longer than I originally expected,
>> > >> > probably won't be ready for v4.2 :-(
>> > >>
>> > >> Are you able replicate the issue with TI AM335x GP EVM? I am wondering
>> > >> if the is custom board design problem? have you checked the custom
>> > >> board schematics?
>> > >
>> > > don't have either AM335x GP EVM nor schematics for this board. But it's
>> > > certainly not a problem with the board. It's very easy to replicate the
>> > > problem:
>> > >
>> > > Set dr-mode to otg, load g_zero, connect to PC and as quickly as you
>> > > can, remove cable and attach otg cable with a mouse or whatever on the
>> > > other end.
>> > >
>> > > First time, mouse won't enumerate (no IRQs fire) remove and connect
>> > > again. You should see a Babble IRQ.
>> >
>> > And this only happens with 3.16+, not older kernels? I have a GP EVM,
>> > and can try to take a look.
>>
>> yeah, if you can try with v4.1-rc3, that'd be great. I also see that
>> disconnect IRQ takes a while to fire, but VBUS drops rather fast on this
>> board (< 10ms to discharge VBUS).
>
> Here are some logs:

[snip]

> | [   53.162507] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0001 tx0000 rx0000
> | [   53.170201] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x1
> | [   53.176709] musb-hdrc musb-hdrc.1.auto: SUSPEND (b_peripheral) devctl 99
> | [   53.183760] musb-hdrc musb-hdrc.1.auto: devctl 99
> | [   53.188713] zero gadget: suspend
> | [   53.192111] zero gadget: zero_suspend
>
> Gadget driver suspended
>
> | [   59.289314] musb-hdrc musb-hdrc.1.auto: usbintr (20) epintr(0)
>
> 6.09 seconds later we get Disconnect IRQ (???????????). No idea what's
> going on here. Why 6 seconds for Disconnect IRQ to fire ?

I believe the Disconnect IRQ was because MUSB is already confused at
this time when the ID pin is grounded before it transition to b_idle.

If I don't connect the mouse after disconnect MUSB from host, I saw it
took about 30 sec for MUSB to transition from b_peripheral to b_idle
which is not right. I think we need to figure out why it takes that
long. Once MUSB can quickly get to b_idle, it should handle connect to
host or device properly.

Regards,
-Bin.

>
> | [   59.295494] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0020 tx0000 rx0000
> | [   59.303187] musb-hdrc musb-hdrc.1.auto: <== DevCtl=88, int_usb=0x20
> | [   59.309786] musb-hdrc musb-hdrc.1.auto: DISCONNECT (b_peripheral) as Peripheral, devctl 88
> | [   59.318482] musb-hdrc musb-hdrc.1.auto: devctl 88
> | [   59.323439] zero gadget: reset config
> | [   59.327312] musb-hdrc musb-hdrc.1.auto: ep1in request cf70d6c0, 512/4096 fault -108
> | [   59.336523] musb-hdrc musb-hdrc.1.auto: ep1in
> | [   59.341133] musb-hdrc musb-hdrc.1.auto: ep1out request ccdab040, 0/4096 fault -108
> | [   59.349106] musb-hdrc musb-hdrc.1.auto: ep1out
>
> Disconnect IRQ handled. All outstanding requests given back, etc.
>
> | [   61.281706] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
>
> ID pin polling restarts
>
> | [   63.281681] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
>
> again
>
> | [   65.281681] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
>
> again
>
> | [   67.281681] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
>
> again
>
> | [   69.281682] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
>
> again
>
> | [   69.340437] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
>
> ID pin grounded (DRVVBUS changed due to ID going low)
>
> | [   69.346711] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
>
> VBUS goes on, a_wait_vrise
>
> | [   69.461549] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
>
> Connect IRQ. We're now HOST.
>
> | [   69.467726] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0010 tx0000 rx0000
> | [   69.474874] musb-hdrc musb-hdrc.1.auto: <== DevCtl=3d, int_usb=0x10
> | [   69.481531] musb-hdrc musb-hdrc.1.auto: CONNECT (a_host) devctl 3d
> | [   69.488158] usb usb2: usb wakeup-resume
> | [   69.492361] usb usb2: usb auto-resume
> | [   69.496228] musb-hdrc musb-hdrc.1.auto: root port reset stopped
> | [   69.502540] hub 2-0:1.0: hub_resume
> | [   69.506275] musb-hdrc musb-hdrc.1.auto: port status 00130303
> | [   69.544084] usb usb2-port1: status 0303 change 0013
> | [   69.549304] musb-hdrc musb-hdrc.1.auto: clear feature 1
> | [   69.559573] musb-hdrc musb-hdrc.1.auto: clear feature 16
> | [   69.569982] musb-hdrc musb-hdrc.1.auto: clear feature 17
> | [   69.580388] musb-hdrc musb-hdrc.1.auto: clear feature 20
> | [   69.691853] hub 2-0:1.0: state 7 ports 1 chg 0002 evt 0000
> | [   69.697734] musb-hdrc musb-hdrc.1.auto: port status 00000301
> | [   69.710670] usb usb2-port1: status 0301, change 0000, 1.5 Mb/s
> | [   69.717351] musb-hdrc musb-hdrc.1.auto: set feature 4
> | [   69.761823] musb-hdrc musb-hdrc.1.auto: root port reset stopped
> | [   69.769125] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   69.775185] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0004 tx0000 rx0000
> | [   69.782331] musb-hdrc musb-hdrc.1.auto: <== DevCtl=3d, int_usb=0x4
> | [   69.788835] musb-hdrc musb-hdrc.1.auto: Babble
> | [   69.793527] musb-hdrc musb-hdrc.1.auto: babble: MUSB_BABBLE_CTL value 44
> | [   69.800577] musb-hdrc musb-hdrc.1.auto: STUCK_J is reset
> | [   69.806269] musb-hdrc: setup fifo_mode 4
> | [   69.810413] musb-hdrc: 28/31 max ep, 16384/16384 memory
> | [   69.815915] musb-hdrc musb-hdrc.1.auto: <== devctl 98
> | [   69.821249] musb-hdrc musb-hdrc.1.auto: Longer idle timer already pending, ignoring...
> | [   69.829815] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(2)
> | [   69.835873] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0004 tx0002 rx0000
> | [   69.843015] musb-hdrc musb-hdrc.1.auto: <== DevCtl=91, int_usb=0x4
> | [   69.849519] musb-hdrc musb-hdrc.1.auto: BUS RESET as a_wait_bcon
> | [   69.855841] musb-hdrc musb-hdrc.1.auto: HNP: in a_wait_bcon, 1100 msec timeout
> | [   69.863450] musb-hdrc musb-hdrc.1.auto: extra TX1 ready, csr 0020
> | [   69.872017] musb-hdrc musb-hdrc.1.auto: port status 00010100
> | [   69.892140] musb-hdrc musb-hdrc.1.auto: clear feature 20
> | [   69.903680] musb-hdrc musb-hdrc.1.auto: clear feature 1
> | [   69.910942] musb-hdrc musb-hdrc.1.auto: clear feature 1
> | [   69.932876] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
> | [   69.939031] musb-hdrc musb-hdrc.1.auto: port status 00010100
> | [   69.962046] musb-hdrc musb-hdrc.1.auto: clear feature 16
> | [   69.973216] usb usb2-port1: status 0100, change 0001, 12 Mb/s
> | [   69.979790] musb-hdrc musb-hdrc.1.auto: port status 00000100
> | [   70.010452] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
> | [   70.016727] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
> | [   70.042019] musb-hdrc musb-hdrc.1.auto: port status 00000100
> | [   70.081874] musb-hdrc musb-hdrc.1.auto: port status 00000100
> | [   70.121890] musb-hdrc musb-hdrc.1.auto: port status 00000100
> | [   70.131541] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
> | [   70.137694] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0010 tx0000 rx0000
> | [   70.144839] musb-hdrc musb-hdrc.1.auto: <== DevCtl=3d, int_usb=0x10
> | [   70.151455] musb-hdrc musb-hdrc.1.auto: CONNECT (a_host) devctl 3d
> | [   70.163281] musb-hdrc musb-hdrc.1.auto: port status 00010301
> | [   70.169710] musb-hdrc musb-hdrc.1.auto: clear feature 16
> | [   70.221845] musb-hdrc musb-hdrc.1.auto: port status 00000301
> | [   70.261889] musb-hdrc musb-hdrc.1.auto: port status 00000301
> | [   70.301885] musb-hdrc musb-hdrc.1.auto: port status 00000301
> | [   70.341888] musb-hdrc musb-hdrc.1.auto: port status 00000301
> | [   70.348089] usb usb2-port1: debounce total 200ms stable 100ms status 0x301
> | [   70.355564] musb-hdrc musb-hdrc.1.auto: set feature 4
> | [   70.401782] musb-hdrc musb-hdrc.1.auto: root port reset stopped
> | [   70.421925] musb-hdrc musb-hdrc.1.auto: port status 00120303
> | [   70.481812] musb-hdrc musb-hdrc.1.auto: clear feature 20
> | [   70.487656] usb 2-1: new low-speed USB device number 3 using musb-hdrc
> | [   70.494695] musb-hdrc musb-hdrc.1.auto: qh ccde8cc0 urb ccdab040 dev0 ep0out, hw_ep 0, cf652340/8
> | [   70.504042] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev0 ep0out h_addr00 h_port00 bytes 8
> | [   70.513933] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf652340
> | [   70.521809] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   70.527255] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   70.533311] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   70.540461] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8cc0, count 0, urb ccdab040, stage 1
> | [   70.549886] musb-hdrc musb-hdrc.1.auto: start IN-DATA
> | [   70.555311] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   70.561363] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   70.568511] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8cc0, count 8, urb ccdab040, stage 2
> | [   70.577939] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cccdb040
> | [   70.585956] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   70.592012] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   70.599160] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8cc0, count 8, urb ccdab040, stage 2
> | [   70.608586] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cccdb048
> | [   70.616555] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   70.622609] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   70.629757] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8cc0, count 2, urb ccdab040, stage 2
> | [   70.639184] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 2 buf cccdb050
> | [   70.647056] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
> | [   70.653137] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   70.659190] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   70.666337] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh ccde8cc0, count 0, urb ccdab040, stage 4
> | [   70.675969] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev0 ep0in, 18/64
> | [   70.748464] musb-hdrc musb-hdrc.1.auto: set feature 4
> | [   70.791839] musb-hdrc musb-hdrc.1.auto: root port reset stopped
> | [   70.811925] musb-hdrc musb-hdrc.1.auto: port status 00120303
> | [   70.871811] musb-hdrc musb-hdrc.1.auto: clear feature 20
> | [   70.877702] musb-hdrc musb-hdrc.1.auto: qh ccde8cc0 urb ccdab040 dev0 ep0out, hw_ep 0, cccdb040/8
> | [   70.887051] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev0 ep0out h_addr00 h_port00 bytes 8
> | [   70.896943] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cccdb040
> | [   70.904818] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   70.910347] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   70.916408] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   70.923558] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8cc0, count 0, urb ccdab040, stage 1
> | [   70.932983] musb-hdrc musb-hdrc.1.auto: start no-DATA
> | [   70.938300] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0860
> | [   70.944365] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   70.950419] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   70.957566] musb-hdrc musb-hdrc.1.auto: <== csr0 0841, qh ccde8cc0, count 0, urb ccdab040, stage 4
> | [   70.967197] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev0 ep0out, 0/0
> | [   70.980094] musb-hdrc musb-hdrc.1.auto: HNP: Unhandled mode a_host
> | [   71.042069] musb-hdrc musb-hdrc.1.auto: qh ccde8ac0 urb ccdab040 dev3 ep0out, hw_ep 0, cf652340/8
> | [   71.051442] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
> | [   71.061345] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf652340
> | [   71.069220] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   71.074759] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.080821] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.087972] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8ac0, count 0, urb ccdab040, stage 1
> | [   71.097397] musb-hdrc musb-hdrc.1.auto: start IN-DATA
> | [   71.102825] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.108880] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.116029] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8ac0, count 8, urb ccdab040, stage 2
> | [   71.125458] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cccdb040
> | [   71.133461] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.139516] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.146664] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8ac0, count 8, urb ccdab040, stage 2
> | [   71.156090] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cccdb048
> | [   71.164055] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.170108] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.177255] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8ac0, count 2, urb ccdab040, stage 2
> | [   71.186680] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 2 buf cccdb050
> | [   71.194553] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
> | [   71.200600] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.206652] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.213798] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh ccde8ac0, count 0, urb ccdab040, stage 4
> | [   71.223428] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 18/18
> | [   71.304075] musb-hdrc musb-hdrc.1.auto: qh ccde8ac0 urb ccdab040 dev3 ep0out, hw_ep 0, cf571d80/8
> | [   71.313389] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
> | [   71.323222] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf571d80
> | [   71.331056] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   71.336615] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.342676] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.349827] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8ac0, count 0, urb ccdab040, stage 1
> | [   71.359252] musb-hdrc musb-hdrc.1.auto: start IN-DATA
> | [   71.364678] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.370733] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.377880] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8ac0, count 8, urb ccdab040, stage 2
> | [   71.387308] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf652340
> | [   71.395273] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.401327] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.408473] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8ac0, count 1, urb ccdab040, stage 2
> | [   71.417900] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 1 buf cf652348
> | [   71.425772] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
> | [   71.431817] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.437871] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.445018] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh ccde8ac0, count 0, urb ccdab040, stage 4
> | [   71.454647] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 9/9
> | [   71.521002] musb-hdrc musb-hdrc.1.auto: qh cf70d6c0 urb ccdab040 dev3 ep0out, hw_ep 0, cf621b00/8
> | [   71.530375] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
> | [   71.540268] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf621b00
> | [   71.548144] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   71.553738] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.559801] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.566953] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh cf70d6c0, count 0, urb ccdab040, stage 1
> | [   71.576378] musb-hdrc musb-hdrc.1.auto: start IN-DATA
> | [   71.581803] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.587855] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.595002] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cf70d6c0, count 8, urb ccdab040, stage 2
> | [   71.604430] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf571d80
> | [   71.612446] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.618503] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.625651] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh cf70d6c0, count 8, urb ccdab040, stage 2
> | [   71.635078] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf571d88
> | [   71.643083] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.649137] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.656284] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cf70d6c0, count 8, urb ccdab040, stage 2
> | [   71.665711] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf571d90
> | [   71.673691] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.679744] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.686891] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh cf70d6c0, count 8, urb ccdab040, stage 2
> | [   71.696317] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf571d98
> | [   71.704281] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.710333] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.717481] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cf70d6c0, count 2, urb ccdab040, stage 2
> | [   71.726907] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 2 buf cf571da0
> | [   71.734779] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
> | [   71.740821] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.746873] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.754020] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh cf70d6c0, count 0, urb ccdab040, stage 4
> | [   71.763646] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 34/34
> | [   71.857582] usb 2-1: skipped 1 descriptor after interface
> | [   71.863555] musb-hdrc musb-hdrc.1.auto: qh cf70d6c0 urb ccdab040 dev3 ep0out, hw_ep 0, cf652340/8
> | [   71.872903] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
> | [   71.882793] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf652340
> | [   71.890669] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   71.896237] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.902298] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.909448] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh cf70d6c0, count 0, urb ccdab040, stage 1
> | [   71.918873] musb-hdrc musb-hdrc.1.auto: start IN-DATA
> | [   71.924299] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.930352] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.937500] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cf70d6c0, count 4, urb ccdab040, stage 2
> | [   71.946928] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 4 buf ccc4c700
> | [   71.954802] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
> | [   71.960849] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   71.966902] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   71.974048] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh cf70d6c0, count 0, urb ccdab040, stage 4
> | [   71.983678] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 4/255
> | [   72.042307] usb 2-1: default language 0x0409
> | [   72.046898] musb-hdrc musb-hdrc.1.auto: qh ccde8cc0 urb ccdab040 dev3 ep0out, hw_ep 0, cf652340/8
> | [   72.056243] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
> | [   72.066134] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf652340
> | [   72.074009] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   72.079561] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.085622] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.092772] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8cc0, count 0, urb ccdab040, stage 1
> | [   72.102196] musb-hdrc musb-hdrc.1.auto: start IN-DATA
> | [   72.107624] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.113679] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.120826] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8cc0, count 8, urb ccdab040, stage 2
> | [   72.130255] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf ccc4c700
> | [   72.138240] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.144295] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.151441] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8cc0, count 8, urb ccdab040, stage 2
> | [   72.160866] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf ccc4c708
> | [   72.168848] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.174900] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.182047] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8cc0, count 8, urb ccdab040, stage 2
> | [   72.191473] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf ccc4c710
> | [   72.199471] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.205526] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.212673] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8cc0, count 8, urb ccdab040, stage 2
> | [   72.222100] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf ccc4c718
> | [   72.230065] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.236118] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.243265] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8cc0, count 4, urb ccdab040, stage 2
> | [   72.252691] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 4 buf ccc4c720
> | [   72.260563] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
> | [   72.266607] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.272659] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.279806] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh ccde8cc0, count 0, urb ccdab040, stage 4
> | [   72.289435] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 36/255
> | [   72.384380] musb-hdrc musb-hdrc.1.auto: qh ccde8ac0 urb ccdab040 dev3 ep0out, hw_ep 0, cf731e00/8
> | [   72.393752] musb-hdrc musb-hdrc.1.auto: --> hw0 urb ccdab040 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
> | [   72.403644] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf731e00
> | [   72.411520] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   72.417101] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.423162] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.430312] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8ac0, count 0, urb ccdab040, stage 1
> | [   72.439737] musb-hdrc musb-hdrc.1.auto: start IN-DATA
> | [   72.445222] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.451278] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.458426] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh ccde8ac0, count 8, urb ccdab040, stage 2
> | [   72.467854] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf ccc4c700
> | [   72.475825] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.481878] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.489025] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh ccde8ac0, count 6, urb ccdab040, stage 2
> | [   72.498451] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 6 buf ccc4c708
> | [   72.506323] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
> | [   72.512369] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.518422] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.525568] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh ccde8ac0, count 0, urb ccdab040, stage 4
> | [   72.535198] musb-hdrc musb-hdrc.1.auto: complete ccdab040 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 14/255
> | [   72.601553] usb 2-1: udev 3, busnum 2, minor = 130
> | [   72.606785] usb 2-1: New USB device found, idVendor=17ef, idProduct=602e
> | [   72.613929] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> | [   72.621442] usb 2-1: Product: USB Optical Mouse
> | [   72.626262] usb 2-1: Manufacturer: PixArt
> | [   72.650288] usb 2-1: usb_probe_device
> | [   72.654398] usb 2-1: configuration #1 chosen from 1 choice
>
> My mouse gets enumerated.
>
> | [   72.660309] musb-hdrc musb-hdrc.1.auto: qh ccde8ac0 urb cf70d6c0 dev3 ep0out, hw_ep 0, cf697040/8
> | [   72.669652] musb-hdrc musb-hdrc.1.auto: --> hw0 urb cf70d6c0 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
> | [   72.679544] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf697040
> | [   72.687420] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   72.692963] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.699023] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.706173] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh ccde8ac0, count 0, urb cf70d6c0, stage 1
> | [   72.715598] musb-hdrc musb-hdrc.1.auto: start no-DATA
> | [   72.720915] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0860
> | [   72.726977] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   72.733031] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   72.740178] musb-hdrc musb-hdrc.1.auto: <== csr0 0841, qh ccde8ac0, count 0, urb cf70d6c0, stage 4
> | [   72.749807] musb-hdrc musb-hdrc.1.auto: complete cf70d6c0 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0out, 0/0
> | [   72.823728] usb 2-1: adding 2-1:1.0 (config #1, interface 0)
> | [   72.845576] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
> | [   72.851998] musb-hdrc musb-hdrc.1.auto: port status 00020303
> | [   72.885276] usb usb2-port1: enable change, status 00000303
> | [   72.891142] musb-hdrc musb-hdrc.1.auto: clear feature 17
> | [   73.013128] usbhid 2-1:1.0: usb_probe_interface
> | [   73.017944] usbhid 2-1:1.0: usb_probe_interface - got id
> | [   73.024791] musb-hdrc musb-hdrc.1.auto: qh cf628240 urb cf65ab40 dev3 ep0out, hw_ep 0, cf670240/8
> | [   73.034152] musb-hdrc musb-hdrc.1.auto: --> hw0 urb cf65ab40 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
> | [   73.044058] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf670240
> | [   73.051934] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   73.057439] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.063501] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.070651] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh cf628240, count 0, urb cf65ab40, stage 1
> | [   73.080076] musb-hdrc musb-hdrc.1.auto: start no-DATA
> | [   73.085394] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0860
> | [   73.091454] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.097510] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.104657] musb-hdrc musb-hdrc.1.auto: <== csr0 0a44, qh cf628240, count 0, urb cf65ab40, stage 4
> | [   73.114080] musb-hdrc musb-hdrc.1.auto: STALLING ENDPOINT
> | [   73.119760] musb-hdrc musb-hdrc.1.auto: aborting
> | [   73.124827] musb-hdrc musb-hdrc.1.auto: complete cf65ab40 usb_api_blocking_completion+0x0/0x14 [usbcore] (-32), dev3 ep0out, 0/0
> | [   73.196596] musb-hdrc musb-hdrc.1.auto: qh cccd5cc0 urb cf65ab40 dev3 ep0out, hw_ep 0, cf670240/8
> | [   73.205967] musb-hdrc musb-hdrc.1.auto: --> hw0 urb cf65ab40 spd1 dev3 ep0out h_addr00 h_port00 bytes 8
> | [   73.215861] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cf670240
> | [   73.223736] musb-hdrc musb-hdrc.1.auto: Start TX0 pio
> | [   73.229329] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.235392] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.242544] musb-hdrc musb-hdrc.1.auto: <== csr0 0200, qh cccd5cc0, count 0, urb cf65ab40, stage 1
> | [   73.251970] musb-hdrc musb-hdrc.1.auto: start IN-DATA
> | [   73.257396] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.263451] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.270598] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cccd5cc0, count 8, urb cf65ab40, stage 2
> | [   73.280026] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf670280
> | [   73.288035] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.294089] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.301237] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh cccd5cc0, count 8, urb cf65ab40, stage 2
> | [   73.310663] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf670288
> | [   73.318662] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.324716] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.331863] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cccd5cc0, count 8, urb cf65ab40, stage 2
> | [   73.341290] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf670290
> | [   73.349271] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.355324] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.362471] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh cccd5cc0, count 8, urb cf65ab40, stage 2
> | [   73.371897] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf670298
> | [   73.379877] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.385930] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.393077] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cccd5cc0, count 8, urb cf65ab40, stage 2
> | [   73.402503] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf6702a0
> | [   73.410545] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.416602] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.423750] musb-hdrc musb-hdrc.1.auto: <== csr0 0201, qh cccd5cc0, count 8, urb cf65ab40, stage 2
> | [   73.433176] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf cf6702a8
> | [   73.441208] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.447263] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.454411] musb-hdrc musb-hdrc.1.auto: <== csr0 0001, qh cccd5cc0, count 4, urb cf65ab40, stage 2
> | [   73.463838] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 4 buf cf6702b0
> | [   73.471711] musb-hdrc musb-hdrc.1.auto: ep0 STATUS, csr 0842
> | [   73.477766] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   73.483819] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0000 tx0001 rx0000
> | [   73.490966] musb-hdrc musb-hdrc.1.auto: <== csr0 0800, qh cccd5cc0, count 0, urb cf65ab40, stage 4
> | [   73.500603] musb-hdrc musb-hdrc.1.auto: complete cf65ab40 usb_api_blocking_completion+0x0/0x14 [usbcore] (0), dev3 ep0in, 52/52
> | [   73.621582] usbcore: registered new interface driver usbhid
> | [   73.627765] usbhid: USB HID core driver
> | [   73.673533] usbcore: registered new interface driver usbmouse
> | [   73.745972] input: PixArt USB Optical Mouse as /devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb2/2-1/2-1:1.0/0003:17EF:602E.0001/input/input0
> | [   73.772055] hid-generic 0003:17EF:602E.0001: input: USB HID v1.11 Mouse [PixArt USB Optical Mouse] on usb-musb-hdrc.1.auto-1/input0
>
> Now I can use.
>
> | [   78.548836] musb-hdrc musb-hdrc.1.auto: usbintr (20) epintr(0)
>
> Disconnect came as soon as cable was disconnected. Host seems to be
> behave well.
>
> | [   78.555017] musb-hdrc musb-hdrc.1.auto: ** IRQ host usb0020 tx0000 rx0000
> | [   78.562162] musb-hdrc musb-hdrc.1.auto: <== DevCtl=19, int_usb=0x20
> | [   78.568761] musb-hdrc musb-hdrc.1.auto: DISCONNECT (a_host) as Host, devctl 19
> | [   78.576429] musb-hdrc musb-hdrc.1.auto: a_wait_bcon inactive, starting idle timer for 1100 ms
> | [   78.585610] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
> | [   78.591477] musb-hdrc musb-hdrc.1.auto: port status 00010100
> | [   78.608263] musb-hdrc musb-hdrc.1.auto: clear feature 16
> | [   78.622870] usb usb2-port1: status 0100, change 0001, 12 Mb/s
> | [   78.629228] usb 2-1: USB disconnect, device number 3
> | [   78.634631] usb 2-1: unregistering device
> | [   78.638863] usb 2-1: unregistering interface 2-1:1.0
> | [   78.714884] usb 2-1: usb_disable_device nuking all URBs
> | [   78.787528] musb-hdrc musb-hdrc.1.auto: port status 00000100
> | [   78.841801] musb-hdrc musb-hdrc.1.auto: port status 00000100
> | [   78.881889] musb-hdrc musb-hdrc.1.auto: port status 00000100
> | [   78.921897] musb-hdrc musb-hdrc.1.auto: port status 00000100
> | [   78.961891] musb-hdrc musb-hdrc.1.auto: port status 00000100
> | [   78.968094] usb usb2-port1: debounce total 100ms stable 100ms status 0x100
> | [   78.979923] hub 2-0:1.0: hub_suspend
> | [   78.988603] usb usb2: bus auto-suspend, wakeup 1
> | [   78.993864] musb-hdrc musb-hdrc.1.auto: Root port suspended, power e0
> | [   79.000656] musb-hdrc musb-hdrc.1.auto: bogus rh suspend? a_wait_bcon
>
> Looks like we shouldn't be in a_wait_bcon here, but that's minor.
>
> | [   79.641702] musb-hdrc musb-hdrc.1.auto: Poll devctl 19 (a_wait_bcon)
> | [   81.641698] musb-hdrc musb-hdrc.1.auto: Poll devctl 90 (a_idle)
> | [   83.641708] musb-hdrc musb-hdrc.1.auto: Poll devctl 91 (b_idle)
> | [   85.641700] musb-hdrc musb-hdrc.1.auto: Poll devctl 91 (b_idle)
> | [   87.641679] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
> | [   89.641685] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
> | [   91.641705] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
> | [   93.167339] musb-hdrc musb-hdrc.1.auto: usbintr (1) epintr(0)
>
> Suspend IRQ. This really doesn't look correct, I'm connecting to my PC,
> why do I get a Suspend IRQ ? I should get a RESET!!!
>
> | [   93.173425] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0001 tx0000 rx0000
> | [   93.181121] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x1
> | [   93.187628] musb-hdrc musb-hdrc.1.auto: SUSPEND (b_idle) devctl 99
> | [   93.291687] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   93.297771] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   93.305465] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   93.311972] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_idle
>
> oh, it came later :-)
>
> | [   93.317839] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   93.402227] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   93.408311] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   93.416009] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
> | [   93.423159] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   93.431037] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l64
> | [   93.437909] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   93.444974] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
> | [   93.452030] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
> | [   93.459999] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
> | [   93.467250] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   93.473304] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   93.480997] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
> | [   93.488617] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   93.494668] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   93.502359] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   93.508864] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   93.515278] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   93.582191] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   93.588276] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   93.595974] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
> | [   93.603124] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   93.611001] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0003 i0000 l0
> | [   93.617782] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
> | [   93.625676] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   93.631734] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   93.639427] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
> | [   93.647019] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   93.653073] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   93.660764] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   93.667270] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   93.673685] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   93.758996] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   93.765083] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   93.772778] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   93.779284] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   93.785700] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   93.970197] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   93.976283] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   93.983981] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
> | [   93.991132] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   93.999010] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l64
> | [   94.005882] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   94.012948] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
> | [   94.020004] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
> | [   94.027973] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
> | [   94.035217] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   94.041273] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   94.048964] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
> | [   94.056586] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   94.062636] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   94.070327] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   94.076832] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   94.083246] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   94.202208] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   94.208296] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   94.215994] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
> | [   94.223144] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   94.231021] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0018 i0000 l0
> | [   94.237801] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
> | [   94.245587] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   94.251640] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   94.259332] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
> | [   94.266861] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   94.272911] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   94.280603] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   94.287107] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   94.293522] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   94.782721] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   94.788806] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   94.796500] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   94.803005] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   94.809421] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   94.890213] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   94.896300] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   94.903998] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
> | [   94.911149] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   94.919026] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v001f i0000 l0
> | [   94.925807] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
> | [   94.933724] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   94.939782] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   94.947476] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
> | [   95.070195] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   95.076280] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   95.083979] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage idle
> | [   95.091038] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   95.098916] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l8
> | [   95.105697] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   95.112762] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=8
> | [   95.119727] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 8 buf cccdcc00
> | [   95.127604] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  8/8
> | [   95.134681] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   95.140736] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   95.148429] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
> | [   95.156030] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   95.163905] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l18
> | [   95.170775] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   95.177830] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
> | [   95.184884] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
> | [   95.192850] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
> | [   95.200069] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   95.206123] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   95.213815] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
> | [   95.221416] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d30
> | [   95.229291] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0200 i0000 l9
> | [   95.236069] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   95.243131] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=9
> | [   95.250094] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 9 buf cccdcc00
> | [   95.257968] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  9/9
> | [   95.264950] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   95.271000] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   95.278692] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
> | [   95.286293] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d30
> | [   95.294168] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0200 i0000 l69
> | [   95.301037] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   95.308094] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=69
> | [   95.315146] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 64 buf cccdcc00
> | [   95.323130] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   95.329180] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   95.336871] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in
> | [   95.343741] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 5 buf cccdcc40
> | [   95.351615] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  69/69
> | [   95.358803] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   95.364855] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   95.372546] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
> | [   95.380146] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   95.388021] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0201 i0000 l9
> | [   95.394799] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   95.401855] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=9
> | [   95.408818] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 9 buf cccdcc00
> | [   95.416692] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  9/9
> | [   95.423692] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   95.429743] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   95.437435] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
> | [   95.445036] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
> | [   95.452911] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0201 i0000 l32
> | [   95.459780] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   95.466836] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=32
> | [   95.473889] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 32 buf cccdcc00
> | [   95.481855] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  32/32
> | [   95.489019] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   95.495069] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   95.502761] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
> | [   95.510361] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
> | [   95.518236] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0300 i0000 l255
> | [   95.525196] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   95.532256] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=4
> | [   95.539219] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 4 buf cccdcc00
> | [   95.547094] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  4/4
> | [   95.554074] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   95.560124] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   95.567816] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage out/status
> | [   95.575416] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9d38
> | [   95.583291] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0302 i0409 l255
> | [   95.590251] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   95.597311] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=24
> | [   95.604365] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 24 buf cccdcc00
> | [   95.612330] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  24/24
> | [   95.619494] musb-hdrc musb-hdrc.1.auto: usbintr (1) epintr(1)
> | [   95.625543] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0001 tx0001 rx0000
> | [   95.633234] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x1
> | [   95.639740] musb-hdrc musb-hdrc.1.auto: SUSPEND (b_peripheral) devctl 99
> | [   95.646792] musb-hdrc musb-hdrc.1.auto: devctl 99
> | [   95.651742] zero gadget: suspend
> | [   95.655140] zero gadget: zero_suspend
>
> Cable removed, got a suspend, not disconnect.
>
> | [   95.659078] musb-hdrc musb-hdrc.1.auto: csr 000a, count 0, ep0stage out/status
> | [   95.666705] musb-hdrc musb-hdrc.1.auto: Poll devctl 99 (b_peripheral)
> | [   98.115605] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   98.121692] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   98.129387] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   98.135893] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   98.142308] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   98.226208] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   98.232294] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   98.239993] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
> | [   98.247144] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   98.255021] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l64
> | [   98.261892] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   98.268958] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
> | [   98.276014] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
> | [   98.283983] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
> | [   98.291233] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   98.297286] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   98.304979] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
> | [   98.312599] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   98.318649] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   98.326341] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   98.332846] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   98.339261] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   98.458184] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   98.464269] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   98.471967] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
> | [   98.479117] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   98.486994] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0007 i0000 l0
> | [   98.493773] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
> | [   98.501558] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   98.507612] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   98.515304] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage in/status
> | [   98.522835] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   98.528887] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   98.536578] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   98.543084] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   98.549499] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   98.631016] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   98.637103] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   98.644798] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   98.651304] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   98.657720] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   98.842197] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   98.848279] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   98.855977] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
> | [   98.863128] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   98.871006] musb-hdrc musb-hdrc.1.auto: SETUP req80.06 v0100 i0000 l64
> | [   98.877878] musb-hdrc musb-hdrc.1.auto: handled 0, csr 0001, ep0stage in
> | [   98.884943] musb-hdrc musb-hdrc.1.auto: queue to ep0 (OUT/RX), length=18
> | [   98.891998] musb-hdrc musb-hdrc.1.auto: TX ep0 fifo d1a82c20 count 18 buf cccdcc00
> | [   98.899967] musb-hdrc musb-hdrc.1.auto: ep0 done request ccdde140,  18/18
> | [   98.907214] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   98.913267] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   98.920960] musb-hdrc musb-hdrc.1.auto: csr 0000, count 0, ep0stage out/status
> | [   98.928580] musb-hdrc musb-hdrc.1.auto: usbintr (4) epintr(0)
> | [   98.934630] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0004 tx0000 rx0000
> | [   98.942321] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x4
> | [   98.948826] musb-hdrc musb-hdrc.1.auto: BUS RESET as b_peripheral
> | [   98.955240] musb-hdrc musb-hdrc.1.auto: <== B-Device driver 'zero'
> | [   99.022183] musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
> | [   99.028268] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0000 tx0001 rx0000
> | [   99.035965] musb-hdrc musb-hdrc.1.auto: csr 0001, count 8, ep0stage setup
> | [   99.043116] musb-hdrc musb-hdrc.1.auto: RX ep0 fifo d1a82c20 count 8 buf c08e9e00
> | [   99.050993] musb-hdrc musb-hdrc.1.auto: SETUP req00.05 v0017 i0000 l0
> | [   99.057774] musb-hdrc musb-hdrc.1.auto: handled 1, csr 0001, ep0stage in/status
> | [   99.068569] musb-hdrc musb-hdrc.1.auto: usbintr (1) epintr(0)
> | [   99.074650] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0001 tx0000 rx0000
> | [   99.082344] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x1
> | [   99.088851] musb-hdrc musb-hdrc.1.auto: SUSPEND (b_peripheral) devctl 99
> | [   99.095903] musb-hdrc musb-hdrc.1.auto: devctl 99
> | [   99.100856] zero gadget: suspend
> | [   99.104254] zero gadget: zero_suspend
>
> cable removed.
>
> | [  105.194553] musb-hdrc musb-hdrc.1.auto: usbintr (20) epintr(0)
>
> Again 6 seconds to get Disconnect.
>
> | [  105.200733] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0020 tx0000 rx0000
> | [  105.208426] musb-hdrc musb-hdrc.1.auto: <== DevCtl=88, int_usb=0x20
> | [  105.215026] musb-hdrc musb-hdrc.1.auto: DISCONNECT (b_peripheral) as Peripheral, devctl 88
> | [  105.223721] musb-hdrc musb-hdrc.1.auto: devctl 88
> | [  107.191676] musb-hdrc musb-hdrc.1.auto: Poll devctl 88 (b_idle)
>
> Any ideas ?
>
> --
> balbi

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 20:03                                     ` Bin Liu
@ 2015-05-14 20:10                                       ` Felipe Balbi
  0 siblings, 0 replies; 42+ messages in thread
From: Felipe Balbi @ 2015-05-14 20:10 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Thu, May 14, 2015 at 03:03:04PM -0500, Bin Liu wrote:
> Felipe,
> 
> I can see the problem with 3.14.42 the current kernel I use right now.
> See my other comments below.
> 
> On Thu, May 14, 2015 at 2:49 PM, Felipe Balbi <balbi@ti.com> wrote:
> > Hi,
> >
> > On Thu, May 14, 2015 at 02:29:46PM -0500, Felipe Balbi wrote:
> >> > >> >> > Even in this case, when I connect the device on the other end of the
> >> > >> >> > cable, I still see some 3 seconds delay from the time device is
> >> > >> >> > connected, to the time connect IRQ fires up.
> >> > >> >>
> >> > >> >> seems to be a problem with the USB stick I'm using. Tested two other
> >> > >> >> devices and they connect right away.
> >> > >> >
> >> > >> > ok, fixing DRD on AM335x will take longer than I originally expected,
> >> > >> > probably won't be ready for v4.2 :-(
> >> > >>
> >> > >> Are you able replicate the issue with TI AM335x GP EVM? I am wondering
> >> > >> if the is custom board design problem? have you checked the custom
> >> > >> board schematics?
> >> > >
> >> > > don't have either AM335x GP EVM nor schematics for this board. But it's
> >> > > certainly not a problem with the board. It's very easy to replicate the
> >> > > problem:
> >> > >
> >> > > Set dr-mode to otg, load g_zero, connect to PC and as quickly as you
> >> > > can, remove cable and attach otg cable with a mouse or whatever on the
> >> > > other end.
> >> > >
> >> > > First time, mouse won't enumerate (no IRQs fire) remove and connect
> >> > > again. You should see a Babble IRQ.
> >> >
> >> > And this only happens with 3.16+, not older kernels? I have a GP EVM,
> >> > and can try to take a look.
> >>
> >> yeah, if you can try with v4.1-rc3, that'd be great. I also see that
> >> disconnect IRQ takes a while to fire, but VBUS drops rather fast on this
> >> board (< 10ms to discharge VBUS).
> >
> > Here are some logs:
> 
> [snip]
> 
> > | [   53.162507] musb-hdrc musb-hdrc.1.auto: ** IRQ peripheral usb0001 tx0000 rx0000
> > | [   53.170201] musb-hdrc musb-hdrc.1.auto: <== DevCtl=99, int_usb=0x1
> > | [   53.176709] musb-hdrc musb-hdrc.1.auto: SUSPEND (b_peripheral) devctl 99
> > | [   53.183760] musb-hdrc musb-hdrc.1.auto: devctl 99
> > | [   53.188713] zero gadget: suspend
> > | [   53.192111] zero gadget: zero_suspend
> >
> > Gadget driver suspended
> >
> > | [   59.289314] musb-hdrc musb-hdrc.1.auto: usbintr (20) epintr(0)
> >
> > 6.09 seconds later we get Disconnect IRQ (???????????). No idea what's
> > going on here. Why 6 seconds for Disconnect IRQ to fire ?
> 
> I believe the Disconnect IRQ was because MUSB is already confused at
> this time when the ID pin is grounded before it transition to b_idle.
> 
> If I don't connect the mouse after disconnect MUSB from host, I saw it
> took about 30 sec for MUSB to transition from b_peripheral to b_idle
> which is not right. I think we need to figure out why it takes that
> long. Once MUSB can quickly get to b_idle, it should handle connect to
> host or device properly.

My feeling is that this won't be enough :-)

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150514/de3da5d4/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 19:29                                 ` Felipe Balbi
  2015-05-14 19:49                                   ` Felipe Balbi
@ 2015-05-14 21:04                                   ` Bin Liu
  2015-05-14 21:16                                     ` Bin Liu
  1 sibling, 1 reply; 42+ messages in thread
From: Bin Liu @ 2015-05-14 21:04 UTC (permalink / raw)
  To: linux-arm-kernel

Felipe,

On Thu, May 14, 2015 at 2:29 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Thu, May 14, 2015 at 02:29:20PM -0500, Bin Liu wrote:
>> On Thu, May 14, 2015 at 2:21 PM, Felipe Balbi <balbi@ti.com> wrote:
>> > On Thu, May 14, 2015 at 02:19:28PM -0500, Bin Liu wrote:
>> >> Felipe,
>> >>
>> >> On Thu, May 14, 2015 at 2:04 PM, Felipe Balbi <balbi@ti.com> wrote:
>> >> > On Thu, May 14, 2015 at 12:49:07PM -0500, Felipe Balbi wrote:
>> >> >> On Thu, May 14, 2015 at 12:40:31PM -0500, Felipe Balbi wrote:
>> >> >> > On Thu, May 14, 2015 at 12:07:00PM -0500, Felipe Balbi wrote:
>> >> >> > > Hi,
>> >> >> > >
>> >> >> > > On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote:
>> >> >> > > > On 25.02.2015 12:11, Maxime Ripard wrote:
>> >> >> > > > > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
>> >> >> > > > >> Hi,
>> >> >> > > > >>
>> >> >> > > > >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
>> >> >> > > > >>> Hi Felipe,
>> >> >> > > > >>>
>> >> >> > > > >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
>> >> >> > > > >>>> Hi,
>> >> >> > > > >>>>
>> >> >> > > > >>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
>> >> >> > > > >>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
>> >> >> > > > >>>>>> Hi,
>> >> >> > > > >>>>>>
>> >> >> > > > >>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
>> >> >> > > > >>>>>>> I have the same experience with 3.15. The switching is working when
>> >> >> > > > >>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
>> >> >> > > > >>
>> >> >> > > > >> since 3.16 ?
>> >> >> > > > >
>> >> >> > > > > That's what Yegor said. I never saw it working with 3.15 either.
>> >> >> > > >
>> >> >> > > > I've used 3.15.1 and 3.15.2 with this set of patches:
>> >> >> > > > https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15
>> >> >> > > >
>> >> >> > > > And it worked so far. The system:
>> >> >> > > > http://www.visionsystems.de/produkte/baltos-ir-5221.html
>> >> >> > >
>> >> >> > > I've had more time to look into this (thanks Yegor for sponsoring a
>> >> >> > > test/dev platform) what I noticed is that Connect IRQ takes seconds to
>> >> >> > > fire up.  Below a tiny log snippet after pluging USB OTG adapter cable
>> >> >> > > that came with IR5521:
>> >> >> > >
>> >> >> > > | [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
>> >> >> > >
>> >> >> > > Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ
>> >> >> > >
>> >> >> > > | [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
>> >> >> > >
>> >> >> > > MUSB starts to wait for VBUS to reach Session valid threshold
>> >> >> > >
>> >> >> > > | [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
>> >> >> > >
>> >> >> > > 3 seconds later connect interrupt happens. Looking at VBUS charge time
>> >> >> > > with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig
>> >> >> > > further into this.
>> >> >> >
>> >> >> > even more weird. If I disconnect device from OTG adapter, rather than
>> >> >> > OTG adapter from IR5521, this leave ID pin grounded, which means DRVVBUS
>> >> >> > is still asserted and VBUS remains above session valid threshold.
>> >> >> >
>> >> >> > Even in this case, when I connect the device on the other end of the
>> >> >> > cable, I still see some 3 seconds delay from the time device is
>> >> >> > connected, to the time connect IRQ fires up.
>> >> >>
>> >> >> seems to be a problem with the USB stick I'm using. Tested two other
>> >> >> devices and they connect right away.
>> >> >
>> >> > ok, fixing DRD on AM335x will take longer than I originally expected,
>> >> > probably won't be ready for v4.2 :-(
>> >>
>> >> Are you able replicate the issue with TI AM335x GP EVM? I am wondering
>> >> if the is custom board design problem? have you checked the custom
>> >> board schematics?
>> >
>> > don't have either AM335x GP EVM nor schematics for this board. But it's
>> > certainly not a problem with the board. It's very easy to replicate the
>> > problem:
>> >
>> > Set dr-mode to otg, load g_zero, connect to PC and as quickly as you
>> > can, remove cable and attach otg cable with a mouse or whatever on the
>> > other end.
>> >
>> > First time, mouse won't enumerate (no IRQs fire) remove and connect
>> > again. You should see a Babble IRQ.
>>
>> And this only happens with 3.16+, not older kernels? I have a GP EVM,
>> and can try to take a look.
>
> yeah, if you can try with v4.1-rc3, that'd be great. I also see that
> disconnect IRQ takes a while to fire, but VBUS drops rather fast on this
> board (< 10ms to discharge VBUS).

How low is VBUS after 10ms? I don't have a scope with me right now,
but I see Diconnect IRQ happened right away if I short VBUS to ground
right after disconnected from the host. So I suspect is that VBUS
discharge takes ~20sec on my board, which is the time taken for MUSB
from b_peripheral to b_idle.

BTY, it seems Disconnect IRQ is expected for MUSB in device mode. I
never pay attention on this.

Regards,
-Bin.

>
>> /me just figured out the modem issue, and in a very good mood now ;)
>
> hey, congrats :-)
>
> --
> balbi

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 21:04                                   ` Bin Liu
@ 2015-05-14 21:16                                     ` Bin Liu
  2015-05-14 21:26                                       ` Alexandre Belloni
  0 siblings, 1 reply; 42+ messages in thread
From: Bin Liu @ 2015-05-14 21:16 UTC (permalink / raw)
  To: linux-arm-kernel

Felipe,

On Thu, May 14, 2015 at 4:04 PM, Bin Liu <binmlist@gmail.com> wrote:
> Felipe,
>
> On Thu, May 14, 2015 at 2:29 PM, Felipe Balbi <balbi@ti.com> wrote:
>> On Thu, May 14, 2015 at 02:29:20PM -0500, Bin Liu wrote:
>>> On Thu, May 14, 2015 at 2:21 PM, Felipe Balbi <balbi@ti.com> wrote:
>>> > On Thu, May 14, 2015 at 02:19:28PM -0500, Bin Liu wrote:
>>> >> Felipe,
>>> >>
>>> >> On Thu, May 14, 2015 at 2:04 PM, Felipe Balbi <balbi@ti.com> wrote:
>>> >> > On Thu, May 14, 2015 at 12:49:07PM -0500, Felipe Balbi wrote:
>>> >> >> On Thu, May 14, 2015 at 12:40:31PM -0500, Felipe Balbi wrote:
>>> >> >> > On Thu, May 14, 2015 at 12:07:00PM -0500, Felipe Balbi wrote:
>>> >> >> > > Hi,
>>> >> >> > >
>>> >> >> > > On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote:
>>> >> >> > > > On 25.02.2015 12:11, Maxime Ripard wrote:
>>> >> >> > > > > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote:
>>> >> >> > > > >> Hi,
>>> >> >> > > > >>
>>> >> >> > > > >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote:
>>> >> >> > > > >>> Hi Felipe,
>>> >> >> > > > >>>
>>> >> >> > > > >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote:
>>> >> >> > > > >>>> Hi,
>>> >> >> > > > >>>>
>>> >> >> > > > >>>> On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:
>>> >> >> > > > >>>>> On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote:
>>> >> >> > > > >>>>>> Hi,
>>> >> >> > > > >>>>>>
>>> >> >> > > > >>>>>> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote:
>>> >> >> > > > >>>>>>> I have the same experience with 3.15. The switching is working when
>>> >> >> > > > >>>>>>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16
>>> >> >> > > > >>
>>> >> >> > > > >> since 3.16 ?
>>> >> >> > > > >
>>> >> >> > > > > That's what Yegor said. I never saw it working with 3.15 either.
>>> >> >> > > >
>>> >> >> > > > I've used 3.15.1 and 3.15.2 with this set of patches:
>>> >> >> > > > https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15
>>> >> >> > > >
>>> >> >> > > > And it worked so far. The system:
>>> >> >> > > > http://www.visionsystems.de/produkte/baltos-ir-5221.html
>>> >> >> > >
>>> >> >> > > I've had more time to look into this (thanks Yegor for sponsoring a
>>> >> >> > > test/dev platform) what I noticed is that Connect IRQ takes seconds to
>>> >> >> > > fire up.  Below a tiny log snippet after pluging USB OTG adapter cable
>>> >> >> > > that came with IR5521:
>>> >> >> > >
>>> >> >> > > | [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0)
>>> >> >> > >
>>> >> >> > > Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ
>>> >> >> > >
>>> >> >> > > | [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), devctl 19
>>> >> >> > >
>>> >> >> > > MUSB starts to wait for VBUS to reach Session valid threshold
>>> >> >> > >
>>> >> >> > > | [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0)
>>> >> >> > >
>>> >> >> > > 3 seconds later connect interrupt happens. Looking at VBUS charge time
>>> >> >> > > with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig
>>> >> >> > > further into this.
>>> >> >> >
>>> >> >> > even more weird. If I disconnect device from OTG adapter, rather than
>>> >> >> > OTG adapter from IR5521, this leave ID pin grounded, which means DRVVBUS
>>> >> >> > is still asserted and VBUS remains above session valid threshold.
>>> >> >> >
>>> >> >> > Even in this case, when I connect the device on the other end of the
>>> >> >> > cable, I still see some 3 seconds delay from the time device is
>>> >> >> > connected, to the time connect IRQ fires up.
>>> >> >>
>>> >> >> seems to be a problem with the USB stick I'm using. Tested two other
>>> >> >> devices and they connect right away.
>>> >> >
>>> >> > ok, fixing DRD on AM335x will take longer than I originally expected,
>>> >> > probably won't be ready for v4.2 :-(
>>> >>
>>> >> Are you able replicate the issue with TI AM335x GP EVM? I am wondering
>>> >> if the is custom board design problem? have you checked the custom
>>> >> board schematics?
>>> >
>>> > don't have either AM335x GP EVM nor schematics for this board. But it's
>>> > certainly not a problem with the board. It's very easy to replicate the
>>> > problem:
>>> >
>>> > Set dr-mode to otg, load g_zero, connect to PC and as quickly as you
>>> > can, remove cable and attach otg cable with a mouse or whatever on the
>>> > other end.
>>> >
>>> > First time, mouse won't enumerate (no IRQs fire) remove and connect
>>> > again. You should see a Babble IRQ.
>>>
>>> And this only happens with 3.16+, not older kernels? I have a GP EVM,
>>> and can try to take a look.
>>
>> yeah, if you can try with v4.1-rc3, that'd be great. I also see that
>> disconnect IRQ takes a while to fire, but VBUS drops rather fast on this
>> board (< 10ms to discharge VBUS).
>
> How low is VBUS after 10ms? I don't have a scope with me right now,
> but I see Diconnect IRQ happened right away if I short VBUS to ground
> right after disconnected from the host. So I suspect is that VBUS
> discharge takes ~20sec on my board, which is the time taken for MUSB
> from b_peripheral to b_idle.
>
> BTY, it seems Disconnect IRQ is expected for MUSB in device mode. I
> never pay attention on this.

I think I found the root cause of the problem: board design issue - I
bet the custom board has too much cap on VBUS line. It should be <
10uF.

I just noticed I have the Jumper 36 on on my EVM, which adds 154.7uF
cap on VBUS causing discharge takes ~20sec. After removed the jumper,
which leaves only 4.7uF cap on VBUS, now it only takes ~0.4sec to
generate Disconnect IRQ. Here is the log.

root@:~# [ 2504.893123] musb-hdrc musb-hdrc.0.auto: usbintr (1) epintr(0)
[ 2504.899198] musb-hdrc musb-hdrc.0.auto: <== DevCtl=99, int_usb=0x1
[ 2504.912751] zero gadget: suspend
[ 2504.916145] zero gadget: zero_suspend
[ 2505.303937] musb-hdrc musb-hdrc.0.auto: usbintr (20) epintr(0)
[ 2505.310072] musb-hdrc musb-hdrc.0.auto: <== DevCtl=88, int_usb=0x20
[ 2505.325355] zero gadget: reset config
[ 2507.303288] musb-hdrc musb-hdrc.0.auto: Poll devctl 80 (b_idle)

Regards,
-Bin.

>
> Regards,
> -Bin.
>
>>
>>> /me just figured out the modem issue, and in a very good mood now ;)
>>
>> hey, congrats :-)
>>
>> --
>> balbi

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 21:16                                     ` Bin Liu
@ 2015-05-14 21:26                                       ` Alexandre Belloni
  2015-05-14 21:36                                         ` Bin Liu
  0 siblings, 1 reply; 42+ messages in thread
From: Alexandre Belloni @ 2015-05-14 21:26 UTC (permalink / raw)
  To: linux-arm-kernel

On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
> I think I found the root cause of the problem: board design issue - I
> bet the custom board has too much cap on VBUS line. It should be <
> 10uF.
> 

We have a custom board that exhibits the issue but it only has a 100nF
cap on VBUS.

> I just noticed I have the Jumper 36 on on my EVM, which adds 154.7uF
> cap on VBUS causing discharge takes ~20sec. After removed the jumper,
> which leaves only 4.7uF cap on VBUS, now it only takes ~0.4sec to
> generate Disconnect IRQ. Here is the log.
> 
> root@:~# [ 2504.893123] musb-hdrc musb-hdrc.0.auto: usbintr (1) epintr(0)
> [ 2504.899198] musb-hdrc musb-hdrc.0.auto: <== DevCtl=99, int_usb=0x1
> [ 2504.912751] zero gadget: suspend
> [ 2504.916145] zero gadget: zero_suspend
> [ 2505.303937] musb-hdrc musb-hdrc.0.auto: usbintr (20) epintr(0)
> [ 2505.310072] musb-hdrc musb-hdrc.0.auto: <== DevCtl=88, int_usb=0x20
> [ 2505.325355] zero gadget: reset config
> [ 2507.303288] musb-hdrc musb-hdrc.0.auto: Poll devctl 80 (b_idle)
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 21:26                                       ` Alexandre Belloni
@ 2015-05-14 21:36                                         ` Bin Liu
  2015-05-26 14:51                                           ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Bin Liu @ 2015-05-14 21:36 UTC (permalink / raw)
  To: linux-arm-kernel

Alexandre,

On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
>> I think I found the root cause of the problem: board design issue - I
>> bet the custom board has too much cap on VBUS line. It should be <
>> 10uF.
>>
>
> We have a custom board that exhibits the issue but it only has a 100nF
> cap on VBUS.

Have you measured the VBUS discharging? Is there any way to share your
schematics?

Regards,
-Bin.

>
>> I just noticed I have the Jumper 36 on on my EVM, which adds 154.7uF
>> cap on VBUS causing discharge takes ~20sec. After removed the jumper,
>> which leaves only 4.7uF cap on VBUS, now it only takes ~0.4sec to
>> generate Disconnect IRQ. Here is the log.
>>
>> root@:~# [ 2504.893123] musb-hdrc musb-hdrc.0.auto: usbintr (1) epintr(0)
>> [ 2504.899198] musb-hdrc musb-hdrc.0.auto: <== DevCtl=99, int_usb=0x1
>> [ 2504.912751] zero gadget: suspend
>> [ 2504.916145] zero gadget: zero_suspend
>> [ 2505.303937] musb-hdrc musb-hdrc.0.auto: usbintr (20) epintr(0)
>> [ 2505.310072] musb-hdrc musb-hdrc.0.auto: <== DevCtl=88, int_usb=0x20
>> [ 2505.325355] zero gadget: reset config
>> [ 2507.303288] musb-hdrc musb-hdrc.0.auto: Poll devctl 80 (b_idle)
>>
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-14 21:36                                         ` Bin Liu
@ 2015-05-26 14:51                                           ` Felipe Balbi
  2015-05-27  9:42                                             ` Alexandre Belloni
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-05-26 14:51 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
> Alexandre,
> 
> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> > On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
> >> I think I found the root cause of the problem: board design issue - I
> >> bet the custom board has too much cap on VBUS line. It should be <
> >> 10uF.
> >>
> >
> > We have a custom board that exhibits the issue but it only has a 100nF
> > cap on VBUS.
> 
> Have you measured the VBUS discharging? Is there any way to share your
> schematics?

Alexandre, any further comments ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150526/3e70a928/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-26 14:51                                           ` Felipe Balbi
@ 2015-05-27  9:42                                             ` Alexandre Belloni
  2015-07-02  7:16                                               ` Gregory CLEMENT
  0 siblings, 1 reply; 42+ messages in thread
From: Alexandre Belloni @ 2015-05-27  9:42 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
> > Alexandre,
> > 
> > On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
> > <alexandre.belloni@free-electrons.com> wrote:
> > > On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
> > >> I think I found the root cause of the problem: board design issue - I
> > >> bet the custom board has too much cap on VBUS line. It should be <
> > >> 10uF.
> > >>
> > >
> > > We have a custom board that exhibits the issue but it only has a 100nF
> > > cap on VBUS.
> > 
> > Have you measured the VBUS discharging? Is there any way to share your
> > schematics?
> 
> Alexandre, any further comments ?
> 

Yeah, I have just got more info.

This is the relevant part of the schematic:
http://free-electrons.com/~alexandre/usb.png

The total VBUS capacitance is 200nF and the USB0 pins are connected
directly to the AM3358 pins. U1 is actually not fitted.

We didn't measure VBUS discharging but we observe the OTG pin sensing
stops when plugging an OTG cable without any device.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-05-27  9:42                                             ` Alexandre Belloni
@ 2015-07-02  7:16                                               ` Gregory CLEMENT
  2015-07-02 17:05                                                 ` Bin Liu
  0 siblings, 1 reply; 42+ messages in thread
From: Gregory CLEMENT @ 2015-07-02  7:16 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Felipe,

On 27/05/2015 11:42, Alexandre Belloni wrote:
> Hi,
> 
> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
>>> Alexandre,
>>>
>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
>>> <alexandre.belloni@free-electrons.com> wrote:
>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
>>>>> I think I found the root cause of the problem: board design issue - I
>>>>> bet the custom board has too much cap on VBUS line. It should be <
>>>>> 10uF.
>>>>>
>>>>
>>>> We have a custom board that exhibits the issue but it only has a 100nF
>>>> cap on VBUS.
>>>
>>> Have you measured the VBUS discharging? Is there any way to share your
>>> schematics?
>>
>> Alexandre, any further comments ?
>>
> 
> Yeah, I have just got more info.
> 
> This is the relevant part of the schematic:
> http://free-electrons.com/~alexandre/usb.png
> 
> The total VBUS capacitance is 200nF and the USB0 pins are connected
> directly to the AM3358 pins. U1 is actually not fitted.
> 
> We didn't measure VBUS discharging but we observe the OTG pin sensing
> stops when plugging an OTG cable without any device.

Do you have any news about this topic?


Is there something else that we can do to help solving this issue?


Thanks,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-07-02  7:16                                               ` Gregory CLEMENT
@ 2015-07-02 17:05                                                 ` Bin Liu
  2015-08-04 13:08                                                   ` Gregory CLEMENT
  0 siblings, 1 reply; 42+ messages in thread
From: Bin Liu @ 2015-07-02 17:05 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi Felipe,
>
> On 27/05/2015 11:42, Alexandre Belloni wrote:
>> Hi,
>>
>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
>>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
>>>> Alexandre,
>>>>
>>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
>>>> <alexandre.belloni@free-electrons.com> wrote:
>>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
>>>>>> I think I found the root cause of the problem: board design issue - I
>>>>>> bet the custom board has too much cap on VBUS line. It should be <
>>>>>> 10uF.
>>>>>>
>>>>>
>>>>> We have a custom board that exhibits the issue but it only has a 100nF
>>>>> cap on VBUS.
>>>>
>>>> Have you measured the VBUS discharging? Is there any way to share your
>>>> schematics?
>>>
>>> Alexandre, any further comments ?
>>>
>>
>> Yeah, I have just got more info.
>>
>> This is the relevant part of the schematic:
>> http://free-electrons.com/~alexandre/usb.png
>>
>> The total VBUS capacitance is 200nF and the USB0 pins are connected
>> directly to the AM3358 pins. U1 is actually not fitted.
>>
>> We didn't measure VBUS discharging but we observe the OTG pin sensing
>> stops when plugging an OTG cable without any device.
>
> Do you have any news about this topic?
>
>
> Is there something else that we can do to help solving this issue?

In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the
gadget driver configured? It has to be a module not built-in.

Regards,
-Bin.

>
>
> Thanks,
>
> Gregory
>
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-07-02 17:05                                                 ` Bin Liu
@ 2015-08-04 13:08                                                   ` Gregory CLEMENT
  2015-08-04 14:23                                                     ` Gregory CLEMENT
  0 siblings, 1 reply; 42+ messages in thread
From: Gregory CLEMENT @ 2015-08-04 13:08 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Bin,

On 02/07/2015 19:05, Bin Liu wrote:
> Hi,
> 
> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>> Hi Felipe,
>>
>> On 27/05/2015 11:42, Alexandre Belloni wrote:
>>> Hi,
>>>
>>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
>>>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
>>>>> Alexandre,
>>>>>
>>>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
>>>>> <alexandre.belloni@free-electrons.com> wrote:
>>>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
>>>>>>> I think I found the root cause of the problem: board design issue - I
>>>>>>> bet the custom board has too much cap on VBUS line. It should be <
>>>>>>> 10uF.
>>>>>>>
>>>>>>
>>>>>> We have a custom board that exhibits the issue but it only has a 100nF
>>>>>> cap on VBUS.
>>>>>
>>>>> Have you measured the VBUS discharging? Is there any way to share your
>>>>> schematics?
>>>>
>>>> Alexandre, any further comments ?
>>>>
>>>
>>> Yeah, I have just got more info.
>>>
>>> This is the relevant part of the schematic:
>>> http://free-electrons.com/~alexandre/usb.png
>>>
>>> The total VBUS capacitance is 200nF and the USB0 pins are connected
>>> directly to the AM3358 pins. U1 is actually not fitted.
>>>
>>> We didn't measure VBUS discharging but we observe the OTG pin sensing
>>> stops when plugging an OTG cable without any device.
>>
>> Do you have any news about this topic?
>>
>>
>> Is there something else that we can do to help solving this issue?
> 
> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the
> gadget driver configured? It has to be a module not built-in.

Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m
it worked seamless.


Thanks,

Gregory

> 
> Regards,
> -Bin.
> 
>>
>>
>> Thanks,
>>
>> Gregory
>>
>>
>> --
>> Gregory Clement, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-08-04 13:08                                                   ` Gregory CLEMENT
@ 2015-08-04 14:23                                                     ` Gregory CLEMENT
  2015-08-04 19:32                                                       ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Gregory CLEMENT @ 2015-08-04 14:23 UTC (permalink / raw)
  To: linux-arm-kernel

Hi again,
On 04/08/2015 15:08, Gregory CLEMENT wrote:
> Hi Bin,
> 
> On 02/07/2015 19:05, Bin Liu wrote:
>> Hi,
>>
>> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT
>> <gregory.clement@free-electrons.com> wrote:
>>> Hi Felipe,
>>>
>>> On 27/05/2015 11:42, Alexandre Belloni wrote:
>>>> Hi,
>>>>
>>>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
>>>>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
>>>>>> Alexandre,
>>>>>>
>>>>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
>>>>>> <alexandre.belloni@free-electrons.com> wrote:
>>>>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
>>>>>>>> I think I found the root cause of the problem: board design issue - I
>>>>>>>> bet the custom board has too much cap on VBUS line. It should be <
>>>>>>>> 10uF.
>>>>>>>>
>>>>>>>
>>>>>>> We have a custom board that exhibits the issue but it only has a 100nF
>>>>>>> cap on VBUS.
>>>>>>
>>>>>> Have you measured the VBUS discharging? Is there any way to share your
>>>>>> schematics?
>>>>>
>>>>> Alexandre, any further comments ?
>>>>>
>>>>
>>>> Yeah, I have just got more info.
>>>>
>>>> This is the relevant part of the schematic:
>>>> http://free-electrons.com/~alexandre/usb.png
>>>>
>>>> The total VBUS capacitance is 200nF and the USB0 pins are connected
>>>> directly to the AM3358 pins. U1 is actually not fitted.
>>>>
>>>> We didn't measure VBUS discharging but we observe the OTG pin sensing
>>>> stops when plugging an OTG cable without any device.
>>>
>>> Do you have any news about this topic?
>>>
>>>
>>> Is there something else that we can do to help solving this issue?
>>
>> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the
>> gadget driver configured? It has to be a module not built-in.
> 
> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m
> it worked seamless.
> 

Actually it didn't worked. And now sometimes I even received continuously
the following message:

 musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-08-04 14:23                                                     ` Gregory CLEMENT
@ 2015-08-04 19:32                                                       ` Felipe Balbi
  2015-08-18 12:36                                                         ` Gregory CLEMENT
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-08-04 19:32 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote:
> Hi again,
> On 04/08/2015 15:08, Gregory CLEMENT wrote:
> > Hi Bin,
> > 
> > On 02/07/2015 19:05, Bin Liu wrote:
> >> Hi,
> >>
> >> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT
> >> <gregory.clement@free-electrons.com> wrote:
> >>> Hi Felipe,
> >>>
> >>> On 27/05/2015 11:42, Alexandre Belloni wrote:
> >>>> Hi,
> >>>>
> >>>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
> >>>>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
> >>>>>> Alexandre,
> >>>>>>
> >>>>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
> >>>>>> <alexandre.belloni@free-electrons.com> wrote:
> >>>>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
> >>>>>>>> I think I found the root cause of the problem: board design issue - I
> >>>>>>>> bet the custom board has too much cap on VBUS line. It should be <
> >>>>>>>> 10uF.
> >>>>>>>>
> >>>>>>>
> >>>>>>> We have a custom board that exhibits the issue but it only has a 100nF
> >>>>>>> cap on VBUS.
> >>>>>>
> >>>>>> Have you measured the VBUS discharging? Is there any way to share your
> >>>>>> schematics?
> >>>>>
> >>>>> Alexandre, any further comments ?
> >>>>>
> >>>>
> >>>> Yeah, I have just got more info.
> >>>>
> >>>> This is the relevant part of the schematic:
> >>>> http://free-electrons.com/~alexandre/usb.png
> >>>>
> >>>> The total VBUS capacitance is 200nF and the USB0 pins are connected
> >>>> directly to the AM3358 pins. U1 is actually not fitted.
> >>>>
> >>>> We didn't measure VBUS discharging but we observe the OTG pin sensing
> >>>> stops when plugging an OTG cable without any device.
> >>>
> >>> Do you have any news about this topic?
> >>>
> >>>
> >>> Is there something else that we can do to help solving this issue?
> >>
> >> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the
> >> gadget driver configured? It has to be a module not built-in.
> > 
> > Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m
> > it worked seamless.
> > 
> 
> Actually it didn't worked. And now sometimes I even received continuously
> the following message:
> 
>  musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active

this is likely because your VBUS hasn't dropped below 0.8V fast enough.

I could only trigger this message in that situation. Use a scope to poke
at VBUS and see how long is takes to reach 0.8V, this could all be cause
by too much capacitance on VBUS line.

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150804/2369ce05/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-08-04 19:32                                                       ` Felipe Balbi
@ 2015-08-18 12:36                                                         ` Gregory CLEMENT
  2015-08-18 14:13                                                           ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Gregory CLEMENT @ 2015-08-18 12:36 UTC (permalink / raw)
  To: linux-arm-kernel

Hi again Felipe,

I sent this email again without the capture because it prevented to be delivered
to the mailing lists.

On 04/08/2015 21:32, Felipe Balbi wrote:
> On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote:
>> Hi again,
>> On 04/08/2015 15:08, Gregory CLEMENT wrote:
>>> Hi Bin,
>>>
>>> On 02/07/2015 19:05, Bin Liu wrote:
>>>> Hi,
>>>>
>>>> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT
>>>> <gregory.clement@free-electrons.com> wrote:
>>>>> Hi Felipe,
>>>>>
>>>>> On 27/05/2015 11:42, Alexandre Belloni wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
>>>>>>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
>>>>>>>> Alexandre,
>>>>>>>>
>>>>>>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
>>>>>>>> <alexandre.belloni@free-electrons.com> wrote:
>>>>>>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
>>>>>>>>>> I think I found the root cause of the problem: board design issue - I
>>>>>>>>>> bet the custom board has too much cap on VBUS line. It should be <
>>>>>>>>>> 10uF.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We have a custom board that exhibits the issue but it only has a 100nF
>>>>>>>>> cap on VBUS.
>>>>>>>>
>>>>>>>> Have you measured the VBUS discharging? Is there any way to share your
>>>>>>>> schematics?
>>>>>>>
>>>>>>> Alexandre, any further comments ?
>>>>>>>
>>>>>>
>>>>>> Yeah, I have just got more info.
>>>>>>
>>>>>> This is the relevant part of the schematic:
>>>>>> http://free-electrons.com/~alexandre/usb.png
>>>>>>
>>>>>> The total VBUS capacitance is 200nF and the USB0 pins are connected
>>>>>> directly to the AM3358 pins. U1 is actually not fitted.
>>>>>>
>>>>>> We didn't measure VBUS discharging but we observe the OTG pin sensing
>>>>>> stops when plugging an OTG cable without any device.
>>>>>
>>>>> Do you have any news about this topic?
>>>>>
>>>>>
>>>>> Is there something else that we can do to help solving this issue?
>>>>
>>>> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the
>>>> gadget driver configured? It has to be a module not built-in.
>>>
>>> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m
>>> it worked seamless.
>>>
>>
>> Actually it didn't worked. And now sometimes I even received continuously
>> the following message:
>>
>>  musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
> 
> this is likely because your VBUS hasn't dropped below 0.8V fast enough.
> 
> I could only trigger this message in that situation. Use a scope to poke
> at VBUS and see how long is takes to reach 0.8V, this could all be cause
> by too much capacitance on VBUS line.

We got some news:
"The capacitance on VBUS due to components is 200nF and the additional parasitic
capacitance will be much smaller than this"

The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter.
I attached a capture of this.

What do you think about these values?


However, "there appears to be a considerable delay between the removal of a usb
drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able
to measure this time)."

Thanks,

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-08-18 12:36                                                         ` Gregory CLEMENT
@ 2015-08-18 14:13                                                           ` Felipe Balbi
  2015-08-20 16:35                                                             ` Gregory CLEMENT
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-08-18 14:13 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote:
> Hi again Felipe,
> 
> I sent this email again without the capture because it prevented to be delivered
> to the mailing lists.
> 
> On 04/08/2015 21:32, Felipe Balbi wrote:
> > On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote:
> >> Hi again,
> >> On 04/08/2015 15:08, Gregory CLEMENT wrote:
> >>> Hi Bin,
> >>>
> >>> On 02/07/2015 19:05, Bin Liu wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT
> >>>> <gregory.clement@free-electrons.com> wrote:
> >>>>> Hi Felipe,
> >>>>>
> >>>>> On 27/05/2015 11:42, Alexandre Belloni wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
> >>>>>>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
> >>>>>>>> Alexandre,
> >>>>>>>>
> >>>>>>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
> >>>>>>>> <alexandre.belloni@free-electrons.com> wrote:
> >>>>>>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
> >>>>>>>>>> I think I found the root cause of the problem: board design issue - I
> >>>>>>>>>> bet the custom board has too much cap on VBUS line. It should be <
> >>>>>>>>>> 10uF.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> We have a custom board that exhibits the issue but it only has a 100nF
> >>>>>>>>> cap on VBUS.
> >>>>>>>>
> >>>>>>>> Have you measured the VBUS discharging? Is there any way to share your
> >>>>>>>> schematics?
> >>>>>>>
> >>>>>>> Alexandre, any further comments ?
> >>>>>>>
> >>>>>>
> >>>>>> Yeah, I have just got more info.
> >>>>>>
> >>>>>> This is the relevant part of the schematic:
> >>>>>> http://free-electrons.com/~alexandre/usb.png
> >>>>>>
> >>>>>> The total VBUS capacitance is 200nF and the USB0 pins are connected
> >>>>>> directly to the AM3358 pins. U1 is actually not fitted.
> >>>>>>
> >>>>>> We didn't measure VBUS discharging but we observe the OTG pin sensing
> >>>>>> stops when plugging an OTG cable without any device.
> >>>>>
> >>>>> Do you have any news about this topic?
> >>>>>
> >>>>>
> >>>>> Is there something else that we can do to help solving this issue?
> >>>>
> >>>> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the
> >>>> gadget driver configured? It has to be a module not built-in.
> >>>
> >>> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m
> >>> it worked seamless.
> >>>
> >>
> >> Actually it didn't worked. And now sometimes I even received continuously
> >> the following message:
> >>
> >>  musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
> > 
> > this is likely because your VBUS hasn't dropped below 0.8V fast enough.
> > 
> > I could only trigger this message in that situation. Use a scope to poke
> > at VBUS and see how long is takes to reach 0.8V, this could all be cause
> > by too much capacitance on VBUS line.
> 
> We got some news:
> "The capacitance on VBUS due to components is 200nF and the additional parasitic
> capacitance will be much smaller than this"
> 
> The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter.
> I attached a capture of this.
> 
> What do you think about these values?
> 
> 
> However, "there appears to be a considerable delay between the removal of a usb
> drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able
> to measure this time)."

yeah, this is really weird. I can't think of anything that would make
VBUS discharge slower from a SW point of view. Once you remove the
cable, VBUS is physically removed and there's nothing else charging it.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150818/9b51eeac/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-08-18 14:13                                                           ` Felipe Balbi
@ 2015-08-20 16:35                                                             ` Gregory CLEMENT
  2015-08-20 16:46                                                               ` Felipe Balbi
  0 siblings, 1 reply; 42+ messages in thread
From: Gregory CLEMENT @ 2015-08-20 16:35 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Felipe,

On 18/08/2015 16:13, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote:
>> Hi again Felipe,
>>
>> I sent this email again without the capture because it prevented to be delivered
>> to the mailing lists.
>>
>> On 04/08/2015 21:32, Felipe Balbi wrote:
>>> On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote:
>>>> Hi again,
>>>> On 04/08/2015 15:08, Gregory CLEMENT wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 02/07/2015 19:05, Bin Liu wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT
>>>>>> <gregory.clement@free-electrons.com> wrote:
>>>>>>> Hi Felipe,
>>>>>>>
>>>>>>> On 27/05/2015 11:42, Alexandre Belloni wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
>>>>>>>>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
>>>>>>>>>> Alexandre,
>>>>>>>>>>
>>>>>>>>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
>>>>>>>>>> <alexandre.belloni@free-electrons.com> wrote:
>>>>>>>>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
>>>>>>>>>>>> I think I found the root cause of the problem: board design issue - I
>>>>>>>>>>>> bet the custom board has too much cap on VBUS line. It should be <
>>>>>>>>>>>> 10uF.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We have a custom board that exhibits the issue but it only has a 100nF
>>>>>>>>>>> cap on VBUS.
>>>>>>>>>>
>>>>>>>>>> Have you measured the VBUS discharging? Is there any way to share your
>>>>>>>>>> schematics?
>>>>>>>>>
>>>>>>>>> Alexandre, any further comments ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yeah, I have just got more info.
>>>>>>>>
>>>>>>>> This is the relevant part of the schematic:
>>>>>>>> http://free-electrons.com/~alexandre/usb.png
>>>>>>>>
>>>>>>>> The total VBUS capacitance is 200nF and the USB0 pins are connected
>>>>>>>> directly to the AM3358 pins. U1 is actually not fitted.
>>>>>>>>
>>>>>>>> We didn't measure VBUS discharging but we observe the OTG pin sensing
>>>>>>>> stops when plugging an OTG cable without any device.
>>>>>>>
>>>>>>> Do you have any news about this topic?
>>>>>>>
>>>>>>>
>>>>>>> Is there something else that we can do to help solving this issue?
>>>>>>
>>>>>> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the
>>>>>> gadget driver configured? It has to be a module not built-in.
>>>>>
>>>>> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m
>>>>> it worked seamless.
>>>>>
>>>>
>>>> Actually it didn't worked. And now sometimes I even received continuously
>>>> the following message:
>>>>
>>>>  musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
>>>
>>> this is likely because your VBUS hasn't dropped below 0.8V fast enough.
>>>
>>> I could only trigger this message in that situation. Use a scope to poke
>>> at VBUS and see how long is takes to reach 0.8V, this could all be cause
>>> by too much capacitance on VBUS line.
>>
>> We got some news:
>> "The capacitance on VBUS due to components is 200nF and the additional parasitic
>> capacitance will be much smaller than this"
>>
>> The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter.
>> I attached a capture of this.
>>
>> What do you think about these values?
>>
>>
>> However, "there appears to be a considerable delay between the removal of a usb
>> drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able
>> to measure this time)."
> 
> yeah, this is really weird. I can't think of anything that would make
> VBUS discharge slower from a SW point of view. Once you remove the
> cable, VBUS is physically removed and there's nothing else charging it.

I have more feedback about it: "When I look at it on the oscilloscope
this isn't a 'slow discharge' like a slowly draining capacitor, it is
a delay between the removal of a device and the initiation of the
discharge.  The discharge itself is quite fast once it begins, it just
seems as if the SOC/driver is taking a long time to notice the cable
is disconnected. At this stage, this isn't actually a problem, just
odd."

While working on this issue we found that the
tg_state_a_wait_vrise_timeout case seemed not managed by musb_dsps
driver. I've just submitted a patch for it:
https://lkml.org/lkml/2015/8/20/507

I made most of my test on a 3.17 kernel and today by using a 4.1
kernel with the patch I have submitted I didn't manage to reproduce
the issue. I saw that since 3.17, there were some patches related to
the babble interrupts; so maybe it was enough to fix the issue we saw.
It is still weird because one month ago I also tested with a 4.1
kernel and I had issues...

It needs more testing to see if it is really fixed because the issue
comes only time to time. I will keep you inform about our last tests.


Thanks,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-08-20 16:35                                                             ` Gregory CLEMENT
@ 2015-08-20 16:46                                                               ` Felipe Balbi
  2015-08-21 12:19                                                                 ` Gregory CLEMENT
  0 siblings, 1 reply; 42+ messages in thread
From: Felipe Balbi @ 2015-08-20 16:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Aug 20, 2015 at 06:35:17PM +0200, Gregory CLEMENT wrote:
> Hi Felipe,
> 
> On 18/08/2015 16:13, Felipe Balbi wrote:
> > Hi,
> > 
> > On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote:
> >> Hi again Felipe,
> >>
> >> I sent this email again without the capture because it prevented to be delivered
> >> to the mailing lists.
> >>
> >> On 04/08/2015 21:32, Felipe Balbi wrote:
> >>> On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote:
> >>>> Hi again,
> >>>> On 04/08/2015 15:08, Gregory CLEMENT wrote:
> >>>>> Hi Bin,
> >>>>>
> >>>>> On 02/07/2015 19:05, Bin Liu wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT
> >>>>>> <gregory.clement@free-electrons.com> wrote:
> >>>>>>> Hi Felipe,
> >>>>>>>
> >>>>>>> On 27/05/2015 11:42, Alexandre Belloni wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
> >>>>>>>>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
> >>>>>>>>>> Alexandre,
> >>>>>>>>>>
> >>>>>>>>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
> >>>>>>>>>> <alexandre.belloni@free-electrons.com> wrote:
> >>>>>>>>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
> >>>>>>>>>>>> I think I found the root cause of the problem: board design issue - I
> >>>>>>>>>>>> bet the custom board has too much cap on VBUS line. It should be <
> >>>>>>>>>>>> 10uF.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> We have a custom board that exhibits the issue but it only has a 100nF
> >>>>>>>>>>> cap on VBUS.
> >>>>>>>>>>
> >>>>>>>>>> Have you measured the VBUS discharging? Is there any way to share your
> >>>>>>>>>> schematics?
> >>>>>>>>>
> >>>>>>>>> Alexandre, any further comments ?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Yeah, I have just got more info.
> >>>>>>>>
> >>>>>>>> This is the relevant part of the schematic:
> >>>>>>>> http://free-electrons.com/~alexandre/usb.png
> >>>>>>>>
> >>>>>>>> The total VBUS capacitance is 200nF and the USB0 pins are connected
> >>>>>>>> directly to the AM3358 pins. U1 is actually not fitted.
> >>>>>>>>
> >>>>>>>> We didn't measure VBUS discharging but we observe the OTG pin sensing
> >>>>>>>> stops when plugging an OTG cable without any device.
> >>>>>>>
> >>>>>>> Do you have any news about this topic?
> >>>>>>>
> >>>>>>>
> >>>>>>> Is there something else that we can do to help solving this issue?
> >>>>>>
> >>>>>> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the
> >>>>>> gadget driver configured? It has to be a module not built-in.
> >>>>>
> >>>>> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m
> >>>>> it worked seamless.
> >>>>>
> >>>>
> >>>> Actually it didn't worked. And now sometimes I even received continuously
> >>>> the following message:
> >>>>
> >>>>  musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
> >>>
> >>> this is likely because your VBUS hasn't dropped below 0.8V fast enough.
> >>>
> >>> I could only trigger this message in that situation. Use a scope to poke
> >>> at VBUS and see how long is takes to reach 0.8V, this could all be cause
> >>> by too much capacitance on VBUS line.
> >>
> >> We got some news:
> >> "The capacitance on VBUS due to components is 200nF and the additional parasitic
> >> capacitance will be much smaller than this"
> >>
> >> The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter.
> >> I attached a capture of this.
> >>
> >> What do you think about these values?
> >>
> >>
> >> However, "there appears to be a considerable delay between the removal of a usb
> >> drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able
> >> to measure this time)."
> > 
> > yeah, this is really weird. I can't think of anything that would make
> > VBUS discharge slower from a SW point of view. Once you remove the
> > cable, VBUS is physically removed and there's nothing else charging it.
> 
> I have more feedback about it: "When I look at it on the oscilloscope
> this isn't a 'slow discharge' like a slowly draining capacitor, it is
> a delay between the removal of a device and the initiation of the
> discharge.  The discharge itself is quite fast once it begins, it just
> seems as if the SOC/driver is taking a long time to notice the cable
> is disconnected. At this stage, this isn't actually a problem, just
> odd."
> 
> While working on this issue we found that the
> tg_state_a_wait_vrise_timeout case seemed not managed by musb_dsps
> driver. I've just submitted a patch for it:
> https://lkml.org/lkml/2015/8/20/507

cool, I'll test it next week. Good finding btw.

> I made most of my test on a 3.17 kernel and today by using a 4.1
> kernel with the patch I have submitted I didn't manage to reproduce
> the issue. I saw that since 3.17, there were some patches related to
> the babble interrupts; so maybe it was enough to fix the issue we saw.
> It is still weird because one month ago I also tested with a 4.1
> kernel and I had issues...
> 
> It needs more testing to see if it is really fixed because the issue
> comes only time to time. I will keep you inform about our last tests.

all right. Seems like we really need to turn some of those states
handling into a reusable (musb-specific) library.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150820/dcebba1f/attachment.sig>

^ permalink raw reply	[flat|nested] 42+ messages in thread

* MUSB dual-role on AM335x behaving weirdly
  2015-08-20 16:46                                                               ` Felipe Balbi
@ 2015-08-21 12:19                                                                 ` Gregory CLEMENT
  0 siblings, 0 replies; 42+ messages in thread
From: Gregory CLEMENT @ 2015-08-21 12:19 UTC (permalink / raw)
  To: linux-arm-kernel

On 20/08/2015 18:46, Felipe Balbi wrote:
> On Thu, Aug 20, 2015 at 06:35:17PM +0200, Gregory CLEMENT wrote:
>> Hi Felipe,
>>
>> On 18/08/2015 16:13, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote:
>>>> Hi again Felipe,
>>>>
>>>> I sent this email again without the capture because it prevented to be delivered
>>>> to the mailing lists.
>>>>
>>>> On 04/08/2015 21:32, Felipe Balbi wrote:
>>>>> On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote:
>>>>>> Hi again,
>>>>>> On 04/08/2015 15:08, Gregory CLEMENT wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> On 02/07/2015 19:05, Bin Liu wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT
>>>>>>>> <gregory.clement@free-electrons.com> wrote:
>>>>>>>>> Hi Felipe,
>>>>>>>>>
>>>>>>>>> On 27/05/2015 11:42, Alexandre Belloni wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote :
>>>>>>>>>>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote:
>>>>>>>>>>>> Alexandre,
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni
>>>>>>>>>>>> <alexandre.belloni@free-electrons.com> wrote:
>>>>>>>>>>>>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote :
>>>>>>>>>>>>>> I think I found the root cause of the problem: board design issue - I
>>>>>>>>>>>>>> bet the custom board has too much cap on VBUS line. It should be <
>>>>>>>>>>>>>> 10uF.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We have a custom board that exhibits the issue but it only has a 100nF
>>>>>>>>>>>>> cap on VBUS.
>>>>>>>>>>>>
>>>>>>>>>>>> Have you measured the VBUS discharging? Is there any way to share your
>>>>>>>>>>>> schematics?
>>>>>>>>>>>
>>>>>>>>>>> Alexandre, any further comments ?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yeah, I have just got more info.
>>>>>>>>>>
>>>>>>>>>> This is the relevant part of the schematic:
>>>>>>>>>> http://free-electrons.com/~alexandre/usb.png
>>>>>>>>>>
>>>>>>>>>> The total VBUS capacitance is 200nF and the USB0 pins are connected
>>>>>>>>>> directly to the AM3358 pins. U1 is actually not fitted.
>>>>>>>>>>
>>>>>>>>>> We didn't measure VBUS discharging but we observe the OTG pin sensing
>>>>>>>>>> stops when plugging an OTG cable without any device.
>>>>>>>>>
>>>>>>>>> Do you have any news about this topic?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is there something else that we can do to help solving this issue?
>>>>>>>>
>>>>>>>> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the
>>>>>>>> gadget driver configured? It has to be a module not built-in.
>>>>>>>
>>>>>>> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m
>>>>>>> it worked seamless.
>>>>>>>
>>>>>>
>>>>>> Actually it didn't worked. And now sometimes I even received continuously
>>>>>> the following message:
>>>>>>
>>>>>>  musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active
>>>>>
>>>>> this is likely because your VBUS hasn't dropped below 0.8V fast enough.
>>>>>
>>>>> I could only trigger this message in that situation. Use a scope to poke
>>>>> at VBUS and see how long is takes to reach 0.8V, this could all be cause
>>>>> by too much capacitance on VBUS line.
>>>>
>>>> We got some news:
>>>> "The capacitance on VBUS due to components is 200nF and the additional parasitic
>>>> capacitance will be much smaller than this"
>>>>
>>>> The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter.
>>>> I attached a capture of this.
>>>>
>>>> What do you think about these values?
>>>>
>>>>
>>>> However, "there appears to be a considerable delay between the removal of a usb
>>>> drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able
>>>> to measure this time)."
>>>
>>> yeah, this is really weird. I can't think of anything that would make
>>> VBUS discharge slower from a SW point of view. Once you remove the
>>> cable, VBUS is physically removed and there's nothing else charging it.
>>
>> I have more feedback about it: "When I look at it on the oscilloscope
>> this isn't a 'slow discharge' like a slowly draining capacitor, it is
>> a delay between the removal of a device and the initiation of the
>> discharge.  The discharge itself is quite fast once it begins, it just
>> seems as if the SOC/driver is taking a long time to notice the cable
>> is disconnected. At this stage, this isn't actually a problem, just
>> odd."
>>
>> While working on this issue we found that the
>> tg_state_a_wait_vrise_timeout case seemed not managed by musb_dsps
>> driver. I've just submitted a patch for it:
>> https://lkml.org/lkml/2015/8/20/507
> 
> cool, I'll test it next week. Good finding btw.

Thanks, however it seemed already needs to be amended.

> 
>> I made most of my test on a 3.17 kernel and today by using a 4.1
>> kernel with the patch I have submitted I didn't manage to reproduce
>> the issue. I saw that since 3.17, there were some patches related to
>> the babble interrupts; so maybe it was enough to fix the issue we saw.
>> It is still weird because one month ago I also tested with a 4.1
>> kernel and I had issues...
>>
>> It needs more testing to see if it is really fixed because the issue
>> comes only time to time. I will keep you inform about our last tests.
> 
> all right. Seems like we really need to turn some of those states
> handling into a reusable (musb-specific) library.


There is something in drivers/usb/common/usb-otg-fsm.c. First I thought it
was handle until I realized that this file was nit used at all for musb
driver.

Thanks,

Gregory



-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2015-08-21 12:19 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-21 16:06 MUSB dual-role on AM335x behaving weirdly Maxime Ripard
2015-01-21 18:53 ` Bin Liu
2015-01-22  7:37   ` Yegor Yefremov
2015-01-22 10:43     ` Maxime Ripard
2015-01-22 11:01       ` Markus Pargmann
2015-01-22 14:00         ` Maxime Ripard
2015-01-22 14:52           ` Bin Liu
2015-02-05 13:21     ` Maxime Ripard
2015-02-24 10:39       ` Maxime Ripard
2015-02-24 14:54         ` Felipe Balbi
2015-02-24 16:50           ` Maxime Ripard
2015-02-24 17:33             ` Felipe Balbi
2015-02-25 11:11               ` Maxime Ripard
2015-02-25 12:11                 ` Yegor Yefremov
2015-05-14 17:07                   ` Felipe Balbi
2015-05-14 17:40                     ` Felipe Balbi
2015-05-14 17:49                       ` Felipe Balbi
2015-05-14 19:04                         ` Felipe Balbi
2015-05-14 19:19                           ` Bin Liu
2015-05-14 19:21                             ` Felipe Balbi
2015-05-14 19:29                               ` Bin Liu
2015-05-14 19:29                                 ` Felipe Balbi
2015-05-14 19:49                                   ` Felipe Balbi
2015-05-14 20:03                                     ` Bin Liu
2015-05-14 20:10                                       ` Felipe Balbi
2015-05-14 21:04                                   ` Bin Liu
2015-05-14 21:16                                     ` Bin Liu
2015-05-14 21:26                                       ` Alexandre Belloni
2015-05-14 21:36                                         ` Bin Liu
2015-05-26 14:51                                           ` Felipe Balbi
2015-05-27  9:42                                             ` Alexandre Belloni
2015-07-02  7:16                                               ` Gregory CLEMENT
2015-07-02 17:05                                                 ` Bin Liu
2015-08-04 13:08                                                   ` Gregory CLEMENT
2015-08-04 14:23                                                     ` Gregory CLEMENT
2015-08-04 19:32                                                       ` Felipe Balbi
2015-08-18 12:36                                                         ` Gregory CLEMENT
2015-08-18 14:13                                                           ` Felipe Balbi
2015-08-20 16:35                                                             ` Gregory CLEMENT
2015-08-20 16:46                                                               ` Felipe Balbi
2015-08-21 12:19                                                                 ` Gregory CLEMENT
2015-04-14 15:46       ` Maxime Ripard

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.