dm: usb: sandbox: Add a driver for sandbox

This driver supports using emulation devices to provide a USB bus within
sandbox.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <

dm: usb: sandbox: Add a driver for sandbox

This driver supports using emulation devices to provide a USB bus within
sandbox.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: sandbox: Reset emulation devices in usb stop()

These devices must have their addresses removed ready for the next USB
bus enumeration. Add this logic to usb_stop().

Signed-off-by: Simon Gl

dm: usb: sandbox: Reset emulation devices in usb stop()

These devices must have their addresses removed ready for the next USB
bus enumeration. Add this logic to usb_stop().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Allow setting up a USB controller as a device/gadget

Some controllers support OTG (on-the-go) where they can operate as either
host or device. The gadget layer in U-Boot supports this.

Whi

dm: usb: Allow setting up a USB controller as a device/gadget

Some controllers support OTG (on-the-go) where they can operate as either
host or device. The gadget layer in U-Boot supports this.

While this layer does not interact with driver model, we can provide a
function which sets up the controller in the correct way. This way the code
at least builds (although it likely will not work).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Bind generic USB devices when there is no driver

At present USB devices with no driver model driver cannot be seen in the
device list, and we fail to set them up correctly. This means they

dm: usb: Bind generic USB devices when there is no driver

At present USB devices with no driver model driver cannot be seen in the
device list, and we fail to set them up correctly. This means they cannot
be used.

While having real drivers that support driver model for all USB devices
is the eventual goal, we are not there yet.

As a stop-gap, add a generic USB driver which is bound when we do not have
a real driver. This allows the device to be set up and shown on the bus.
It also allows ad-hoc code (such as usb_ether) to find these devices and
set them up.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Allow USB drivers to be declared and auto-probed

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.:

dm: usb: Allow USB drivers to be declared and auto-probed

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>

show more ...

dm: usb: Add driver model support to EHCI

Add a way for EHCI controller drivers to support driver model. Drivers can
call ehci_register() to register themselves in their probe() methods.

Signed-off

dm: usb: Add driver model support to EHCI

Add a way for EHCI controller drivers to support driver model. Drivers can
call ehci_register() to register themselves in their probe() methods.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Change ehci_reset() to use a pointer

The index cannot be used with driver model, and isn't needed anyway. Change
the parameter to a pointer.

Signed-off-by: Simon Glass <sjg@chromium.org>
R

dm: usb: Change ehci_reset() to use a pointer

The index cannot be used with driver model, and isn't needed anyway. Change
the parameter to a pointer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Drop the EHCI weak functions

These are a pain with driver model because we might have different EHCI
drivers which want to implement them differently. Now that they use
consistent function

dm: usb: Drop the EHCI weak functions

These are a pain with driver model because we might have different EHCI
drivers which want to implement them differently. Now that they use
consistent function signatures, we can in good conscience move them to
a struct.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Fix non-driver-model EHCI to set up the EHCI operations correctly:
Signed-off-by: Tom Rini <trini@konsulko.com>

show more ...

dm: usb: Refactor EHCI init

Move the bulk of the code in usb_lowlevel_init() into a separate function
which will also be used by driver model. Keep the CONFIG options out of
this function by providi

dm: usb: Refactor EHCI init

Move the bulk of the code in usb_lowlevel_init() into a separate function
which will also be used by driver model. Keep the CONFIG options out of
this function by providing a tweak flag for Faraday. We need to avoid using
CONFIG options in driver model code where possible, since it makes it
impossible to use multiple controllers in that code where they have
different options.

The CONFIG_EHCI_HCD_INIT_AFTER_RESET option is also kept out of the
common init function. With driver model the controller will be able to
perform this extra init itself after registering with the EHCI layer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: ehci: Use a function to find the controller from struct udevice

With driver model we want to remove the controller pointer in struct udevice
and use driver model data structures instead. To

dm: usb: ehci: Use a function to find the controller from struct udevice

With driver model we want to remove the controller pointer in struct udevice
and use driver model data structures instead. To prepare for this, move
access to this field to a function which can provide a different
implementation for driver model.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Pass EHCI controller pointer to ehci_get_portsc_register()

Adjust this function so that it is passed an EHCI controller pointer so that
implementations can look up their controller. This ma

dm: usb: Pass EHCI controller pointer to ehci_get_portsc_register()

Adjust this function so that it is passed an EHCI controller pointer so that
implementations can look up their controller. This makes the weak functions
use a consistent API.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Pass EHCI controller pointer to ehci_set_usbmode()

Adjust this function so that it is passed an EHCI controller pointer so that
implementations can look up their controller. This makes the

dm: usb: Pass EHCI controller pointer to ehci_set_usbmode()

Adjust this function so that it is passed an EHCI controller pointer so that
implementations can look up their controller. This makes the weak functions
use a consistent API.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: tegra: Drop use of global controller variable

We don't need this anymore, so adjust the code to avoid using it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <mare

dm: usb: tegra: Drop use of global controller variable

We don't need this anymore, so adjust the code to avoid using it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Pass EHCI controller pointer to ehci_powerup_fixup()

Adjust this function so that it is passed an EHCI controller pointer so that
implementations can look up their controller.

Signed-off-b

dm: usb: Pass EHCI controller pointer to ehci_powerup_fixup()

Adjust this function so that it is passed an EHCI controller pointer so that
implementations can look up their controller.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: tegra: Store the controller type explicitly

At present the tegra driver uses a separate pointer to know which controller
type is in use. This works because only one controller type is used

dm: usb: tegra: Store the controller type explicitly

At present the tegra driver uses a separate pointer to know which controller
type is in use. This works because only one controller type is used at a
time.

