These files uses the full set of MODULE_ macros and so need to
include module.h directly.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg 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: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
dwc3-wrapper can be used by any other wrapper,
using dwc3-omap makes it clear that we're running
on OMAP SoC.
Signed-off-by: Felipe Balbi <balbi@ti.com>
The OMAP wrapper allows us to either control internal
OTG signals via SW or HW. Different boards might wish
to use one or the other mode of operation. Let's have
have that information passed via platform_data for now.
After DT conversion is finished for OMAP, we can easily
convert this to a DT attribute.
Signed-off-by: Felipe Balbi <balbi@ti.com>
We need to have actual HW in order to implement
and test that part of the code anyway. Until then
it's best to remove it.
Signed-off-by: Felipe 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=2
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paul Gortmaker