Commit Graph

70 Commits

Author SHA1 Message Date
Simon Glass
c05ed00afb common: Drop linux/delay.h from common header
Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 21:19:23 -04:00
Simon Glass
f7ae49fc4f common: Drop log.h from common header
Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 21:19:18 -04:00
Simon Glass
336d4615f8 dm: core: Create a new header file for 'compat' features
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.

Move the compatibility features into a separate header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-02-05 19:33:46 -07:00
Simon Glass
7b51b576d6 env: Move env_get() to env.h
Move env_get() over to the new header file.

Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
2019-08-11 16:43:41 -04:00
Ismael Luceno Cortes
51f60a89b7 usb: Make portspeed return a read-only string
Current code is plain wrong, and there's no need to have a mutable string,
so fix function type and remove the intermediate variable.

Signed-off-by: Ismael Luceno <ismael.luceno@silicon-gears.com>
2019-04-09 13:11:45 +02:00
Sven Schwermer
fd09c205fc usb: s/CONFIG_DM_USB/CONFIG_IS_ENABLED(DM_USB)/
This allows to disable the USB driver model in SPL because it checks
the CONFIG_SPL_DM_USB variable for SPL builds. Nothing changes for
regular non-SPL builds.

Signed-off-by: Sven Schwermer <sven@svenschwermer.de>
2018-11-26 21:19:03 +01:00
Tom Rini
83d290c56f SPDX: Convert all of our single license tags to Linux Kernel style
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-07 09:34:12 -04:00
Tom Rini
d024236e5a Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTR
We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-04-27 14:54:48 -04:00
Simon Glass
0ad0458c76 usb: Correct use of debug()
With clang this gives a warning because hubsts appears to be used before
it is set, even if ultimately it is not used. Simplify the code to avoid
this problem.

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-12-07 15:17:00 -05:00
Philipp Tomsich
883946e8e7 usb: hub: identify the hub-device to usb_hub_reset_devices
When usb_hub_reset_devices is called, it should be passed both an
indicator which hub it should operate on and what port number (local
to that hub) should be reset.

Previously, the usb_hub.c code did not include such context and
always started resets from port number 1, performing multiple
reset-requests for the same devices:

       /*
        * Reset any devices that may be in a bad state when applying
        * the power.  This is a __weak function.  Resetting of the devices
        * should occur in the board file of the device.
        */
       for (i = 0; i < dev->maxchild; i++)
              usb_hub_reset_devices(i + 1);

This adds an additional 'hub' parameter to usb_hub_reset_devices
that provides the context to fully qualify the port-number in.

Existing implementations are changed to accept and ignore the new
parameter.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
2017-11-26 02:22:36 +01:00
Bin Meng
061895fbe5 usb: hub: Clear BH reset status change for a 3.0 hub
USB 3.0 hubs report bit[5] in the port status change response as BH
reset. The hub shall set the C_BH_PORT_RESET field for this port.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2017-10-01 16:32:54 +02:00
Bin Meng
b90203526f usb: hub: Clear port reset before usb_hub_port_connect_change()
During usb_hub_port_connect_change(), a port reset set feature
request is issued to the port, and later a port reset clear feature
is done to the same port before the function returns. However at
the end of usb_scan_port(), we attempt to clear port reset again
on a cached port status change variable, which should not be done.

Adjust the call to clear port reset to right before the call to
usb_hub_port_connect_change().

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2017-10-01 16:32:54 +02:00
Simon Glass
00caae6d47 env: Rename getenv/_f() to env_get()
We are now using an env_ prefix for environment functions. Rename these
two functions for consistency. Also add function comments in common.h.