With driver model we want to make the controller state hermetic in the sense
that it is not necessary to look elsewhere to know the controller type. This
will permit a controller to implement the EHCI weak functions without
reference to global data structures.

To achieve this, define an enum for the controller type and store it with
the information on each EHCI controller.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Allow ECHI to hold private data for the controller

Add a private data pointer that clients of EHCI can use to access their
private information. This establishes a link between struct ehci_c

dm: usb: Allow ECHI to hold private data for the controller

Add a private data pointer that clients of EHCI can use to access their
private information. This establishes a link between struct ehci_ctrl and
its associated controller data structure.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Pass EHCI controller pointer to ehci_get_port_speed()

Adjust this function so that it is passed an EHCI controller pointer so that
implementations can look up their controller.

Signed-off-

dm: usb: Pass EHCI controller pointer to ehci_get_port_speed()

Adjust this function so that it is passed an EHCI controller pointer so that
implementations can look up their controller.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Move all the EHCI weak functions together and declare them

Put these at the top of the file so they are in one place. Also add function
prototypes to the header file to avoid call site mism

dm: usb: Move all the EHCI weak functions together and declare them

Put these at the top of the file so they are in one place. Also add function
prototypes to the header file to avoid call site mismatches.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

dm: usb: Add a uclass for USB controllers

Add a uclass that can represent a USB controller. For now we do not create
devices for things attached to the controller. This will be added later.

Signed-

dm: usb: Add a uclass for USB controllers

Add a uclass that can represent a USB controller. For now we do not create
devices for things attached to the controller. This will be added later.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>

show more ...

usb: dwc2: retry NAK'd interrupt transfers

IIUC, interrupt transfers are NAK'd by devices until they wish to trigger
an interrupt, and e.g. EHCI controllers retry these in HW until they are
ACK'd. H

usb: dwc2: retry NAK'd interrupt transfers

IIUC, interrupt transfers are NAK'd by devices until they wish to trigger
an interrupt, and e.g. EHCI controllers retry these in HW until they are
ACK'd. However, DWC2 doesn't seem to retry, so we need to do this in SW.
In practice, I've seen DWC2_HCINT_FRMOVRUN happen too. I'm not quite sure
what this error implies; perhaps it's related to how near the end of a
USB frame we're at when the interrupt transfer is initiated? Anyway,
retrying this temporary error seems to be necessary too.

With all these commits applied, both my USB keyboards (one LS Lenovo and
one FS Dell) work correctly when there is no USB hub between the SoC and
the keyboard; We still need split transactions to be implemented for hubs
to work.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>

show more ...

usb: dwc2: implement interrupt transfers

As best I can tell, there's no difference between bulk and interrupt
transfers in terms of how the HW should be programmed, at least given
that we're executi

usb: dwc2: implement interrupt transfers

As best I can tell, there's no difference between bulk and interrupt
transfers in terms of how the HW should be programmed, at least given
that we're executing one transaction at a time rather than scheduling
them into frames for maximum throughput.

This patch ends up sharing the toggle bit state between bulk and
interrupt transfers on a particular EP. However I believe this is fine;
AFAIK a given EP either uses bulk or interrupt transfers and doesn't mix
them.

This patch doesn't do anything with the "interval" parameter for
interrupt transfers, but then most other USB controller drivers in U-Boot
don't either.

It turns out that one of my keyboards is happy to work using control
transfers but the other only gives non-zero "HID reports" via interrupt
transfers.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>

show more ...

usb: dwc2: correctly program hcchar for LS devices

A bit must be set in HCCHAR when communicating with low-speed devices.
I have no idea why there's no corresponding bit to distinguish between
full-

usb: dwc2: correctly program hcchar for LS devices

A bit must be set in HCCHAR when communicating with low-speed devices.
I have no idea why there's no corresponding bit to distinguish between
full-speed and high-speed devices, but no matter; they all work now!

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>

show more ...

usb: dwc2: detect device speed correctly

This doesn't make my LS keyboard work any better, but it does at least
report the correct speed in "usb tree".

Signed-off-by: Stephen Warren <swarren@wwwdot

usb: dwc2: detect device speed correctly

This doesn't make my LS keyboard work any better, but it does at least
report the correct speed in "usb tree".

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>

show more ...

usb: dwc2: use phys_to_bus/bus_to_phys

Use of these APIs is required on the Raspberry Pi. With this change, USB
on RPi1 should be more reliable, and USB on the RPi2 will start working.

Signed-off-b

usb: dwc2: use phys_to_bus/bus_to_phys

Use of these APIs is required on the Raspberry Pi. With this change, USB
on RPi1 should be more reliable, and USB on the RPi2 will start working.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>

show more ...

usb: dwc2: fix bulk transfers

When I created wait_for_chhltd(), I noticed that some instances of the
code it replaced expected the ACK bit to be set and others didn't. I
assumed this was an accident

usb: dwc2: fix bulk transfers

When I created wait_for_chhltd(), I noticed that some instances of the
code it replaced expected the ACK bit to be set and others didn't. I
assumed this was an accidental inconsistency in the code, so wrote
wait_for_chhltd() to always expect ACK to be set. This code appeared to
work correctly for both enumeration of USB keyboards and operation of
USB Ethernet devices. However, this change broke USB Mass Storage (at
least my USB SD card reader). This change reverts to exactly the
original behaviour. I'm not sure why the ACK bit isn't always set
(perhaps a quirk in the USB HW or DWC2 controller), but the code works
this way!

Fixes: 5be4ca7d6ac8 ("usb: dwc2: unify waiting for transfer completion")
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>

show more ...