I have the following issue: I have a Himax touch driver IC connected via I2C. Additionally, I have a USB microphone and speaker connected. When I boot the system with both connected, the USB devices are not detected, “lsusb” just returns an empty list. (This is via adb over wifi, because with the USB-C cable connected, Hikey runs in USB client mode.) When I disconnect the touch panel and reboot, the USB devices show up nicely. A way of getting them to work together is to boot the system with both connected and then briefly connecting the USB-C cable and removing it. This forces the USB controller to reinitialize itself, causing the USB devices to be re-enumerated again. But this of course is not a real solution. I know this is not enough information for you to identify the issue at hand, but I’m really clueless as to what could be causing it. The Himax driver has a few references to USB, but they are all disabled and i also tried using different GPIOs for the touch controller hoping to remove a possible conflict. One major difference in the dmesg output is that the hi3660_usb3_phy is shut down, which doesn’t happen with the touch panel disconnected.
here’s a dmesg-diff:
--- notouch.txt
+++ touch.txt
@@ -88,6 +88,15 @@
usbcore: registered new interface driver snd-usb-audio
[bq2588x] bq2588x_charger_probe: USB supply not found, defer probe
[bq2588x] bq2588x_charger_interrupt: usb removed, set usb present = 0
+ [USB3][hisi_dwc3_runtime_idle]+
+ [USB3][hisi_dwc3_runtime_suspend]+
+ [USB3][hi3660_usb3phy_shutdown]+
+ [USB3][set_hisi_dwc3_power_flag]get dwc3 lock
+ [USB3][set_hisi_dwc3_power_flag]set hisi_dwc3_power_flag 0
+ [USB3][set_hisi_dwc3_power_flag]put dwc3 lock
+ [USB3][hi3660_usb3phy_shutdown]-
+ [USB3][hisi_dwc3_runtime_suspend]-
+ [USB3][hisi_dwc3_runtime_idle]-
dpm_caps: local_usb_comm
dpm_caps: local_usb_suspend
[USB3][hisi_usb_otg_event]hisi_usb_otg_event in:1
@@ -98,55 +107,9 @@
[USB3][event_work]+
[USB3][handle_event][handle_event] type: 2
[USB3][set_vbus_power]set port power 1
- xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
- usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
- usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
- usb usb1: Product: xHCI Host Controller
- usb usb1: Manufacturer: Linux 4.9.124-09052-g1927d41-dirty xhci-hcd
- usb usb1: SerialNumber: xhci-hcd.0.auto
- hub 1-0:1.0: USB hub found
- xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
- usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
- usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
- usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
- usb usb2: Product: xHCI Host Controller
- usb usb2: Manufacturer: Linux 4.9.124-09052-g1927d41-dirty xhci-hcd
- usb usb2: SerialNumber: xhci-hcd.0.auto
- hub 2-0:1.0: USB hub found
- [USB3][hisi_dwc3_wake_lock]usb otg wake lock
- [USB3][handle_event]hisi usb_status: OFF -> HOST
+ dwc3 ff100000.dwc3: this is not a DesignWare USB3 DRD Core
+ [USB3][handle_event]start host error
+ [USB3][set_vbus_power]set port power 0
[USB3][event_work]-
- usb 1-1: new high-speed USB device number 2 using xhci-hcd
- usb 1-1: New USB device found, idVendor=0424, idProduct=2734
- usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
- usb 1-1: Product: USB2734
- usb 1-1: Manufacturer: Microchip Tech
- hub 1-1:1.0: USB hub found
- usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
- usb 2-1: New USB device found, idVendor=0424, idProduct=5734
- usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=0
- usb 2-1: Product: USB5734
- usb 2-1: Manufacturer: Microchip Tech
- hub 2-1:1.0: USB hub found
otg_wakelock_init: No USB transceiver found
- usb 1-1.2: new full-speed USB device number 3 using xhci-hcd
- usb 1-1.2: New USB device found, idVendor=16c0, idProduct=048a
- usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
- usb 1-1.2: Product: Teensy MIDI/Audio
- usb 1-1.2: Manufacturer: Teensyduino
- usb 1-1.2: SerialNumber: 5046240
- cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
- usb 2-1: USB disconnect, device number 2
- usb 1-1.2: Warning! Unlikely big volume range (=4095), cval->res is probably wrong.
- usb 1-1.2: [49] FU [PCM Playback Volume] ch = 2, val = 0/4095/1
- usb 1-1.5: new high-speed USB device number 4 using xhci-hcd
- usb 1-1.5: New USB device found, idVendor=0424, idProduct=2740
- usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
- usb 1-1.5: Product: Hub Controller
- usb 1-1.5: Manufacturer: Microchip Tech
- type=1400 audit(1560844290.753:46): avc: denied { read } for comm="lsusb" name="uevent" dev="sysfs" ino=19959 scontext=u:r:shell:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
- type=1400 audit(1560844290.753:46): avc: denied { read } for comm="lsusb" name="uevent" dev="sysfs" ino=19959 scontext=u:r:shell:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
- type=1400 audit(1560844290.753:47): avc: denied { open } for comm="lsusb" path="/sys/devices/platform/soc/ff200000.hisi_usb/ff100000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.2/1-1.2:1.0/uevent" dev="sysfs" ino=19959 scontext=u:r:shell:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
- type=1400 audit(1560844290.753:47): avc: denied { open } for comm="lsusb" path="/sys/devices/platform/soc/ff200000.hisi_usb/ff100000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.2/1-1.2:1.0/uevent" dev="sysfs" ino=19959 scontext=u:r:shell:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
- type=1400 audit(1560844290.757:48): avc: denied { getattr } for comm="lsusb" path="/sys/devices/platform/soc/ff200000.hisi_usb/ff100000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.2/1-1.2:1.0/uevent" dev="sysfs" ino=19959 scontext=u:r:shell:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
to me, the question is: why does the hisi_dwc3_runtime_idle event happen when the touch panel is connected? could it be that Linux stops looking for an input device because the touch panel has been registered and therefore shuts down the usb controller?
It might help for you to post a link to your touchscreen driver and the changes you implemented in the DT to enable it.
Nothing about a pure i2c/gpio touchscreen should have any impact on usb, and in fact, I have successfully used i2c touchscreen (goodix gt91x) with no I’ll effects. I am therefore forced to assume that your issue is due to the driver you are using, and/or the configuration you have implemented, neither of which can be debugged without seeing the driver and configuration.
Here’s the device tree:
&i2c0 {
/* On Low speed expansion */
label = "LS-I2C0";
status = "okay";
himax-ts@48 {
status = "ok";
compatible = "himax,hxcommon";
reg = <0x48>;
himax,panel-coords = <0 800 0 800>;
himax,display-coords = <0 800 0 800>;
himax,irq-gpio = <&gpio26 4 0x00>;
himax,rst-gpio = <&gpio26 1 0x00>;
himax,3v3-gpio = <0>;
interrupt-parent = <&gpio26>;
interrupts = <4 0x2>;
report_type = <1>;
};
...
}
I have tried using different GPIO’s as well with no positive result.
You can download the driver code from here (7 days):
There doesn’t seem to be an actual hardware conflict, because after you force the dwc3 controller into client mode and back into host mode by connecting and disconnecting the USB-C debugging cable, things work just fine. But I just can’t tell my client to do that every time the system is brought up.
I have also tried to enforce the procedure above from software, by toggling the USB_SW_SEL pin from the command line. This only had an effect on the availability of the device on the debugging USB-C port as seen from the host.
With just a quick glance, I’m not seeing anything in the driver or config that should have any impact on USB at all.
Tell me; what kernel are you running? Have you moved up to 4.14? Or are you still running 4.9?
Early on when I started working with the kernel at 4.9, I recall having some strange USB behavior. It ultimately seemed to be timing related, and I ended up working around it by disabling other, unneeded drivers, from the kernel. I wonder if that is what you are running into now?
I wonder how much time this driver adds to boot?
Maybe try this;
Yeah, I think that’s probably it.
I even found the bug thread discussing it;
https://bugs.96boards.org/show_bug.cgi?id=662
** No solution was ever found.
I also implemented another workaround for it;
I think I’m still on 4.9 altough I’m not entirely sure, I’ll look it up when I get back to work tomorrow. Would upgrading to 4.14 also be a possible fix?
The bug report shows exactly the same behaviour, so I’ll also try your workaround(s). Device mode is not needed. I guess I can still use it in fastboot mode, right?
Easy way to tell if you’re running 4.9: if you ever see any graphical artifacts, basically small squares in the “top layer” that show through to the bottom layer most notable in the taskbar area – this would be a sure sign you’re running 4.9, since its gone in 4.14.
Regarding the USB workarounds;
Fastboot will work fine, and adb over IP, if you add the system property to enable it.
I haven’t personally seen (or heard of) this USB problem on 4.14, but that doesn’t necessarily mean that its not there or that it can’t be triggered.
There are other USB glitches I have seen on 4.14, like occasionally a kernel panic/reboot when plugging or unplugging a USB device.
Oh in that case I’m on 4.9 for sure, artefacts galore here! Will update kernel tomorrow first thing!
Remember to do a make clean, or otherwise wipe the /out directory. There are a bunch of files that are changed in the filesystem that won’t automatically correct themselves.
When was the last time you updated your AOSP? 4.14 is now the default and has been for a few months. All of my stuff is now based off the April 23 known good manifest.
Got delayed, some new hardware issue surfaced that requires immediate attention:)
Last time I did a pull on 4.9 must have been summer or fall 2018. We basically run a single app that we develop in house. As long as that runs fine, there is no need to update or upgrade.
Then I would probably suggest keeping the 4.9 kernel with your current summer/fall '18 tree and try working around the usb glitches as we’ve discussed. You can sync the April '19 manifest into a new directory to work on in parallel so that you don’t destroy what is known to mostly work.
And for what its worth, I was able to use kernel 4.9 from January 27, 2019 with the known good manifest of September 11, 2018. So if you want to move forward with a more mature kernel 4.9, that should be an option for you.
Yeah sounds like a good idea. I used your workaround of disabling USB_GADGET, works flawlessly. Thanks again!
