29 Jul, 2017
1 commit
-
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
Reviewed-by: Stefan Roese
Tested-by: Stefan Roese
Tested-by: Dinh Nguyen
04 Jul, 2017
1 commit
-
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
28 Jul, 2016
2 commits
-
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
-
This new function is more convenient for callers, and handles pre-relocation
situations automatically.Signed-off-by: Simon Glass
07 May, 2016
1 commit
-
The code shouldn't continue probing the port if get_port_status() failed.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Hans de Goede
Cc: Stefan Roese
Cc: Stephen Warren
03 May, 2016
1 commit
-
Signed-off-by: Vagrant Cascadian
Reviewed-by: Simon Glass
21 Mar, 2016
3 commits
-
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) foundtime: 20.163 seconds
With this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) foundtime: 1.822 seconds
So ~18.3 seconds of USB scanning time reduction.
Signed-off-by: Stefan Roese
Acked-by: Hans de Goede
Tested-by: Stephen Warren -
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) foundtime: 28.415 seconds
With this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) foundtime: 24.003 seconds
So ~4.5 seconds of USB scanning time reduction.
Signed-off-by: Stefan Roese
Cc: Simon Glass
Acked-by: Hans de Goede
Tested-by: Stephen Warren
Cc: Marek Vasut -
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
Cc: Simon Glass
Acked-by: Hans de Goede
Tested-by: Stephen Warren
Cc: Marek Vasut
20 Nov, 2015
1 commit
-
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
23 Oct, 2015
1 commit
-
The current name is inconsistent with other driver model data access
functions. Rename it and fix up all users.Signed-off-by: Simon Glass
Reviewed-by: Joe Hershberger
12 Sep, 2015
1 commit
-
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
05 Aug, 2015
1 commit
-
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
Cc: Simon Glass
Cc: Hans de Goede
22 Jul, 2015
1 commit
-
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
15 May, 2015
3 commits
-
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
Reviewed-by: Stefan Reinauer
Tested-by: Stefan Reinauer
Signed-off-by: Simon Glass -
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
-
Actually check for usb_set_port_feature() errors and propagate these if they
happen.Signed-off-by: Hans de Goede
19 Apr, 2015
4 commits
-
Adjust the existing hub code to support driver model, and add a USB driver
for hubs.Signed-off-by: Simon Glass
Reviewed-by: Marek Vasut -
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
Reviewed-by: Marek Vasut -
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
Reviewed-by: Marek Vasut -
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
Reviewed-by: Marek Vasut
14 Apr, 2015
1 commit
-
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
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
argumentSigned-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
04 Nov, 2014
1 commit
-
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
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 1The 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 coreThis 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
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 -
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
27 Aug, 2013
2 commits
-
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 -
Add a __weak function that can be overridden to reset devices
attached to an ehci devices after the FEAT_POWER has been submittedSigned-off-by: Dan Murphy
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
24 Jul, 2013
1 commit
-
Signed-off-by: Wolfgang Denk
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini
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 -
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
06 May, 2013
6 commits
-
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
-
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
-
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
Signed-off-by: Vivek Gautam -
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
Reviewed-by: Vipin Kumar -
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
Signed-off-by: Vivek Gautam -
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
17 Dec, 2012
1 commit
-
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
