27 Nov, 2018
1 commit
-
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
07 May, 2018
1 commit
-
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
28 Apr, 2018
1 commit
-
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
08 Dec, 2017
1 commit
-
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
26 Nov, 2017
1 commit
-
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
Tested-by: Jakob Unterwurzacher
01 Oct, 2017
2 commits
-
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
-
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
16 Aug, 2017
1 commit
-
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
Signed-off-by: Simon Glass
29 Jul, 2017
11 commits
-
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
Reviewed-by: Simon Glass -
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
Reviewed-by: Simon Glass -
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
Reviewed-by: Simon Glass -
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
Reviewed-by: Simon Glass -
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
-
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
Reviewed-by: Simon Glass -
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
Reviewed-by: Simon Glass -
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
Reviewed-by: Simon Glass
Reviewed-by: Stefan Roese
Tested-by: Stefan Roese -
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
Reviewed-by: Simon Glass
Reviewed-by: Stefan Roese
Tested-by: Stefan Roese -
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
Reviewed-by: Simon Glass
Reviewed-by: Stefan Roese
Tested-by: Stefan Roese -
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
