summaryrefslogtreecommitdiffstats
path: root/common/usb_hub.c
Commit message (Collapse)AuthorAgeFilesLines
* usb: hub: Don't continue on get_port_status failureMarek Vasut2016-05-061-0/+1
| | | | | | | | | | | The code shouldn't continue probing the port if get_port_status() failed. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <clsee@altera.com> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Stefan Roese <sr@denx.de> Cc: Stephen Warren <swarren@nvidia.com>
* Fix spelling of "occurred".Vagrant Cascadian2016-05-021-1/+1
| | | | | Signed-off-by: Vagrant Cascadian <vagrant@debian.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* usb: Change power-on / scanning timeout handlingStefan Roese2016-03-201-94/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the USB port scanning procedure and timeout handling in the following ways: a) The power-on delay in usb_hub_power_on() is now reduced to a value of max(100ms, "hub->desc.bPwrOn2PwrGood * 2"). The code does not wait using mdelay, instead usb_hub_power_on() will wait before querying the device in the scanning loop later. The total timeout for this hub, which is 1 second + "hub->desc.bPwrOn2PwrGood * 2" is calculated and will be used in the following per-port scanning loop as the timeout to detect active USB devices on this hub. b) Don't delay the minimum delay (for power to stabilize) in usb_hub_power_on(). Instead skip querying these devices in the scannig loop until the delay time is reached. c) The ports are now scanned in a quasi parallel way. The current code did wait for each (unconnected) port to reach its timeout and only then continue with the next port. This patch now changes this to scan all ports of all USB hubs quasi simultaneously. For this, all ports are added to a scanning list. This list is scanned until all ports are ready by either a) reaching the connection timeout (calculated earlier), or by b) detecting a USB device. This results in a faster USB scan time as the recursive scanning of USB hubs connected to the hub that's currently being scanned will start earlier. One small functional change to the original code is, that ports with overcurrent detection will now get rescanned multiple times (PORT_OVERCURRENT_MAX_SCAN_COUNT). Without this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 20.163 seconds With this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 1.822 seconds So ~18.3 seconds of USB scanning time reduction. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Stephen Warren <swarren@nvidia.com>
* usb: Remove 200 ms delay in usb_hub_port_connect_change()Stefan Roese2016-03-201-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes 2 mdelay(200) calls from usb_hub_port_connect_change(). These delays don't seem to be necessary. At least not in my tests. Here the number for a custom x86 Bay Trail board (not in mainline yet) with a quite large and complex USB hub infrastructure. Without this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 28.415 seconds With this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 24.003 seconds So ~4.5 seconds of USB scanning time reduction. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Stephen Warren <swarren@nvidia.com> Cc: Marek Vasut <marex@denx.de>
* usb: legacy_hub_port_reset(): Speedup hub reset handlingStefan Roese2016-03-201-2/+7
| | | | | | | | | | | | | | | | | | Start with a short USB hub reset delay of 20ms. This can be enough for some configurations. The 2nd delay at the end of the loop is completely removed. Since the delay hasn't been long enough, a longer delay time of 200ms is assigned and will be used in the next loop round. This hub reset handling is also used in the v4.4 Linux USB driver, hub_port_reset(). Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Stephen Warren <swarren@nvidia.com> Cc: Marek Vasut <marex@denx.de>
* dm: usb: Avoid time delays in sandbox testsSimon Glass2015-11-191-1/+9
| | | | | | | Currently the USB tests take around two seconds to run. Remove these unnecessary time delays so that the tests run quickly. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Rename dev_get_parentdata() to dev_get_parent_priv()Simon Glass2015-10-231-2/+2
| | | | | | | | The current name is inconsistent with other driver model data access functions. Rename it and fix up all users. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
* Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h headerSimon Glass2015-09-111-0/+1
| | | | | | | Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org>
* usb: Fix device detection codeMarek Vasut2015-08-051-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code in question polls an USB port status via USB_REQ_GET_STATUS to determine whether there is a device on the port or not. The way to figure that out is to check two bits. Those are wPortChange[0] and wPortStatus[0]. The wPortChange[0] indicates whether some kind of a connection status change happened on a port (a device was plugged or unplugged). The wPortStatus[0] bit indicates the status of the connection (plugged or unplugged). The current code tests whether wPortChange[0] == wPortStatus[0] and if that's the case, considers the loop polling for the presence of a USB device on port finished. This works for most USB sticks, since they come up really quickly and trigger the USB port change detection before the first iteration of the detection loop happens. Thus, both wPortChange[0] and wPortStatus[0] are set to 1 and thus equal. The loop is existed in it's first iteration and the stick is detected correctly. The problem is with some obscure USB sticks, which take some time before they pop up on the bus after the port was enabled. In this case, both the wPortChange[0] and wPortStatus[0] are 0. They are equal again, so the loop again exits in the first iteration, but this is incorrect, as such USB stick didn't have the opportunity to get detected on the bus. Rework the code such, that it checks for wPortChange[0] first to test if any connection change happened at all. If no change occured, keep polling. If a change did occur, test the wPortStatus[0] to see there is some device present on the port and only if this is the case, break out of the polling loop. This patch also trims down the duration of the polling loop from 10s per port to 1s per port. This is still annoyingly long, but there is no better option in case of U-Boot unfortunatelly. This change will most likely increase the duration of 'usb start' on some platforms, but this is needed to fix a bug. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Hans de Goede <hdegoede@redhat.com>
* dm: usb: Adjust the USB_DEVICE() macro namingSimon Glass2015-07-211-1/+1
| | | | | | | | | In Linux USB_DEVICE() is used to declare a USB device by vendor/device ID. We should follow the same convention in U-Boot. Rename the existing USB_DEVICE() macro to U_BOOT_USB_DEVICE() and bring in the USB_DEVICE() macro from Linux for use in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org>
* usb: add device connection/disconnection detectionVincent Palatin2015-05-141-1/+1
| | | | | | | | | | | | Provide a function to detect USB device insertion/removal in order to avoid having to do USB enumeration in a tight loop when trying to detect peripheral hotplugging. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* usb: Stop reset procedure when a dev is handed over to a companion hcdHans de Goede2015-05-141-1/+2
| | | | | | | | | | Short circuit the retry loop in legacy_hub_port_reset() by returning an error from usb_control_msg() when a device was handed over to a companion by the ehci code. This avoids trying to reset low / fullspeed devices 5 times needlessly. Also do not print an error when a device has been handed over. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* usb: legacy_hub_port_reset() check and propagate usb_set_port_feature() errorsHans de Goede2015-05-141-2/+4
| | | | | | | Actually check for usb_set_port_feature() errors and propagate these if they happen. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* dm: usb: Add driver model support for hubsSimon Glass2015-04-181-4/+90
| | | | | | | | Adjust the existing hub code to support driver model, and add a USB driver for hubs. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
* dm: usb: Split hub detection into its own functionSimon Glass2015-04-181-16/+41
| | | | | | | | Split out the hub detection logic so it can be used by driver model. Also adjust the code to return errors correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
* dm: usb: Refactor port resetsSimon Glass2015-04-181-2/+2
| | | | | | | | Move the port reset code into its own function. Rename usb_hub_reset() to indicate that is is now a legacy function. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
* dm: usb: Adjust usb_alloc_new_device() to return an errorSimon Glass2015-04-181-15/+26
| | | | | | | | | | This function returns NULL on error at present. Adjust it so that we can return a real error, as is needed with driver model. Also improve the error handling in its caller, usb_hub_port_connect_change(), and adjust the code order to prepare for driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
* usb: hub: allow pgood_delay to be specified via envTim Harvey2015-04-141-0/+8
| | | | | | | Some USB devices break the spec and require longer warm-up times. Allow the usb_pgood_delay env variable to override the calculated time. Signed-off-by: Tim Harvey <tharvey@gateworks.com>
* linux/kernel.h: sync min, max, min3, max3 macros with LinuxMasahiro Yamada2014-11-231-1/+2
| | | | | | | | | | | | | | | | | | | | 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 <yamada.m@jp.panasonic.com> Acked-by: Pavel Machek <pavel@denx.de> Acked-by: Lukasz Majewski <l.majewski@samsung.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [trini: Fixup arch/blackfin/lib/string.c] Signed-off-by: Tom Rini <trini@ti.com>
* usb: Do not power-cycle usb devices on initHans de Goede2014-11-041-39/+0
| | | | | | | Do as the Linux kernel does and power on any ports which are not yet one, this is enough. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* usb: hub: don't check CONNECTION in hub_port_reset()Stephen Warren2014-08-291-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <swarren@nvidia.com>
* usb: hub: remove CONFIG_USB_HUB_MIN_POWER_ON_DELAYStephen Warren2014-06-011-5/+1
| | | | | | | | | | | | | | | | | 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 <grinberg@compulab.co.il> Cc: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
* usb: hub: fix power good delay timingStephen Warren2014-06-011-3/+6
| | | | | | | | | | | | | | | | | | | 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 <swarren@nvidia.com>
* usb: Use well-known descriptor sizes when parsing configurationJulius Werner2013-08-261-10/+4
| | | | | | | | | | | The existing USB configuration parsing code relies on the descriptors' own length values when reading through the configuration blob. Since the size of those descriptors is always well-defined, we should rather use the known sizes instead of trusting device-provided values to be correct. Also adds some safety to potential out-of-order descriptors. Change-Id: I16f69dfdd6793aa0fe930b5148d4521f3e5c3090 Signed-off-by: Julius Werner <jwerner@chromium.org>
* USB: usb-hub: Add a weak function for resetting devicesDan Murphy2013-08-261-0/+12
| | | | | | | Add a __weak function that can be overridden to reset devices attached to an ehci devices after the FEAT_POWER has been submitted Signed-off-by: Dan Murphy <dmurphy@ti.com>
* usb_hub: fix power cycling logicNikita Kiryanov2013-07-291-2/+2
| | | | | | | | | | | 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 <marex@denx.de> Cc: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-241-19/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* usb: ehci: add Faraday USB 2.0 EHCI supportKuo-Jung Su2013-06-121-1/+6
| | | | | | | | | | | | | | | | | | | 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 <dantesu@faraday-tech.com> CC: Marek Vasut <marex@denx.de>
* usb: hub: make minimum power-on delay configurableKuo-Jung Su2013-06-121-2/+6
| | | | | | | | | | 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 <dantesu@faraday-tech.com> CC: Marek Vasut <marex@denx.de>
* usb: fix: Fixing Port status and feature number constantsVivek Gautam2013-05-061-12/+28
| | | | | | | Fix the Port status bit constants and Port feature number constants as a part of USB 2.0 and USB 3.0 Hub class. Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
* usb: hub: Parallelize power-cycling of root-hub portsVivek Gautam2013-05-061-7/+12
| | | | | | | | | | | | Untill now we power-cycle (aka: disable power on a port and re-enabling again) one port at a time. Delay of 20ms for Port-power to change multiplies with number of ports in this case. So better we parallelize this process: disable power on all ports, wait for port-power to stabilize and then re-enable the power subsequently. Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
* USB: SS: Add support for Super Speed USB interfaceVivek Gautam2013-05-051-2/+6
| | | | | | | | This adds usb framework support for super-speed usb, which will further facilitate to add stack support for xHCI. Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
* usb: hub: Fix enumration timeoutVivek Gautam2013-05-051-1/+0
| | | | | | | | | | | | | | Patch b6d7852c increases timeout for enumeration, taking worst case to be 10 sec. get_timer() api returns timestamp in milliseconds, which is what we are checking in the do-while() loop in usb_hub_configure() (get_timer(start) < CONFIG_SYS_HZ * 10). This should give us a required check for 10 seconds, and thereby we don't need to add additional mdelay of 100 microseconds in each cycle. Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com> Reviewed-by: Vipin Kumar <vipin.kumar@st.com>
* usb: hub: Power-cycle on root-hub portsVivek Gautam2013-05-051-0/+34
| | | | | | | | | XHCI ports are powered on after a H/W reset, however EHCI ports are not. So disabling and re-enabling power on all ports invariably. Signed-off-by: Amar <amarendra.xt@samsung.com> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
* usb: common: Weed out USB_**_PRINTFs from usb frameworkVivek Gautam2013-05-051-88/+74
| | | | | | | | USB_PRINTF, USB_HUB_PRINTF, USB_STOR_PRINTF, USB_KBD_PRINTF are nothing but conditional debug prints, depending on DEBUG. So better remove them and use debug() simply. Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
* usb: Clean up newly allocated device nodes in case of configuration failureMilind Choudhary2012-12-171-0/+2
| | | | | | | | 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 <milindc@codeaurora.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* usbh/ehci: Increase timeout for enumerationVipin Kumar2012-12-171-5/+28
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <vipin.kumar@st.com> Acked-by: Igor Grinberg <grinberg@compulab.co.il>
* usb: lowlevel interface change to support multiple controllersLucas Stach2012-10-151-1/+1
| | | | | | | | | | | Carry an index in the lowlevel usb functions to make specify the respective usb controller. Also pass through an controller struct from lowlevel_init to the creation of the root usb device of this controller. Signed-off-by: Lucas Stach <dev@lynxeye.de> Reviewed-by: Marek Vasut <marex@denx.de>
* usb: do explicit unaligned accessesLucas Stach2012-09-211-5/+9
| | | | | | | | | | | | | | | 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 <dev@lynxeye.de>
* USB: Align buffers at cachelinePuneet Saxena2012-05-201-13/+14
| | | | | | | | | | | | 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 <puneets@nvidia.com> Signed-off-by: Marek Vasut <marex@denx.de>
* usb: replace wait_ms() with mdelay()Mike Frysinger2012-03-191-5/+5
| | | | | | | | | | | | | | | | | | | | | | | 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 <vapier@gentoo.org> Acked-by: Marek Vasut <marex@denx.de>
* USB: relax usbcore reset timingsWolfgang Grandegger2012-03-031-1/+4
| | | | | | | | | | | | Following the corresponding Linux code, this patch relaxes reset timings waiting at least 100ms after power to the ports. There are some reports that it helps make enumeration work better on some high speed devices. Furthermore, the wait is only done once after power has been enabled on all ports. CC: Remy Bohmer <linux@bohmer.net> CC: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Wolfgang Grandegger <wg@denx.de>
* USB: Separate out USB hub driverMarek Vasut2012-03-031-0/+476
Signed-off-by: Marek Vasut <marek.vasut@gmail.com> Cc: Remy Bohmer <linux@bohmer.net> Acked-by: Mike Frysinger <vapier@gentoo.org>
OpenPOWER on IntegriCloud