23 May, 2018
1 commit
-
When unregister gadget driver in ci_udc, the usb device is not
removed or stop. This causes next "usb start" fails to work.Add a new interface "usb_remove_ehci_gadget" in usb-uclass to
remove the usb device for DM driver. Using "usb_lowlevel_stop" for
non-DM driver.Signed-off-by: Ye Li
(cherry picked from commit c73d137e0a4a613a49f6f63ec63332508afb88c0)
01 Oct, 2017
5 commits
-
With the root hub unbinding in usb_stop(), there is no need to do
a Sandbox-specific reset operation. usb_emul_reset() is no longer
used anywhere, drop it.Signed-off-by: Bin Meng
-
This can be useful outside of the sandbox usb emulation uclass
driver. Expose it as a public API with a proper prefix (usb_emul_).Signed-off-by: Bin Meng
-
Current emulator select logic in usb_emul_find_devnum() is to test
the USB address. The USB address of the device being enumerated is
initialized to zero at the beginning of the enumeration process in
usb_setup_device(). At this point, the saved USB address in the
platform data has not been assigned to any valid USB address either.
This means: the logic will select an emulator device according to
its sequence of declaring order in the device tree. Take test.dts
for example, flash-stick@0 will be selected before flash-stick@1.
But unfortunately such logic is wrong.In fact USB devices show up in a random order during the enumeration
which means usb_emul_find_devnum() may be called on port 3 for keyb@3
before on port 0 for flash-stick@0.To fix this, we introduce a new emulator uclass specific platdata
to store the USB device's port number on its parent hub, and update
the logic to test the port number instead.Signed-off-by: Bin Meng
-
There is no such a parameter called 'bus'.
Signed-off-by: Bin Meng
-
This parameter is never used.
Signed-off-by: Bin Meng
27 Sep, 2017
1 commit
-
The HCD may have limitation on the maximum bytes to be transferred
in a USB transfer. USB class driver needs to be aware of this.Signed-off-by: Bin Meng
29 Jul, 2017
6 commits
-
For USB host controllers like xHC, its internal representation of
hub needs to be updated after the hub descriptor is fetched. This
adds a new op that does this.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 -
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 -
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
15 May, 2017
1 commit
-
In order to be able to migrate the various SoC EHCI CONFIG options we
first need to finish the switch from CONFIG_USB_EHCI to
CONFIG_USB_EHCI_HCD.Cc: Marek Vasut
Signed-off-by: Tom Rini
Reviewed-by: Marek Vasut
17 May, 2016
1 commit
-
This function is implemented by the legacy block functions now. Drop it.
Signed-off-by: Simon Glass
23 Mar, 2016
1 commit
-
Signed-off-by: Vagrant Cascadian
Acked-by: Marek Vasut
Reviewed-by: Simon Glass
Reviewed-by: Tom Rini
21 Mar, 2016
1 commit
-
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
15 Mar, 2016
1 commit
-
Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long
and causes 80-column violations, rename it to struct blk_desc.Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
Tested-by: Stephen Warren
08 Jan, 2016
1 commit
-
The current limit of 5 is not enough for the driver model USB tests. Really
we should not have a limit but the driver model code still uses the
usb_dev_desc[] array, which has a limit.Increasing the limit by 2 should not bother anyone. Adjust it.
Signed-off-by: Simon Glass
Reviewed-by: Marek Vasut
31 Dec, 2015
2 commits
-
Start split and complete split tokens need the hub address and the
downstream port of the first HS hub (device view).The core of the function was duplicated in both host/ehci_hcd and
musb-new/usb-compat.h.Signed-off-by: Stefan Brüns
Reviewed-by: Marek Vasut
Reviewed-by: Hans de Goede
Tested-by: Hans de Goede -
The configuration descriptor includes all interface, endpoint and
auxiliary descriptors (e.g. report, union) so 512 bytes may not be enough.Signed-off-by: Stefan Brüns
Reviewed-by: Marek Vasut
Reviewed-by: Simon Glass
20 Nov, 2015
3 commits
-
Allow USB device emulation to support interrupt URBs so that we can use USB
keyboards with sandbox.Signed-off-by: Simon Glass
-
Each USB device has an emulator. Currently this can only be found by
supplying the 'pipe' value, which contains the device number. Add a way
to find it directly from the emulated device.Signed-off-by: Simon Glass
-
Allow the 'usb tree' command to be used from test code, so that we can
verify that it works correctly.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
05 Aug, 2015
1 commit
-
USB-related options are usually prefixed with CONFIG_USB and platform-specific
adaptation for the MUSB controller already have a CONFIG_USB_MUSB prefix, so
this switches all MUSB-related options to a CONFIG_USB_MUSB prefix, for
consistency.Signed-off-by: Paul Kocialkowski
22 Jul, 2015
6 commits
-
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
-
The function documentation is incorrect. Fix it.
Signed-off-by: Simon Glass
Acked-by: Marek Vasut -
Allow usb uclass host drivers to implement usb_reset_root_port, this is
used by single port usb hosts which do not emulate a hub, such as otg
controllers.Signed-off-by: Hans de Goede
Acked-by: Simon Glass -
Add an usb_device parameter to usb_reset_root_port so that it knows which
root-port it is resetting. This is necessary for proper device-model support
for usb_reset_root_port.Also remove a duplicate declaration of usb_reset_root_port() from usb.h .
Signed-off-by: Hans de Goede
Acked-by: Simon Glass -
Drop the unneeded portnr function argument, the portnr is part of the
usb_device struct which is passed via the dev argument.Signed-off-by: Hans de Goede
Acked-by: Simon Glass -
The device-model usb_legacy_port_reset function calls the device-model
usb_port_reset function which is a 1 on 1 copy of the non dm
usb_legacy_port_reset and this is the only use of usb_port_reset in all
of u-boot.Drop both, and alway use the usb_legacy_port_reset() version in
common/usb.c .Also while at it make it static as it is only used in common/usb.c .
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
19 Jun, 2015
1 commit
-
There is no harm in declaring the function prototypes even if nothing
implements them, and when CONFIG_DM_USB=y the various usb functions are
available regardless of any controller drivers being enabled.This fixes compile warnings due to missing prototypes on ARCHs where
the ARCH Kconfig always enables CONFIG_DM_USB and various usb drivers.One could argue that in the case of no controllers CONFIG_DM_USB should not
be set, but this problem is typically seen during bringup of boards which
do actually have usb controllers.Signed-off-by: Hans de Goede
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 -
USB companion controllers must be scanned after the main controller has
been scanned, so that any devices which the main controller which to hand
over to the companion have actually been handed over before we scan the
companion.As there are no guarantees that this will magically happen in the right
order, split the scanning of the buses in 2 phases, first main controllers,
and then companion controllers.Signed-off-by: Hans de Goede
Acked-by: Simon Glass -
Interrupt endpoints typically are polled for a long time by the usb
controller before they return anything, so calls to submit_int_msg() can
take a long time to complete this.To avoid this the u-boot code has the an interrupt queue mechanism / API,
add support for this to the driver-model usb code and implement it for the
dm ehci code.See the added doc comments for more details.
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
06 May, 2015
2 commits
-
Currently we copy over a number of usb_device values stored in the on stack
struct usb_device probed in usb_scan_device() to the final driver-model managed
struct usb_device in usb_child_pre_probe() through usb_device_platdata, and
then call usb_select_config() to fill in the rest.There are 3 problems with this approach:
1) It does not fill in enough fields before calling usb_select_config(),
specifically it does not fill in ep0's maxpacketsize causing a div by zero
exception in the ehci driver.2) It unnecessarily redoes a number of usb requests making usb probing slower
3) Calling usb_select_config() a second time fails on some usb-1 devices
plugged into usb-2 hubs, causing u-boot to not recognize these devices.This commit fixes these issues by removing (*) the usb_select_config() call
from usb_child_pre_probe(), and instead of copying over things field by field
through usb_device_platdata, store a pointer to the in stack usb_device
(which is still valid when usb_child_pre_probe() gets called) and copy
over the entire struct.*) Except for devices which are explictly instantiated through device-tree
rather then discovered through usb_scan_device() such as emulated usb devices
in the sandbox.Signed-off-by: Hans de Goede
Acked-by: Simon Glass -
Make usb_get_bus easier to use for callers, by directly returning the bus
rather then returning it via a pass-by-ref argument.This also removes the error checking from the current callers, as
we already have an assert() for bus not being NULL in usb_get_bus().Signed-off-by: Hans de Goede
Acked-by: Simon Glass
19 Apr, 2015
2 commits
-
With sandbox we want to be able to emulate USB devices so that we can test
the USB stack. Add a uclass to support this. It implements the same
operations as a normal USB device driver, but in this case passes them on
to an emulation driver.Signed-off-by: Simon Glass
Reviewed-by: Marek Vasut -
USB devices in U-Boot are currently probed only after all devices have
been enumerated. Each type of device is probed by custom code, e.g.:- USB storage
- Keyboard
- EthernetWith driver model this approach doesn't work very well. We could build
a picture of the bus and then go back and add the devices later, but
this means that the data structures are incomplete for quite a while.
It also does not follow the model of being able to bind a device when we
discover it.We would prefer to have devices automatically be bound as the device is
enumerated. This allows us to attach drivers to particular USB classes
or product/vendor IDs. This is the method used by Linux.Add the required #defines from Linux, a way of declaring a USB driver and
the logic to locate the correct driver given the USB device's descriptors.Signed-off-by: Simon Glass
Reviewed-by: Marek Vasut