Control of external VBUS on resume from sleep

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello all,

I've got a USB 3.0 host (an NXP i.MX8QM running 5.10.72 with Cadence
XHCI host controller IP) connected to a USB device on the same PCB,
which also happens to run Linux (although I think that's beside the
point here). The quirk is that, although D+/D- are routed directly
from host to device, VBUS is actually controlled by a separate GPIO on
the host. The dedicated VBUS pin on the USB host controller is pulled
high. ID is pulled high on the PBC but driven low by a GPIO from the
i.MX8, so we can imagine it's tied to ground.

I've made a little schematic drawing [1] to help visualize the connections.

We've run into an issue where, on resume from STR, the following
sequence occurs:
- the GPIO peripheral on the host is powered back on, VBUS is
immediately driven high
- the device signals attach on DP/DN, but _I believe_ the host
controller on the host is not yet powered on
- the host controller is then powered on and the {hub, hcd, xhci}
drivers all resume, but no port status change is detected; I believe
that attach signaling was missed by the host controller

I'd like for the host controller driver (or the root hub driver??) to
have explicit control of VBUS, so that it's driven high only when the
host controller regains power and is ready to detect attach signaling.
I see device-tree documentation about the USB connector node and
`vbus-supply`, but I'm having a hard time understanding how to square
my use-case with `drivers/usb/common/usb-conn-gpio.c`, which reacts to
state changes on VBUS or ID.

Any thoughts on where I should stick the logic that enables VBUS on
resume? My current (very hacky) fix is to initialize a global (argh!)
gpio_desc to refer to the VBUS GPIO, then to call
`gpiod_set_value(<gpio_desc>, 0); gpiod_set_value(<gpio_desc>, 1);` in
`usb_port_resume()`, which is where I ended up when tracking the
original issue. This toggles VBUS and allows us to catch the new round
of attach signaling from the device.

I'm happy to use the fixed-regulator framework instead, I'm just not
sure which driver should own the gpio_desc / regulator and where it
should be disabled / enabled during suspend / resume.

Best,
Kevin

[1]

 i.MX8                      device
.----------------.         .-------------.
|     GPIOX.Y ---|-------->| VBUS (in)   |
|                |         |             |
|  USB           |    _    |             |
| .------------. |    |    |             |
| |    VBUS ---|-|----'    |             |
| |     DP <---|-|-------->| DP          |
| |     DP <---|-|-------->| DN          |
| |     ID ----|-|----.    '-------------'
| '------------' |    |
'----------------'    v



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux