switching LED disables USB

[lambda]

Hi,

I'm having a rather strange problem with recent kernels on my olinuxino-mini
(starting around 3.14): If I enable the LED1 (GPIO65) the USB host gets
disabled and/or there are problems with the MMC card.

So far as I know, LED1 is processor pin 88, which also has the functions
"Removable Card Detect" and "USB_ID". So it seems when I enable
the LED (or setting GPIO65 high) the kernel switches into USB gadget mode
(and maybe thinks a SD-Card is inserted).

I think the pin is configured as GPIO by pinctrl, but it seems the other
functions are still active. Maybe the actual behaviour depends on whether
USB OTG support is enabled in the kernel.

Does anybody have an idea how to deal with that?

I noticed this problem when working with current openwrt/mxs snapshots.
Just compiling a kernel without usg gadget support is not an option, because
the same kernel should work with MAXI/MINI as with the NANO. Different
devicetree blobs would be fine though ...

Thanks for any hints,
Harald

[swahren]

Hi Harald,

could you please try to set "dr_mode" to "host" in imx23-olinuxino.dts for MINI:

http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt

Best regards
Stefan

[lambda]

Thanks, this solved the problem for me.

Right now there is only one arch/arm/boot/dts/imx23-olinuxino.dts file for all boards. Should this be split into different files for all the boards? Is somebody from olimex reading this and taking care of this?

Thanks,
Harald

[swahren]

I thought about this problem and came to the conclusion that setting dr_mode is right but it's still a problem in the USB driver.

I think this problem should be submitted to an adequat mailing list.

Could you please describe a scenario to reproduce the problem (Kernel config, bootloader, commands, any other modifications)?

Is the problem reproducable with a current kernel 4.0?

Is this problem reproducable with Olinuxino Maxi?

[lambda]

I thought about this problem and came to the conclusion that setting dr_mode is right but it's still a problem in the USB driver.

Jein. It's not that much what the USB driver could do about it, however two solutions come to my mind:
1) Add a new devicetree property usb_id_broken, that tells the driver to ignore the USB_ID pin. This
is what the mmc driver (having exactly the same problem) does: It's called broken card detect there.
But I think in the USB case we still would need to tell the driver what to acutally do via dr_mode,
so we can as well use this in the first place.
2) Somehow figure out from pinctrl that the pin is not muxed for USB and default to to host mode if
it is not specified in devicetree. (And reject if devicetree asks for OTG)

I think this problem should be submitted to an adequat mailing list.

Please CC me if you do so.

Could you please describe a scenario to reproduce the problem (Kernel config, bootloader, commands, any other modifications)?

It is reproducible with standard OpenWRT kernels or mainline kernels. I don't have access to a running
system now, so pathnames might be wrong, but it's something like

echo 1 >/sys/class/leds/green/brightness
and
echo 0 >/sys/class/leds/green/brightness

and USB is going up/down ...

If you don't have the LED configured, then using the gpio interface has the same effect:
echo 0 >/sys/class/gpio/gpio65/value
and
echo 1 >/sys/class/gpio/gpio65/value

Is the problem reproducable with a current kernel 4.0?

I reproduced it with various kernels from 3.14.0 to 3.19.0+ - I can't test a 4.0 right now, but
unless a fix was merged recently, I expect it to be affected.

Is this problem reproducable with Olinuxino Maxi?

I did my tests with Mini and Nano (don't own a Maxi), but I think the Led works the same there,
so yes. If the Led was different you could still reproduce it via the gpio interface.

HTH,
Harald

[swahren]

Thanks, i think that should be enough information.

[swahren]

Hi Harald,

i'm able to reproduce the problem. After booting my olinuxino-maxi the green LED is on and USB doesn't work.

Code Select Expand

# Switching the led off (level inverted, also an issue)
echo 255 > /sys/class/leds/green/brightness
[  318.650000] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in 11
[  318.650000] ci_hdrc ci_hdrc.0: EHCI Host Controller
[  318.670000] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[  318.710000] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[  318.750000] hub 1-0:1.0: USB hub found
[  318.780000] hub 1-0:1.0: 1 port detected
[  319.140000] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[  319.310000] hub 1-1:1.0: USB hub found
[  319.340000] hub 1-1:1.0: 3 ports detected
[  319.640000] usb 1-1.1: new high-speed USB device number 3 using ci_hdrc
[  319.880000] usb 1-1.2: new high-speed USB device number 4 using ci_hdrc
[  320.030000] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[  320.040000] scsi host0: usb-storage 1-1.2:1.0
[  321.090000] scsi 0:0:0:0: Direct-Access     LG       USB Drive        1100 PQ: 0 ANSI: 0 CCS
[  321.160000] sd 0:0:0:0: [sda] 7928832 512-byte logical blocks: (4.05 GB/3.78 GiB)
[  321.190000] sd 0:0:0:0: [sda] Write Protect is off
[  321.220000] sd 0:0:0:0: [sda] No Caching mode page found
[  321.220000] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  321.490000]  sda: sda1
[  321.530000] sd 0:0:0:0: [sda] Attached SCSI removable disk


Code Select Expand

# Switching the led on
echo "0" > brightness
[ 1068.890000] ci_hdrc ci_hdrc.0: remove, state 1
[ 1068.890000] usb usb1: USB disconnect, device number 1
root@duckbill:/sys/class/leds/green# [ 1068.920000] usb 1-1: USB disconnect, device number 2
[ 1068.920000] usb 1-1.1: USB disconnect, device number 3
[ 1069.070000] usb 1-1.2: USB disconnect, device number 4
[ 1069.450000] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[ 1074.460000] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in 11


Kernel: 4.0.0-rc4-next-20150320
Bootloader: U-Boot

Stefan