23 Nov, 2014

1 commit

  • U-Boot has never cared about the type when we get max/min of two
    values, but Linux Kernel does. This commit gets min, max, min3, max3
    macros synced with the kernel introducing type checks.

    Many of references of those macros must be fixed to suppress warnings.
    We have two options:
    - Use min, max, min3, max3 only when the arguments have the same type
    (or add casts to the arguments)
    - Use min_t/max_t instead with the appropriate type for the first
    argument

    Signed-off-by: Masahiro Yamada
    Acked-by: Pavel Machek
    Acked-by: Lukasz Majewski
    Tested-by: Lukasz Majewski
    [trini: Fixup arch/blackfin/lib/string.c]
    Signed-off-by: Tom Rini

    Masahiro Yamada
     

04 Nov, 2014

1 commit


29 Aug, 2014

1 commit

  • One specific USB 3.0 device behaves strangely when reset by
    usb_new_device()'s call to hub_port_reset(). For some reason, the device
    appears to briefly drop off the bus when this second bus reset is
    executed, yet if we retry this loop, it'll eventually come back after
    another two resets.

    If USB bus reset is executed over and over within usb_new_device()'s call
    to hub_port_reset(), I see the following sequence of results, which
    repeats as long as you want:

    1) STAT_C_CONNECTION = 1 STAT_CONNECTION = 0 USB_PORT_STAT_ENABLE 0
    2) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0
    3) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1

    The device in question is a SanDisk Ultra USB 3.0 16GB memory stick with
    USB VID/PID 0x0781/0x5581.

    In order to allow this device to work with U-Boot, ignore the
    {C_,}CONNECTION bits in the status/change registers, and only use the
    ENABLE bit to determine if the reset was successful.

    To be honest, extensive investigation has failed to determine why this
    problem occurs. I'd love to know! I don't know if it's caused by:
    * A HW bug in the device
    * A HW bug in the Tegra USB controller
    * A SW bug in the U-Boot Tegra USB driver
    * A SW bug in the U-Boot USB core

    This issue only occurs when the device's USB3 pins are attached to the
    host; if only the USB2 pins are connected the issue does not occur. The
    USB3 controller on Tegra is in reset, so is not actively communicating
    with the device at all - a USB3 analyzer confirms this. Slightly
    unplugging the device (so the USB3 pins don't contact) or using a USB2
    cable or hub as an intermediary avoids the problem. For some reason,
    the Linux kernel (either on the same Tegra board, or on an x86 host)
    has no issue with the device, and I observe no disconnections during
    reset.

    This change won't affect any USB device that already works, since such
    devices could not currently be triggering the error return this patch
    removes, or they wouldn't be working currently.

    However, this patch is quite reliable in practice, hence I hope it's
    acceptable to solve the problem.

    The only potential fallout I can see from this patch is:

    * A broken device that triggers C_CONNECTION/!CONNECTION now causes the
    loop in hub_port_reset() to run multiple times. If it never succeeds,
    this will cause "usb start" to take roughly 1s extra to execute.

    * If the user unplugs a device while hub_port_reset() is executing, and
    very quickly swaps in a new device, hub_port_reset() might succeed on
    the new device. This would mean that any information cached about the
    original device (from the descriptor read in usb_new_device(), which
    simply caches the max packet size) might be invalid, which would cause
    problems talking to the new device. However, without this change, the
    new device wouldn't work anyway, so this is probably not much of a
    loss.

    Signed-off-by: Stephen Warren

    Stephen Warren
     

02 Jun, 2014

2 commits

  • Now that we wait the correct specification-mandated time at the end of
    usb_hub_power_on(), I suspect that CONFIG_USB_HUB_MIN_POWER_ON_DELAY has
    no purpose.

    For cm_t35.h, we already wait longer than the original MIN_POWER_ON_DELAY,
    so this change is safe.

    For gw_ventana.h, we will wait as long as the original MIN_POWER_ON_DELAY
    iff pgood_delay was at least 200ms. I'm not sure if this is the case or
    not, hence I've CC'd relevant people to test this change.

    Cc: Igor Grinberg
    Cc: Tim Harvey
    Signed-off-by: Stephen Warren

    Stephen Warren
     
  • usb_hub_power_on() currently waits for the maximum of (a) the hub port's
    power output to become good, (b) the max time the USB specification
    allows a device to take to connect.

    However, these two operations must occur in series rather than in
    parallel. First, the power supply ramps up to the level required to
    power the USB device, and then the device may take a certain amount of
    time to connect (assert D+/D- pullups).

    Related, the maximum time that a device has to assert pullups is 1s not
    100ms.

    This is explained in "Connect Timing ECN.pdf", itself part of
    usb_20_042814.zip from www.usb.org.

    Signed-off-by: Stephen Warren

    Stephen Warren
     

27 Aug, 2013

2 commits


30 Jul, 2013

1 commit

  • When power cycling the hub ports, a misbehaving port will prevent all ports
    from being powered on because we quit at the first sign of trouble.

    Skip problematic ports instead of failing the entire power on.

    Cc: Marek Vasut
    Cc: Igor Grinberg
    Signed-off-by: Nikita Kiryanov

    Nikita Kiryanov
     

24 Jul, 2013

1 commit


13 Jun, 2013

2 commits

  • This patch adds support to both Faraday FUSBH200 and FOTG210,
    the differences between Faraday EHCI and standard EHCI are
    listed bellow:

    1. The PORTSC starts at 0x30 instead of 0x44.
    2. The CONFIGFLAG(0x40) is not only un-implemented, and
    also has its address space removed.
    3. Faraday EHCI is a TDI design, but it doesn't
    compatible with the general TDI implementation
    found at both U-Boot and Linux.
    4. The ISOC descriptors differ from standard EHCI in
    several ways. But since U-boot doesn't support ISOC,
    we don't have to worry about that.

    Signed-off-by: Kuo-Jung Su
    CC: Marek Vasut

    Kuo-Jung Su
     
  • This patch makes the minimum power-on delay for USB HUB
    become configurable. The original design waits at least
    100 msec here, but some EHCI controlers(e.g. Faraday EHCI)
    are known to require much longer delay interval.

    Signed-off-by: Kuo-Jung Su
    CC: Marek Vasut

    Kuo-Jung Su
     

06 May, 2013

6 commits


17 Dec, 2012

2 commits

  • If probe of a newly connected device fails for some reason, clean up
    the allocated entry in usb_dev array.

    Signed-off-by: Milind Choudhary
    Signed-off-by: Simon Glass

    Milind Choudhary
     
  • The current logic reads the port status just once after usb_hub_power_on and
    expects the portstatus and portchange to report the connection status
    immediately and correctly.

    Few pen drives are not able to report both of them immediately ie. those pens
    report the connection change but not the connected state after the first read.
    This opportunity once lost is gone for ever because the u-boot, unlike linux or
    any other OS, works in polling mode.

    This patch modifies the logic to read the port status continuously until the
    portstatus and portchange both report a connection change as well as a connected
    state or no connection change and no connection. This logic is placed in a
    timeout of 10 sec. At the end of it, the pen drive would have either reported a
    ONE or a ZERO in bit 1 of portstatus as well as portchange.

    It enhances the set of pen drives which can eventually be detected by u-boot

    Note: This 10 second timeout is based purely on several experiments done with
    the broken pen drives

    Signed-off-by: Vipin Kumar
    Acked-by: Igor Grinberg

    Vipin Kumar
     

16 Oct, 2012

1 commit


21 Sep, 2012

1 commit

  • usb_hub_descriptor has to be packed as it's used for
    communication with the device. Member wHubCharacteristics
    violates the natural alignment rules.

    Use explicit unaligned access functions for this member.
    Fixes ARMv7 traping while using USB.

    v2: fix typo found by Thomas Langer

    v3: rebased on top of u-boot-usb/master

    Signed-off-by: Lucas Stach

    Lucas Stach
     

20 May, 2012

1 commit

  • This avoids cache-alignment warnings shown in console
    when a usb command is entered.

    Whenever X bytes of unaligned buffer is invalidated, arm core
    invalidates X + Y bytes as per the cache line size and throws
    these warnings.

    Signed-off-by: Puneet Saxena
    Signed-off-by: Marek Vasut

    Puneet Saxena
     

19 Mar, 2012

1 commit

  • Common code has a mdelay() func, so use that instead of the usb-specific
    wait_ms() func. This also fixes the build errors:

    ohci-hcd.c: In function 'submit_common_msg':
    /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available
    ohci-hcd.c:1519:9: sorry, unimplemented: called from here
    /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available
    ohci-hcd.c:1816:10: sorry, unimplemented: called from here
    /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available
    ohci-hcd.c:1827:10: sorry, unimplemented: called from here
    /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available
    ohci-hcd.c:1844:10: sorry, unimplemented: called from here
    /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available
    ohci-hcd.c:1563:11: sorry, unimplemented: called from here
    /usr/local/src/u-boot/blackfin/include/usb.h:202:44: sorry, unimplemented: inlining failed in call to 'wait_ms': function body not available
    ohci-hcd.c:1583:9: sorry, unimplemented: called from here
    make[1]: *** [ohci-hcd.o] Error 1

    Signed-off-by: Mike Frysinger
    Acked-by: Marek Vasut

    Mike Frysinger
     

03 Mar, 2012

2 commits