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