On Mon, 13 Apr 2015 01:18:07 +0200, Marek Vasut <marex@xxxxxxx> 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@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.
HTH,
Harald
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
