MUSB dual-role on AM335x behaving weirdly

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

Hi,

Quoted 33 lines · Maxime Ripard

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.

Quoted 1 line

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

Quoted 43 lines · Bin Liu

Hi,

Quoted 26 lines · Maxime Ripard

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.

Quoted 8 lines

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.

Quoted 2 lines

[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.

Hi Yegor,

Quoted 44 lines · Yegor Yefremov

Quoted 43 lines · Bin Liu

Hi,

Quoted 26 lines · Maxime Ripard

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.

Quoted 8 lines

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.

Quoted 6 lines

Quoted 2 lines

[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.

Hi,

Quoted 54 lines · Maxime Ripard

Hi Yegor,

Quoted 44 lines · Yegor Yefremov

Quoted 43 lines · Bin Liu

Hi,

Quoted 26 lines · Maxime Ripard

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.

Quoted 8 lines

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.

Quoted 6 lines

Quoted 2 lines

[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.

Quoted 6 lines

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

Hi Markus,

Quoted 64 lines · Markus Pargmann

Hi,

Quoted 54 lines · Maxime Ripard

Hi Yegor,

Quoted 44 lines · Yegor Yefremov

Quoted 43 lines · Bin Liu

Hi,

Quoted 26 lines · Maxime Ripard

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.

Quoted 8 lines

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.

Quoted 6 lines

Quoted 2 lines

[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.

Quoted 6 lines

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.

Quoted 7 lines

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

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.

Hi,

Quoted 3 lines · Yegor Yefremov

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.

Quoted 31 lines · Maxime Ripard

Hi,

Quoted 3 lines · Yegor Yefremov

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

Quoted 4 lines

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?

Hi,

Quoted 37 lines · Maxime Ripard

Quoted 35 lines · Maxime Ripard

Hi,

Quoted 3 lines · Yegor Yefremov

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.

Quoted 1 line

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.

Hi Felipe,

Quoted 9 lines · Felipe Balbi

Hi,

Quoted 6 lines · Maxime Ripard

Quoted 5 lines · Maxime Ripard

Hi,

Quoted 2 lines · Yegor Yefremov

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

Quoted 33 lines

Quoted 32 lines

Quoted 26 lines

Quoted 1 line

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

Quoted 4 lines

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?

Quoted 2 lines

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.

Hi,

Quoted 6 lines · Maxime Ripard

Hi Felipe,

Quoted 3 lines · Felipe Balbi

Hi,

On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote:

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines · Maxime Ripard

Quoted 5 lines

Hi,

Quoted 2 lines · Yegor Yefremov

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 ?

Quoted 36 lines

Quoted 35 lines

Quoted 26 lines

Quoted 26 lines

Quoted 1 line

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

Quoted 6 lines

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 12 lines · Felipe Balbi

Hi,

Quoted 9 lines · Maxime Ripard

Hi Felipe,

Quoted 6 lines · Felipe Balbi

Hi,

Quoted 3 lines · Maxime Ripard

Quoted 2 lines · Maxime Ripard

Hi,

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines · Yegor Yefremov

Quoted 2 lines

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.

Quoted 36 lines

Quoted 36 lines

Quoted 35 lines

Quoted 26 lines

Quoted 26 lines

Quoted 1 line

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

Quoted 6 lines

Quoted 4 lines

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.

Quoted 7 lines

Quoted 4 lines

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

Quoted 19 lines · Maxime Ripard

Quoted 17 lines · Felipe Balbi

Hi,

Quoted 12 lines · Maxime Ripard

Hi Felipe,

Quoted 9 lines · Felipe Balbi

Hi,

Quoted 6 lines · Maxime Ripard

Quoted 5 lines · Maxime Ripard

Hi,

Quoted 2 lines · Yegor Yefremov

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 ?

Quoted 1 line

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

Hi,

Quoted 20 lines · Yegor Yefremov

Quoted 19 lines · Maxime Ripard

Quoted 17 lines · Felipe Balbi

Hi,

Quoted 12 lines · Maxime Ripard

Hi Felipe,

Quoted 9 lines · Felipe Balbi

Hi,

Quoted 6 lines · Maxime Ripard

Quoted 5 lines · Maxime Ripard

Hi,

Quoted 2 lines · Yegor Yefremov

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 ?

Quoted 7 lines

Quoted 1 line

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.

Quoted 42 lines · Felipe Balbi

Hi,

Quoted 20 lines · Yegor Yefremov

Quoted 19 lines · Maxime Ripard

Quoted 17 lines · Felipe Balbi

Hi,

Quoted 12 lines · Maxime Ripard

Hi Felipe,

Quoted 9 lines · Felipe Balbi

Hi,

Quoted 6 lines · Maxime Ripard

Quoted 5 lines · Maxime Ripard

Hi,

Quoted 2 lines · Yegor Yefremov

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 ?

Quoted 7 lines

Quoted 1 line

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

Quoted 7 lines

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.

Quoted 55 lines · Felipe Balbi

Quoted 42 lines · Felipe Balbi

Hi,

Quoted 20 lines · Yegor Yefremov

Quoted 19 lines · Maxime Ripard

Quoted 17 lines · Felipe Balbi

Hi,

Quoted 12 lines · Maxime Ripard

Hi Felipe,

Quoted 9 lines · Felipe Balbi

Hi,

Quoted 6 lines · Maxime Ripard

Quoted 5 lines · Maxime Ripard

Hi,

Quoted 2 lines · Yegor Yefremov

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 ?

Quoted 7 lines

Quoted 1 line

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

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 60 lines · Felipe Balbi

Quoted 58 lines · Felipe Balbi

Quoted 42 lines · Felipe Balbi

Hi,

Quoted 20 lines · Yegor Yefremov

Quoted 19 lines · Maxime Ripard

Quoted 17 lines · Felipe Balbi

Hi,

Quoted 12 lines · Maxime Ripard

Hi Felipe,

Quoted 9 lines · Felipe Balbi

Hi,

Quoted 6 lines · Maxime Ripard

Quoted 5 lines · Maxime Ripard

Hi,

Quoted 2 lines · Yegor Yefremov

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 ?

Quoted 7 lines

Quoted 1 line

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

Quoted 7 lines

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.

Quoted 2 lines

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

Felipe,

Quoted 64 lines · Felipe Balbi

Quoted 62 lines · Felipe Balbi

Quoted 51 lines · Felipe Balbi

Quoted 42 lines · Felipe Balbi

Hi,

Quoted 20 lines · Yegor Yefremov

Quoted 19 lines · Maxime Ripard

Quoted 17 lines · Felipe Balbi

Hi,

Quoted 12 lines · Maxime Ripard

Hi Felipe,

Quoted 9 lines · Felipe Balbi

Hi,

Quoted 6 lines · Maxime Ripard

Quoted 5 lines · Maxime Ripard

Hi,

Quoted 2 lines · Yegor Yefremov

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 ?

Quoted 7 lines

Quoted 1 line

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

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 2 lines

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?

Quoted 67 lines · Bin Liu

Felipe,

Quoted 64 lines · Felipe Balbi

Quoted 62 lines · Felipe Balbi

Quoted 51 lines · Felipe Balbi

Quoted 42 lines · Felipe Balbi

Hi,

Quoted 20 lines · Yegor Yefremov

Quoted 19 lines · Maxime Ripard

Quoted 17 lines · Felipe Balbi

Hi,

Quoted 12 lines · Maxime Ripard

Hi Felipe,

Quoted 9 lines · Felipe Balbi

Hi,

Quoted 6 lines · Maxime Ripard

Quoted 5 lines · Maxime Ripard

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 ?

Quoted 7 lines

Quoted 1 line

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

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 6 lines

Quoted 2 lines

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

Quoted 83 lines · Felipe Balbi

Quoted 67 lines · Bin Liu

Felipe,

Quoted 64 lines · Felipe Balbi

Quoted 62 lines · Felipe Balbi

Quoted 51 lines · Felipe Balbi

Quoted 42 lines · Felipe Balbi

Hi,

Quoted 20 lines · Yegor Yefremov

Quoted 19 lines · Maxime Ripard

Quoted 17 lines · Felipe Balbi

Hi,

Quoted 12 lines · Maxime Ripard

Hi Felipe,

Quoted 9 lines · Felipe Balbi

Hi,

Quoted 6 lines · Maxime Ripard

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 ?

Quoted 7 lines

Quoted 1 line

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

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 2 lines

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 ;)

Quoted 25 lines

Quoted 24 lines

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 2 lines

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).

Hi,

Quoted 25 lines · Felipe Balbi

Quoted 25 lines

Quoted 24 lines

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 6 lines

Quoted 2 lines

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:

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

Felipe,

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

Quoted 36 lines · Felipe Balbi

Hi,

Quoted 25 lines · Felipe Balbi

Quoted 25 lines

Quoted 24 lines

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 6 lines

Quoted 2 lines

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]

Quoted 7 lines

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

Quoted 6 lines

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.

Quoted 87 lines · Bin Liu

Quoted 85 lines · Felipe Balbi

Quoted 67 lines · Bin Liu

Felipe,

Quoted 64 lines · Felipe Balbi

Quoted 62 lines · Felipe Balbi

Quoted 51 lines · Felipe Balbi

Quoted 42 lines · Felipe Balbi

Hi,

Quoted 20 lines · Yegor Yefremov

Quoted 19 lines · Maxime Ripard

Quoted 17 lines · Felipe Balbi

Hi,

Quoted 12 lines · Maxime Ripard

Hi Felipe,

Quoted 9 lines · Felipe Balbi

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 ?

Quoted 7 lines

Quoted 1 line

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

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 2 lines

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).

