There are two where need to set operational mode:
- during initialization while we decide to run in host,device or DRD
  mode
- at runtime via the debugfs interface.

This patch provides a new function which sets the operational mode and
moves its initialiation to the mode switch instead in the gadget code
itself.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

hardware will tell us how many event buffers we
need to support, so let's allocate the array
dynamically too.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

if we want to support situations where we have
both SoC and PCIe versions of the IP on the same
platform, we need to have sequential numbers between
them, otherwise we will still have name collisions.

Because of that, we need to move dwc3_get/put_device_id()
to core.c and export that symbol to be used by glue
layers.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We can have three modules here: dwc3.ko, dwc3-omap.ko and dwc3-pci.ko.
The later have already ids-aliases for probing and is fine. The omap
module has alias for DT but lacks alias for the "native"
platform_device. Maybe we should get rid of it and stick to the DT name?
Both glue modules create a new device for which the dwc3.ko module is
responsible and that one lacks the platform alias.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The Designware USB3 IP can be configured with
an internal xHCI. If we're running on such a
version, let's start the xHCI stack.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

There's no need to add driver_data for something
we can fetch from HW.

This also makes our id_table unnecessary - at least
for now -, so we also remove it on the same patch.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This will allow us to only allocate memory when
we actually need.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

this is mainly for testing. In order to be able
to test if we're enumerating correctly on all
speeds, let that be controlled by a module
parameter.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

These files uses the full set of MODULE_ macros and so need to
include module.h directly.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

cache the contents of GHWPARAMS* registers in
our device structure for easy access.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Some people think that this line is not compatible with the GPL. The
statement was required due to the Buenos Aires Convention and is now
deprecated. I remove it because it is said that it is pointless nowdays.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We need that header because of THIS_MODULE.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We read the DWC3_GSNPSID register to make sure we got the correct
register offset passed. One of the recent commits moved the soft reset
before this so in case of the wrong offset we end up with "reset timed
out". This patch moves the "id" check before the reset again.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The DesignWare USB3 is a highly
configurable IP Core which can be
instantiated as Dual-Role Device (DRD),
Peripheral Only and Host Only (XHCI)
configurations.

Several other parameters can be configured
like amount of FIFO space, amount of TX and
RX endpoints, amount of Host Interrupters,
etc.

The current driver has been validated with
a virtual model of version 1.73a of that core
and with an FPGA burned with version 1.83a
of the DRD core. We have support for PCIe
bus, which is used on FPGA prototyping, and
for the OMAP5, more adaptation (or glue)
layers can be easily added and the driver
is half prepared to handle any possible
configuration the HW engineer has chosen
considering we have the information on
one of the GHWPARAMS registers to do
runtime checking of certain features.

More runtime checks can, and should, be added
in order to make this driver even more flexible
with regards to number of endpoints, FIFO sizes,
transfer types, etc.

While this supports only the device side, for
now, we will add support for Host side (xHCI -
see the updated series Sebastian has sent [1])
and OTG after we have it all stabilized.

[1] http://marc.info/?l=linux-usb&m=131341992020339&w=2Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>