Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Novice
1,822 Views

Disabling power to otg (without reboot)

Hello,

In this thread:

I was wondering about disabling power to the otg after a restart. However the ideal scenario for our application would be to disable power to the otg without requiring a restart (and ideally to be able to bring it back up).

(Our application has the edison connected to a mobile device over bluetooth - it would be nice to power up / power down our attached usb hub and devices in response to bluetooth messages from the connected mobile device)

Anyone attempting something similar?

Here are my current (nonworking) steps

# identify usb device

root@ehren-edison-battery1:~# lspci

00:00.0 Host bridge: Intel Corporation Device 1170 (rev 01)

00:01.0 SD Host controller: Intel Corporation Device 1190 (rev 01)

00:01.2 SD Host controller: Intel Corporation Device 1190 (rev 01)

00:01.3 SD Host controller: Intel Corporation Device 1190 (rev 01)

00:02.0 Display controller: Intel Corporation Device 1182 (rev 01)

00:04.0 Serial controller: Intel Corporation Device 1191 (rev 01)

00:04.1 Serial controller: Intel Corporation Device 1191 (rev 01)

00:04.2 Serial controller: Intel Corporation Device 1191 (rev 01)

00:04.3 Serial controller: Intel Corporation Device 1191 (rev 01)

00:05.0 Serial controller: Intel Corporation Device 1192 (rev 01)

00:06.0 System peripheral: Intel Corporation Device 1193 (rev 01)

00:06.1 System peripheral: Intel Corporation Device 1193 (rev 01)

00:07.0 System peripheral: Intel Corporation Device 1194 (rev 01)

00:07.1 System peripheral: Intel Corporation Device 1194 (rev 01)

00:07.2 System peripheral: Intel Corporation Device 1194 (rev 01)

00:08.0 Communication controller: Intel Corporation Device 1195 (rev 01)

00:08.1 Communication controller: Intel Corporation Device 1195 (rev 01)

00:08.2 Communication controller: Intel Corporation Device 1195 (rev 01)

00:08.3 Communication controller: Intel Corporation Device 1195 (rev 01)

00:09.0 Communication controller: Intel Corporation Device 1196 (rev 01)

00:09.1 Communication controller: Intel Corporation Device 1196 (rev 01)

00:09.2 Communication controller: Intel Corporation Device 1196 (rev 01)

00:0a.0 Communication controller: Intel Corporation Device 1197 (rev 01)

00:0b.0 Encryption controller: Intel Corporation Device 1198 (rev 01)

00:0c.0 System peripheral: Intel Corporation Device 1199 (rev 01)

00:0d.0 Multimedia audio controller: Intel Corporation Device 119a (rev 01)

00:0e.0 System peripheral: Intel Corporation Device 119b (rev 01)

00:11.0 USB controller: Intel Corporation Device 119e (rev 01)

00:12.0 Signal processing controller: Intel Corporation Device 119f (rev 01)

00:13.0 Co-processor: Intel Corporation Device 11a0 (rev 01)

00:14.0 Co-processor: Intel Corporation Device 11a1 (rev 01)

00:15.0 System peripheral: Intel Corporation Device 11a2 (rev 01)

00:16.0 Co-processor: Intel Corporation Device 11a3 (rev 01)

00:16.1 Co-processor: Intel Corporation Device 11a4 (rev 01)

00:17.0 System peripheral: Intel Corporation Device 11a5 (rev 01)

00:18.0 Display controller: Intel Corporation Device 11a6 (rev 01)

# disable otg driver

# sometimes a hard reboot of board is required; other times the below stacktrace is echoed (but I can then immediately ssh back into board). In both cases, the otg is still getting power

root@ehren-edison-battery1:~# echo 0000\:00\:11.0 > /sys/bus/pci/drivers/dwc3_otg/unbind

[ 138.203644] BUG: spinlock bad magic on CPU# 1, sh/234

[ 138.203725] BUG: unable to handle kernel paging request at 00001f45

[ 138.203797] IP: [] spin_dump+0x60/0xf0

[ 138.203866] *pdpt = 00000000354d8001 *pde = 0000000000000000

