ODROID-C1/-C2 USB Detection only triggered by some devices dwc2

Tue Aug 3 13:20:54 PDT 2021

Hi Alan,

sorry for the late reply - I've been very busy with offline things.

On Wed, Jul 21, 2021 at 5:58 PM Alan Stern <stern at rowland.harvard.edu> wrote:
[...]
> On Tue, Jul 20, 2021 at 11:55:05PM +0200, Martin Blumenstingl wrote:
> > > That's what it looks like to me too.  This means that the hub on the
> > > Odroid doesn't support remote wakeup properly.  Or else the root hub
> > > gets the remote-wakeup message and doesn't handle it properly.  Either
> > > way it's a pretty nasty bug for a significant piece of hardware.
> > as a wild idea: I do have a 24MHz logic analyzer. If there was a way
> > for me to force the communication between the hub and dwc2 to use
> > "full speed" or or slower I might be able to look at the signals on
> > the bus.
> > in case you're aware of any possibility to force the communication to
> > use a slower speed then please let me know.
>
> In theory you don't need to worry about this.  When a high-speed device such
> as the Genesys Logic hub goes into suspend, it reverts to full-speed
> signalling (see section 7.1.7.6 of the USB-2 specification).
>
> As such, you can easily measure the change from a suspend signal to a wakeup
> or resume signal, although you can't easily tell which device (the computer
> or the hub) caused the change.  A suspend signal has the D+ line steady at
> high voltage (> 3 V) and the D- line at low voltage (close to 0 V).  A
> resume signal is the opposite, typically lasting only a few (or a few tens)
> of microseconds.
Great, thanks for this explanation.
I'll put this on my TODO list then

> > I misread your comment at first and used slightly different steps:
> > - boot without usbcore.autosuspend=-1
> > - plug in my Corsair Voyager USB 3.0 flash drive
> > - start the usbmon dump
> > - echo -1 >/sys/bus/usb/devices/1-1/power/autosuspend
> > - (the flash drive is detected automatically)
> > - stop the usbmon dump
> >
> > The result of this test can be found in:
> > 0u.mon-odroidc1-plugged-after-boot-disable-autosuspend.out
>
> This was the second attachment to your email.
I double-checked: it seems that I messed up the order of the
attachments but not the filenames here

> > After that I did the test as I believe you're expecting it to be done:
> > - plug in my Corsair Voyager USB 3.0 flash drive
> > - boot without usbcore.autosuspend=-1
> > - start the usbmon dump
> > - echo -1 >/sys/bus/usb/devices/1-1/power/autosuspend
> > - (the flash drive is detected automatically)
>
> This is weird.  Didn't you say earlier that doing the same thing, except for
> using "lsusb -vvv" to wake up the GL hub rather than this sysfs write, would
> not lead to the Corsair drive being detected?
I just verified this again
- plug in my Corsair Voyager USB 3.0 flash drive
- boot without usbcore.autosuspend=-1
- (device is not detected)
- lsusb -vvv
- (nothing happens, device is not detected)
- wait at least 5 seconds
- start the usbmon dump
- echo -1 >/sys/bus/usb/devices/1-1/power/autosuspend
- (the flash drive is detected automatically)
- stop the usbmon dump

So it seems that telling the hub not to auto-suspend seems to work
around it enough?
I attached test-1_hub-autosuspend-1.out to document this result

[...]
> > In both tests I observe the following in the kernel log:
> >   usb 1-1: reset high-speed USB device number 2 using dwc2
> > I assume that this brings the hub into a well-defined state where
> > remote wakeup may not be relevant
>
> I saw such a reset only in the first usbmon trace, not the second.  It looks
> like the reset was performed because of a communication error (the -71
> status code near the beginning of the trace), but it's not at all clear why
> the error occurred.
you are right, it's only happening for the first usbmon trace

