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>

In "usb: dwc3: remove special status request handling in ep0" I simplied
a few things and used the generic API for the status transfers. The bug
I introcuded here is that we queue now requests to dep[1] but we don't
clear that list in the stall+start case.
Actually we don't need to use dep[1] at all. We only did in the past to
talk to the correct endpoint (i.e. in or out). This is now take care of
in a diffent place within the ep0 code. So we could queue the in
transfers to dep[0] and don't use dep[1] at all.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The first access was correct, the second was wrong.
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 ever have an omap with multiple instances of
the DWC3 IP, we need unique names for them. In order
to achieve that, let's use the dwc3_get/put_device_id()
calls to give us an unique device identifier.
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>

The GetStatus (STD)-request is handled the driver and uses a tiny hack
to send the two bytes long answer. This patch removes the custom hack
uses the normal usb_ep_queue() for that.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If we stall and restart we have to reset also this flag to 0 as there is
nothing pending anymore.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

None of these are required atm.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The read and write operation is atomic and we need no locking around
this operations. What we need however is a lock that is held which
ensures that the content of the DWC3_GCTL has not been changed. With
this, the conten may have been change changed after the first but before
our write back.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
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>

Sometimes the host might be trying to initiate Data or
Status phase for an older Control transfer. In such
situations we must STALL that transfer and restart
the state machine rather than letting such situation
go through the wire.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This makes testing a lot easier when trying to
switch between host and device modes.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

I have talked to USB-IF about USB30CV issuing SetAddres()
with a device on Configured state and they have agreed on
changing USB30CV not to do so.

Adding back the STALL reply in such case and while at
that, also add a debugging message for an address which
is too large.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we have host support, we must depend
on both sides.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

host prototypes are there, let's move gadget's
closer.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We can decide in runtime if that will be used
or not.
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>

when we remove the gadget driver, it will already
do that for us.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Without this the gadget will never be able to allocate a stream capable
endpoint. The manual says that the stream id is a 16bit id. It does not
talk about an upper limit in any other way. So I think 15 is a
reasonable limit :)
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>

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>

our parameter structures need to be written to
HW, so instead of assuming little endian, we
convert those into bit shifts.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The dwc3 core has internal clock gating support.

Let's allow that to happen by clearing the disable
bit in GCTL register.
Signed-off-by: NFelipe Balbi <balbi@ti.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>

That structure will hold a copy of readonly
GHWPARAMS* registers for ease accessing by
the driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The following patch adds support for streams
to dwc3 driver.

While at that, also fix one small issue on
endpoint disable where we should clear all
flags not only ENABLED.
Reviewied-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We already have the value from gadget drivers,
just need to pass it to our controller.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix offset calculation in dwc3_trb_dma_offset()
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This makes DWC3_EP_WEDGE do the right thing, which is
prevent DWC3_EP_WEDGE from ever being cleared by a
ClearFeature(HALT) command.

[ balbi@ti.com : allowed set_wedge to send SetHalt command
	to controller ]
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

An older version of the databook said to wait for the FIFO to
drain, but that has been removed from the newer databooks.

Waiting for RxFIFO to drain caused problems when testing against
one of the host controllers available in the market.

After talking to one of the RTL engineers, he stated that we
should _not_ wait for RxFIFO to drain.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

DEPSTARTCFG for non-EP0 EPs must only be sent once per config

[ balbi@ti.com : changed config_start to start_config_issued ]
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
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>

Use "ep0in" and "ep0out" instead "ep1in" and "ep0out" which is confusing
and not consistent with the remaining output.
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 already give requests back in dwc3_ep0_stall_and_restart() so
doing it again here will most likely corrupt the list.
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>

The way it was before was really meaningless.
Now it looks saner.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We don't need to care about direction on a two stage
transfer.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

According to USB 3.0 Specification, a SetAddress()
while device is in Configured State has an unspecified
behavior (see Section 9.4.6). Still USB30CV wasn't
happy with my Stall reply.

To make that thing happy, just accept the SetAddress()
always. No problems have been observed thus far.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>