We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
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 <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The speed member actually uses an enum, so add this to the comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Rather than keeping the asynchronous schedule running always, keep it
running only across USB mass storage transfers for now, as it seems
that keeping it running all the time interferes with certain control
transfers during device enumeration.
Note that running the async schedule all the time should not be an
issue, especially on EHCI HCD, as that one implements most of the
transfers using async schedule.
Note that we have usb_disable_asynch(), which however is utterly broken.
The usb_disable_asynch() blocks the USB core from doing async transfers
by setting a global flag. The async schedule should however be disabled
per USB controller. Moreover, setting a global flag does not prevent the
controller from using the async schedule, which e.g. the EHCI HCD does.
This patch implements additional callback to the controller, which
permits it to lock the async schedule and keep it running across
multiple transfers. Once the schedule is unlocked, it must also be
disabled. This thus prevents the async schedule from running outside
of the USB mass storage transfers.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Tested-by: Tom Rini <trini@konsulko.com> [omap3_beagle, previously failing]
Move constant USB_KBD_BOOT_REPORT_SIZE. This allows us to reuse it.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
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>
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 <bmeng.cn@gmail.com>
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 <bmeng.cn@gmail.com>
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 <bmeng.cn@gmail.com>
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 <bmeng.cn@gmail.com>
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 <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
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>
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>
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>
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>
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 <marex@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marex@denx.de>
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>
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 <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
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 <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
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 <stefan.bruens@rwth-aachen.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
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 <stefan.bruens@rwth-aachen.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <sjg@chromium.org>
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>
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 <contact@paulk.fr>
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>
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 <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <hdegoede@redhat.com>
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 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 <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
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
- Ethernet
With 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 <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