[ 138.203929] Oops: 0000 [# 1] PREEMPT SMP

[ 138.203984] Modules linked in: usb_f_acm u_serial g_multi libcomposite bcm_bt_lpm bcm4334x(O)

[ 138.204105] CPU: 1 PID: 234 Comm: sh Tainted: G W O 3.10.17-poky-edison+ # 1

[ 138.204167] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48

[ 138.204237] task: f5771640 ti: f5746000 task.ti: f5746000

[ 138.204288] EIP: 0060:[] EFLAGS: 00010006 CPU: 1

[ 138.204341] EIP is at spin_dump+0x60/0xf0

[ 138.204382] EAX: 00000028 EBX: 00001d1d ECX: 00000000 EDX: 00000020

[ 138.204436] ESI: f5c05070 EDI: 000000ea EBP: f5747dd8 ESP: f5747db4

[ 138.204490] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068

[ 138.204539] CR0: 8005003b CR2: 00001f45 CR3: 354bd000 CR4: 001007f0

[ 138.204592] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000

[ 138.204643] DR6: ffff0ff0 DR7: 00000400

[ 138.204678] Stack:

[ 138.204703] c1b10078 c1b0f751 00000001 f5771940 000000ea f5747de4 f5c05070 c1b0f751

[ 138.204815] 00000001 f5747de8 c14e0dbb f5c05070 f5c05070 f5747e04 c14e0f4a c15e5852

[ 138.204925] f5746000 f5c05070 f5c05070 00000001 f5747e10 c18df1c2 f5c05000 f5747e24

[ 138.205035] Call Trace:

[ 138.205084] [] spin_bug+0x1b/0x20

[ 138.205139] [] do_raw_spin_lock+0x11a/0x150

[ 138.205200] [] ? hcd_release+0x52/0x60

[ 138.205258] [] _raw_spin_lock_irq+0x22/0x30

[ 138.205316] [] __pm_runtime_disable+0x19/0x110

[ 138.205378] [] xhci_dwc_drv_remove+0x5e/0x80

[ 138.205437] [] platform_drv_remove+0x11/0x20

[ 138.205498] [] __device_release_driver+0x61/0xc0

[ 138.205559] [] device_release_driver+0x1d/0x30

[ 138.205618] [] bus_remove_device+0xb6/0x120

[ 138.205677] [] ? device_remove_attrs+0x21/0x50

[ 138.205736] [] device_del+0xea/0x180

[ 138.205789] [] platform_device_del+0x19/0x90

[ 138.205847] [] platform_device_unregister+0x10/0x20

[ 138.205909] [] dwc_otg_remove+0x35/0xe0

[ 138.205964] [] ? __pm_runtime_resume+0x51/0x80

[ 138.206023] [] pci_device_remove+0x2d/0xa0

[ 138.206082] [] __device_release_driver+0x61/0xc0

[ 138.206143] [] device_release_driver+0x1d/0x30

[ 138.206202] [] driver_unbind+0x61/0xf0

[ 138.206257] [] ? klist_devices_get+0x20/0x20

[ 138.206316] [] ? subsys_virtual_register+0x50/0x50

[ 138.206377] [] drv_attr_store+0x1a/0x30

[ 138.206434] [] sysfs_write_file+0x9a/0x100

[ 138.206490] [] ? sysfs_remove_files+0x40/0x40

[ 138.206551] [] vfs_write+0x9e/0x1c0

[ 138.206607] [] SyS_write+0x49/0x90

[ 138.206662] [] syscall_call+0x7/0xb

[ 138.206704] Code: 00 c7 04 24 78 00 b1 c1 64 8b 0d 10 50 d0 c1 89 7c 24 10 89 44 24 0c 89 4c 24 08 e8 f8 71 3f 00 85 db 8b 56 08 0f 84 7e 00 00 00 <8b> 83 28 02 00 00 81 c3 00 03 00 00 89 44 24 10 8b...

5 Replies
Highlighted
Novice
10 Views

So I've made a little progress.

First use the technique from the thread linked above:

cd /lib/modules/3.10.17-poky-edison+/kernel/drivers/usb/gadget/

mv g_multi.ko g_multi.ko-blah

Then reboot the board

Once rebooted the board will be in such a state where the otg can be re-powered (without a reboot)

# first undo rename

cd /lib/modules/3.10.17-poky-edison+/kernel/drivers/usb/gadget/

mv g_multi.ko-blah g_multi.ko

# then restart load modules service

systemctl restart systemd-modules-load

At this point otg hostmode works (and a reboot wasn't required).

However there is a large caveat - the bug where hostmode is initialized on every other reboot affects this.

 

So on the last step the systemctl restart systemd-modules-load will only work "every other time" - that is, only if hostmode would have been initialized had you not performed the rename kernel modules step above. This is problematic in that after I've done the "rename kernel module then reboot board" step I have to trust that hostmode will be initialized when I restart the systemd-modules-load service (in response to a bluetooth command sent to the edison).

 

(still investigating)

 

0 Kudos
Highlighted
Employee
10 Views

Hello ehren_m,

As stated in several posts, this is a known issue where the Edison will have issues detecting USB devices when the board soft reboots. A software fix has not been yet found but hopefully it will be included in future updates. Nevertheless, there is no ETA on it.

However, a hardware fix might be possible as a "workaround". I mean, you could break the power signal and with a relay or an optocoupler have it reset. You will only need a pin that controls the optocoupler/relay and this pin can be set to toggle every time on boot with a system service.

I know this is a less subtle option but it requires little circuitry and could help you work around this issue.

Peter

Highlighted
Novice
10 Views

Hi Intel_Peter,

Definitely understand there's no ETA for the fix which is totally understandable.

Thanks for the info. Using some sort of relay would actually handle my desired use case (to cut and restore power to the otg port on demand -- so that connected usb devices do not draw power when unneeded). I'm still looking for a software-only approach to achieve this however (which I'm continuing to investigate).

Ehren

0 Kudos
Highlighted
Employee
10 Views

Unfortunately, there's no software solution right now. However, the hardware solution should work in any case.

Peter.

0 Kudos
Highlighted
Novice
10 Views

So I know that this may be an old question, but I stumbled upon this message while I was trying to do a similar thing.

A software-only solution that I found is the following: instead of unbinding the USB host PCI device from the PCI driver, unbind the USB hub from the USB driver. You can use the following:

echo "1-1" > /sys/bus/usb/drivers/usb/unbind

This should remove power to whatever is connected to the USB bus 1-1.

To re-enable power, re-bind the hub with:

echo "1-1" > /sys/bus/usb/drivers/usb/bind

Let me know if that works for you.