Apalis iMX8 power-off USB port

Using an Apalis iMX8QP 2GB WB V1.1B flashed with the tdx-reference-multimedia-image from the tdx-xwayland distro (5.3.0 dunfell tag).

I’m wanting to drive the MXM3_84 pin (mapped to gpio-356) lo so as to cut power to the usb hub. However, using the normal Linux userspace doesn’t permit that because the pin is already taken (I suspect) by the usb drivers.

How can I either a) gain access to the pin to drive it lo, or b) tell the usb driver to cut the power

?

Greetings @grh,

Let me ask a few questions so that I may understand your use-case better.

So ultimately it sounds like you want to be able to enable/disable power to the USB hub at will? Meaning sometimes you want the USB hub powered and sometimes you don’t. Is that all correct?

May I ask for what reason/purpose you’re trying to do this?

Best Regards,
Jeremias

That’s correct. We have a USB camera that requires a power cycle on reboot instead of just a reset signal.

Hmm that does sound tricky. What’s the current behavior of your USB camera when the system reboots?

It’s “possible” to toggle the state of the USB power rail/regulator from user-space Linux. But it’s not a very well known process form what I’ve seen and toggling power rails from Linux is usually seen as a kernel space process.

I’m curious if there’s any less “hackish” alternatives for your USB camera.

There are a number of USB relates files in the sysfs. For example /sys/bus/usb/devices/usb1/power/level, or something similar. It should be possible to write to these files to affect the power state of the USB system. Though I’ve never tried this before and I’m unsure if this would be enough to power-cycle your USB camera.

Best Regards,
Jeremias

Hi, Jeremias, sorry for the delay,

When the system reboots, it appears the USB camera (enumerated as a SuperSpeed device on H4) does not power cycle (and therefore does not go through its normal power up cycle), and when the system comes back up, it generates numerous USB errors like this:

usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
usb usb2-port1: config error

Yes, I’ve already played around with sysfs methods for trying to make the usb bus think the power has cycled, to no avail, but I may not have understood everything fully. I’ve been using the Power Management for USB kernel documentation for reference:

https://www.kernel.org/doc/html/latest/driver-api/usb/power-management.html

We’re not so concerned if a solution is “hacky” or not: we just need it to cut the power to the port…

v/r

grh

One follow up:

Confirmed that it never physically powers off, and when those errors are generated, unplugging the usb camera and plugging it back in fixes the errors. However, that is not an option for our application: these cameras will be mounted on top of a light pole in a parking lot, so won’t have the option of physically touching the device.

grh

Alright in this case then there is a way then to use that GPIO to control the USB power. Please see my solution that I posted to a similar question here: Toggle the ethernet/Phy power supply on Verdin - #6 by jeremias.tx

Basically you want to do something similar except for the regulator that goes to the USB hub instead. The regulator for the USB hub should be defined here in the device tree: imx8-apalis-v1.1.dtsi « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis and Colibri modules

As shown in the other post you’ll want to remove any reference to this so that the pin MXM3 84 is now free to be manipulated from user-space. From here you should be able to manually control the power via this GPIO.

Best Regards,
Jeremias

Oh interesting! This leads me to another question (or perhaps the same question asked in a different way?)

What is it that is keeping the power applied to the port when the reset signal is received as part of the reboot process? Could it be the “regulator-always-on” property?

grh

This is part of it, but essentially the regulator “construct” in the kernel manages all defined regulators at time of boot once the kernel takes over. I believe even without that property the regulator would be on by default, though I think this has to do with the default state of pin. Also to be considered is the state of the pin before the kernel take over (i.e. during the bootloader stage).

Best Regards,
Jeremias

Got it. I can certainly do the device tree patch and am working on that as we speak. I don’t know that we want to go the route I’m about to ask, but let’s talk about hacking on the kernel drivers then as a potentially better solution?

grh

Well, appears to work for our application just fine. I’ve included a startup script that cycles the power on boot, so in the event of a reset signal, it will always cycle power regardless.

v/r

grh

Well that’s good to hear glad we were able to get something that works for you.

I’m not sure if this would be a “better” solution. Though it’s not something I can really comment on further.

Best Regards,
Jeremias