Quoted 2 lines

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

hey, congrats :-)

--
balbi

Felipe,

Quoted 88 lines · Felipe Balbi

Quoted 87 lines · Bin Liu

Quoted 85 lines · Felipe Balbi

Quoted 67 lines · Bin Liu

Felipe,

Quoted 64 lines · Felipe Balbi

Quoted 62 lines · Felipe Balbi

Quoted 51 lines · Felipe Balbi

Quoted 42 lines · Felipe Balbi

Hi,

Quoted 20 lines · Yegor Yefremov

Quoted 19 lines · Maxime Ripard

Quoted 17 lines · Felipe Balbi

Hi,

Quoted 12 lines · Maxime Ripard

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 ?

Quoted 7 lines

Quoted 1 line

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

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 7 lines

Quoted 2 lines

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

hey, congrats :-)

--
balbi

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)

Quoted 4 lines · Bin Liu

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.

Quoted 6 lines

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.

Quoted 9 lines

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

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 2 lines

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?

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 5 lines

Quoted 2 lines

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 ?

Hi,

Quoted 11 lines · Felipe Balbi

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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.

Hi Felipe,

Quoted 31 lines · Alexandre Belloni

Hi,

Quoted 11 lines · Felipe Balbi

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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.

Quoted 2 lines

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