Quite a few places use getenv() in a condition context, provoking a
warning from checkpatch. These are fixed up in this patch also.

Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-16 08:30:24 -04:00
Bin Meng
81060bb1c0 usb: hub: Call usb_update_hub_device() after hub descriptor is fetched
After fetching hub descriptor, we need to call USB uclass operation
update_hub_device() to notify HCD to do some preparation work.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-07-28 23:34:35 +02:00
Bin Meng
5624dfd5aa usb: hub: Parse and save TT details from device descriptor
A high speed hub has a special responsibility to handle full speed/
low speed devices connected on downstream ports. In this case, the
hub must isolate the high speed signaling environment from the full
speed/low speed signaling environment with the help of Transaction
Translator (TT). TT details are provided by hub descriptors and we
parse and save it to hub uclass_priv for later use.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-07-28 23:34:34 +02:00
Bin Meng
bbc6f06c00 usb: hub: Support 'set hub depth' request for USB 3.0 hubs
USB 3.0 hub uses a hub depth value multiplied by four as an offset
into the 'route string' to locate the bits it uses to determine the
downstream port number. We shall set the hub depth value of a USB
3.0 hub after it is configured.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-07-28 23:34:32 +02:00
Bin Meng
74ffc7cbb1 usb: hub: Translate USB 3.0 hub port status into old version
USB 3.0 hub port status field has different bit positions from 2.0
hubs. Since U-Boot only understands the old version, translate the
new one into the old one.

Since we are going to add USB 3.0 hub support, this feature is only
available with driver model USB.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-07-28 23:34:31 +02:00
Bin Meng
46c1d49330 usb: hub: Add a new API to test if a hub device is root hub
Sometimes we need know if a given hub device is root hub or not.
Add a new API to test this. This removes the xHCI driver's own
version is_root_hub() and change to use the new API.

While we are here, remove the unused/commented out get_usb_device()
in the xHCI driver too.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2017-07-28 23:34:30 +02:00
Bin Meng
a199a72448 usb: hub: Remove hub_port_reset()
At present hub_port_reset() is defined in DM USB, but it is never
called hence remove it (removing another ifdefs).

While we are here, change legacy_hub_port_reset() name to
usb_hub_port_reset() to better match other function names in the
same hub module.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-07-28 23:34:30 +02:00
Bin Meng
dfa96e0676 usb: hub: Use 'struct usb_hub_device' as hub device's uclass_priv
Use USB hub device's dev->uclass_priv to point to 'usb_hub_device'
so that with driver model usb_hub_reset() and usb_hub_allocate()
are no longer needed.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-07-28 23:34:29 +02:00
Bin Meng
337fc7e665 usb: hub: Change USB hub descriptor to match USB 3.0 hubs
USB 3.0 hubs have a slightly different hub descriptor than USB 2.0
hubs, with a fixed (rather than variable length) size. Change the
host controller drivers that access those last two fields
(DeviceRemovable and PortPowerCtrlMask) to use the union.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
2017-07-28 23:34:20 +02:00
Bin Meng
53771a490e usb: hub: Revise wLength for 'get port status' request
For accuracy, we should use 'sizeof(struct usb_port_status)' as the
wLength for 'get port status' request, although it happens to be
equal to 'sizeof(struct usb_hub_status)'.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
2017-07-28 23:34:19 +02:00
Bin Meng
f342119602 usb: hub: Send correct wValue to get hub descriptor of a USB 3.0 hub
Testing a USB 3.0 hub by connecting it to the xHCI port on Intel
MinnowMax, when issuing 'get hub descriptor' to the hub, xHCI
reports a transfer event TRB with a completion code 6 which means
'Stall Error'.