> In fact, there were a few strange things in the traces.  Let's look at the
> start of the first one.  The trace starts by showing the root hub
> being resumed, which involves asking for the port status:
>
> c57f1680 41352445 S Ci:1:001:0 s a3 00 0000 0001 0004 4 <
> c57f1680 41352762 C Ci:1:001:0 0 4 = 03050000
>
> The status for port 1 shows that the port isn't suspended and hasn't
> undergone a wakeup transition.  It's simply active, as though it had never
> been suspended in the first place.
>
> (For those unaccustomed to reading these traces, the 03050000 status value
> above means the following: The two bits in the "3" are "Port connected" and
> "Port enabled", and the two bits in the "5" are "Port power on" and "Port is
> high-speed".  If the port were still suspended, the 04000000 bit would be
> set.  Notably missing is the bit which would indicate "Port suspend status
> change", which is in the 00000400 position and is supposed to be set
> whenever the port is resumed because of a wakeup request from the attached
> device.)
>
> c5753280 41352977 S Ii:1:001:1 -115:2048 4 <
>
> The shows the root hub's interrupt URB starting up, the last part of a
> normal resume.
>
> So was the GL hub actually suspended?  It's hard to tell exactly what the
> hardware's doing, but you can get a trace that will help.  Do the following:
at this point I'd like to point out again that it's amazing to have
someone with your knowledge about the whole USB subsystem help out on
this

> Boot with no device plugged in and with "usbcore.autosuspend=-1" on the
> command line.  Then start a usbmon trace.
>
> Next, do
>
>         echo 2 >/sys/bus/usb/devices/1-1/power/autosuspend
>
> and wait a few seconds for the GL hub to be suspended.  To make sure it has,
> do "grep . /sys/bus/usb/devices/1-1/power/*" and include the output in your
> reply.
# grep . /sys/bus/usb/devices/1-1/power/*
/sys/bus/usb/devices/1-1/power/active_duration:104940
/sys/bus/usb/devices/1-1/power/autosuspend:2
/sys/bus/usb/devices/1-1/power/autosuspend_delay_ms:2000
/sys/bus/usb/devices/1-1/power/connected_duration:116500
/sys/bus/usb/devices/1-1/power/control:auto
/sys/bus/usb/devices/1-1/power/level:auto
/sys/bus/usb/devices/1-1/power/runtime_active_time:104511
/sys/bus/usb/devices/1-1/power/runtime_status:suspended
/sys/bus/usb/devices/1-1/power/runtime_suspended_time:11562
/sys/bus/usb/devices/1-1/power/wakeup:disabled

(I ran this command twice by accident, but I guess this makes no
difference. this is the output of the second run)

> Then do
>
>         echo 2 >/sys/bus/usb/devices/usb1/power/autosuspend
>
> and wait a few seconds for the root hub to be suspended.  Again, to make
> sure it has, do "grep . /sys/bus/usb/devices/usb1/power/*".
# grep . /sys/bus/usb/devices/usb1/power/*
/sys/bus/usb/devices/usb1/power/active_duration:130880
/sys/bus/usb/devices/usb1/power/autosuspend:2
/sys/bus/usb/devices/usb1/power/autosuspend_delay_ms:2000
/sys/bus/usb/devices/usb1/power/connected_duration:140000
/sys/bus/usb/devices/usb1/power/control:auto
/sys/bus/usb/devices/usb1/power/level:auto
/sys/bus/usb/devices/usb1/power/runtime_active_time:130872
/sys/bus/usb/devices/usb1/power/runtime_status:suspended
/sys/bus/usb/devices/usb1/power/runtime_suspended_time:9120
/sys/bus/usb/devices/usb1/power/wakeup:disabled

> Once that has settled down, wake up the root hub by doing
>
>         echo -1 >/sys/bus/usb/devices/usb1/power/autosuspend
>
> and a few seconds later, wake up the GL hub by doing
>
>         echo -1 >/sys/bus/usb/devices/1-1/power/autosuspend
>
> All these suspends and resumes should show up in the usbmon trace.  I'd like
> to see what it really says; my guess is that it won't show quite what it
> should.
I attached test-2_autosuspend-steps-without-device-plugged-in.out
which contains the usbmon dump for these steps
At no point I had a USB device plugged in

# grep -o 'usbcore.autosuspend=-1' /proc/cmdline
usbcore.autosuspend=-1

Best regards,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-1_hub-autosuspend-1.out
Type: application/octet-stream
Size: 89589 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-amlogic/attachments/20210803/7790c357/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-2_autosuspend-steps-without-device-plugged-in.out
Type: application/octet-stream
Size: 1617 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-amlogic/attachments/20210803/7790c357/attachment-0001.obj>