Hi,

Quoted 37 lines · Gregory CLEMENT

Hi Felipe,

Quoted 33 lines · Alexandre Belloni

Hi,

Quoted 11 lines · Felipe Balbi

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 12 lines

Thanks,

Gregory

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

Hi Bin,

Quoted 44 lines · Bin Liu

Hi,

Quoted 40 lines · Gregory CLEMENT

Hi Felipe,

Quoted 25 lines · Alexandre Belloni

Hi,

Quoted 11 lines · Felipe Balbi

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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.

Quoted 8 lines

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?

Quoted 4 lines

Quoted 1 line

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.

Hi again,

Quoted 52 lines · Gregory CLEMENT

Hi Bin,

Quoted 48 lines · Bin Liu

Hi,

Quoted 34 lines · Gregory CLEMENT

Hi Felipe,

Quoted 31 lines · Alexandre Belloni

Hi,

Quoted 11 lines · Felipe Balbi

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 3 lines

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

Quoted 61 lines · Gregory CLEMENT

Hi again,

Quoted 47 lines · Gregory CLEMENT

Hi Bin,

Quoted 44 lines · Bin Liu

Hi,

Quoted 40 lines · Gregory CLEMENT

Hi Felipe,

Quoted 25 lines · Alexandre Belloni

Hi,

