Bug: Toggling green led on Olinuxino Maxi, also toggles USB

[Marek Vasut]

On Monday, April 13, 2015 at 07:59:29 AM, harald at ccbib.org wrote:
> On Mon, 13 Apr 2015 01:18:07 +0200, Marek Vasut <marex at denx.de> wrote:
> > On Sunday, April 12, 2015 at 12:06:10 PM, Stefan Wahren wrote:
> >> Hi,
> >> 
> >> toggling the green LED (GPIO 65) on Olinuxino Maxi unexpectedly also
> >> toggles the USB Host support.
> >> 
> >> Here is the console output:
> >> 
> >> # Switching the led off (USB drive connected)
> >> 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
> >> 
> >> # Switching the led on (USB drive connected)
> >> echo "0" > /sys/class/leds/green/brightness
> >> [ 1068.890000] ci_hdrc ci_hdrc.0: remove, state 1
> >> [ 1068.890000] usb usb1: USB disconnect, device number 1
> >> [ 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 2014-10
> >> 
> >> Harald discovered this problem before me on Olinuxino Mini [1].
> >> 
> >> I think the problem has something to with USB OTG, because GPIO 65 is
> 
> on
> 
> >> the same pin for USB_OTG_ID.
> >> My idea was to set "dr_mode" in olinuxino dts explicit to "host" and it
> >> works, but i'm not sure that is the right fix.
> >> 
> >> Shouldn't chipidea driver complain about missing pinctrl or something
> >> else?
> > 
> > Is the MX23_PAD_SSP1_DETECT pin muxed as a GPIO ? ie. you should have
> 
> such
> 
> > an
> > entry in the DTS pinmux setup -- MX23_PAD_SSP1_DETECT__GPIO_2_1 .
> 
> Yes:
> led_pin_gpio2_1: led_gpio2_1 at 0 {
> 	reg = <0>;
> 	fsl,pinmux-ids = <
> 		MX23_PAD_SSP1_DETECT__GPIO_2_1
> 
> 	>;
> 
> 	fsl,drive-strength = <MXS_DRIVE_4mA>;
> 	fsl,voltage = <MXS_VOLTAGE_HIGH>;
> 	fsl,pull-up = <MXS_PULL_DISABLE>;
> };
> 
> > If it is, then it'd probably mean that the pin state is leaking into the
> > USB
> > core even if it's muxed as GPIO, in which case this would be a silicon
> > problem.
> 
> Well, silicon problem or not: It is actually documented in the iMX23
> 
> Reference Manual 37.2.2:
> | Readback registers are never affected by the operation of the
> | HW_PINCTRL_MUXSELx registers and always sense the actual value
> | on the data pin.
> | 
> | For example, if a pin is programmed to be a GPIO output and then
> | driven high, any specialized hardware interfaces that are actively
> | monitoring that pin will read the high logic value. Conversely, if
> | the pin mux is programmed to give a specialized hardware interface
> | such as the EMI block control of a particular pin, the current state
> | of that pin can be read through its GPIO read register at any time,
> | even while active EMI cycles are in progress.
> 
> So it seems like the driver has to take care not to read pins it isn't
> actually in charge of.

Yikes. But good find, thanks!