In fact super speed USB hub descriptor type is 0x2a, not 0x29.
Sending correct SETUP packet to the hub makes it not stall anymore.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
2017-07-28 23:34:18 +02:00
Bin Meng
f7a9e5dd03 usb: hub: Update handling connect status/change in usb_scan_port()
It was observed that on Intel MinnowMax board, when xHCI is enabled
in the BayTrail SoC, with a USB 3.0 device connected to the bottom
USB 3.0 port (mapped to xHCI root port #7), its PORTSC register is
always 0x201203 (CCS = 1, CSC = 0). The root cause of such behavior
is unknown yet. Connect status change bit is set on the same port
with a USB 2.0 device (mapped to xHCI port #1, which is a different
port on the root hub).

With current logic in usb_scan_port(), the enumeration process will
abort if it does not detect a connect status change on a hub port.
However since a device connection status is correctly reported, the
enumeration process can still continue.

With this change, USB device connected to the bottom blue port on
MinnowMax board can be enumerated under either SS or HS mode.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Dinh Nguyen <dinguyen@kernel.org>
2017-07-28 23:34:18 +02:00
Heiko Schocher
98f705c9ce powerpc: remove 4xx support
There was for long time no activity in the 4xx area.
We need to go further and convert to Kconfig, but it
turned out, nobody is interested anymore in 4xx,
so remove it.

Signed-off-by: Heiko Schocher <hs@denx.de>
2017-07-03 17:35:28 -04:00
Simon Glass
911954859d dm: Use dm_scan_fdt_dev() directly where possible
Quite a few places have a bind() method which just calls dm_scan_fdt_dev().
We may as well call dm_scan_fdt_dev() directly. Update the code to do this.

Signed-off-by: Simon Glass <sjg@chromium.org>
2016-07-27 14:15:54 -06:00
Simon Glass
2e3f1ff63f dm: Convert users from dm_scan_fdt_node() to dm_scan_fdt_dev()
This new function is more convenient for callers, and handles pre-relocation
situations automatically.

Signed-off-by: Simon Glass <sjg@chromium.org>
2016-07-27 14:15:07 -06:00
Marek Vasut
d81db48d41 usb: hub: Don't continue on get_port_status failure
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>
2016-05-06 20:06:56 +02:00
Vagrant Cascadian
eae4b2b67b Fix spelling of "occurred".
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
2016-05-02 18:37:09 -04:00
Stefan Roese
c998da0d67 usb: Change power-on / scanning timeout handling
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>
2016-03-20 18:00:45 +01:00
Stefan Roese
2ef117fe4f usb: Remove 200 ms delay in usb_hub_port_connect_change()
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>
2016-03-20 18:00:44 +01:00
Stefan Roese
f7f601002d usb: legacy_hub_port_reset(): Speedup hub reset handling
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>
2016-03-20 18:00:44 +01:00
Simon Glass
3884c98c32 dm: usb: Avoid time delays in sandbox tests
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>
2015-11-19 20:27:50 -07:00
Simon Glass
bcbe3d1579 dm: Rename dev_get_parentdata() to dev_get_parent_priv()
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>
2015-10-23 09:42:28 -06:00
Simon Glass
cf92e05c01 Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h header
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>
2015-09-11 17:15:20 -04:00
Marek Vasut
dcc7dbc731 usb: Fix device detection code
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>
2015-08-05 17:22:43 +02:00
Simon Glass
abb59cffcf dm: usb: Adjust the USB_DEVICE() macro naming
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>
2015-07-21 17:39:40 -06:00
Vincent Palatin
08f3bb0bcd usb: add device connection/disconnection detection
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>
2015-05-14 18:49:33 -06:00
Hans de Goede
45b9ea1da2 usb: Stop reset procedure when a dev is handed over to a companion hcd
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>
2015-05-14 18:49:31 -06:00
Hans de Goede
ad84a42fc5 usb: legacy_hub_port_reset() check and propagate usb_set_port_feature() errors
Actually check for usb_set_port_feature() errors and propagate these if they
happen.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-05-14 18:49:30 -06:00
Simon Glass
054fe48eb2 dm: usb: Add driver model support for hubs
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>
2015-04-18 11:11:21 -06:00
Simon Glass
361ad6afc4 dm: usb: Split hub detection into its own function
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>
2015-04-18 11:11:21 -06:00
Simon Glass
862e75c0db dm: usb: Refactor port resets
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>
2015-04-18 11:11:20 -06:00
Simon Glass
79b5888729 dm: usb: Adjust usb_alloc_new_device() to return an error
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>
2015-04-18 11:11:20 -06:00
Tim Harvey
319418c01c usb: hub: allow pgood_delay to be specified via env
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>
2015-04-14 05:47:48 +02:00
Masahiro Yamada
b41411954d linux/kernel.h: sync min, max, min3, max3 macros with Linux
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>
2014-11-23 06:48:30 -05:00
Hans de Goede
0834bb2fb0 usb: Do not power-cycle usb devices on init
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>
2014-11-04 06:03:59 +01:00
Stephen Warren
74c0d756de usb: hub: don't check CONNECTION in hub_port_reset()
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>
2014-08-29 11:27:43 +02:00
Stephen Warren
77b83e6d09 usb: hub: remove CONFIG_USB_HUB_MIN_POWER_ON_DELAY
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>
2014-06-01 19:20:07 +02:00
Stephen Warren
0d437bcaf9 usb: hub: fix power good delay timing
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>
2014-06-01 19:19:16 +02:00