Quoted 11 lines · Felipe Balbi

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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.

Quoted 8 lines

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?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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:

Quoted 1 line

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.

Hi again Felipe,

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

Quoted 62 lines · Felipe Balbi

Quoted 61 lines · Gregory CLEMENT

Hi again,

Quoted 47 lines · Gregory CLEMENT

Hi Bin,

Quoted 44 lines · Bin Liu

Hi,

Quoted 40 lines · Gregory CLEMENT

Hi Felipe,

Quoted 25 lines · Alexandre Belloni

Hi,

Quoted 11 lines · Felipe Balbi

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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.

Quoted 8 lines

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?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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:

Quoted 7 lines

Quoted 1 line

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)."

Hi,

Quoted 86 lines · Gregory CLEMENT

Hi again Felipe,

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

Quoted 62 lines · Felipe Balbi

Quoted 61 lines · Gregory CLEMENT

Hi again,

Quoted 47 lines · Gregory CLEMENT

Hi Bin,

Quoted 44 lines · Bin Liu

Hi,

Quoted 40 lines · Gregory CLEMENT

Hi Felipe,

Quoted 25 lines · Alexandre Belloni

Hi,

Quoted 11 lines · Felipe Balbi

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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.

Quoted 8 lines

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?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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:

Quoted 7 lines

Quoted 1 line

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?

Quoted 3 lines

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.

Hi Felipe,

Quoted 89 lines · Felipe Balbi

Hi,

Quoted 86 lines · Gregory CLEMENT

Hi again Felipe,

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

Quoted 62 lines · Felipe Balbi

Quoted 61 lines · Gregory CLEMENT

Hi again,

Quoted 47 lines · Gregory CLEMENT

Hi Bin,

Quoted 44 lines · Bin Liu

Hi,

Quoted 40 lines · Gregory CLEMENT

Hi Felipe,

Quoted 25 lines · Alexandre Belloni

Hi,

Quoted 11 lines · Felipe Balbi

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

Quoted 4 lines · Bin Liu

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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.

Quoted 8 lines

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?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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:

Quoted 7 lines

Quoted 1 line

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?

Quoted 7 lines

Quoted 3 lines

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.

Quoted 108 lines · Gregory CLEMENT

Hi Felipe,

Quoted 89 lines · Felipe Balbi

Hi,

Quoted 86 lines · Gregory CLEMENT

Hi again Felipe,

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

Quoted 62 lines · Felipe Balbi

Quoted 61 lines · Gregory CLEMENT

Hi again,

Quoted 47 lines · Gregory CLEMENT

Hi Bin,

Quoted 44 lines · Bin Liu

Hi,

Quoted 40 lines · Gregory CLEMENT

Hi Felipe,

Quoted 25 lines · Alexandre Belloni

Hi,

Quoted 11 lines · Felipe Balbi

Quoted 10 lines · Bin Liu

Alexandre,

Quoted 6 lines · Alexandre Belloni

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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.

Quoted 8 lines

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?

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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:

Quoted 7 lines

Quoted 1 line

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?

Quoted 7 lines

Quoted 3 lines

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."

Quoted 4 lines

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.

Quoted 8 lines

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

Quoted 2 lines

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.

Hi,

Quoted 3 lines · Yegor Yefremov

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.