This commit replaces usb_gadget's is_dualspeed field with
a max_speed field.

[ balbi@ti.com : Fixed DWC3 driver ]
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
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>

It's useful to know which states core is going
through, as it might help us figure out misbehavior
on specific link states.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

For now, let's disable IDLE and STANDBY transitions
until we have a real HW to validate against.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This flag will tell us which direction we're
expecting on the next (data or status) phase.

It will help us catching errors of host going
crazy and requesting data of the wrong direction.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

if we don't, the list will be busy forever.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

if req->dma isn't DMA_ADDR_INVALID it means gadget driver
mapped the request or allocated from coherent, so it's
unnecessary to do anything.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

ensure a few bits are cleared before enabling
what we need.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We must ensure that those bits aren't set as
they should only be used in simulation.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

that should be 1 << 16, not 16. Caused so many
problems and we never caught it before.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If the gadget drivers sends a ZLP we are trying to map this this request
which does not work on all implementations. So we simply skip mapping
it.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In order to ACK the IRQ we must write back
to the same register the bits we read.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NFelipe Balbi <balbi@ti.com>

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

trivial patch, no functional changes.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Otherwise that IRQ will trigger forever. It's quite
unnecessary.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

dev_dbg() macro expects a device pointer as
argument, not a memory base address.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Start tracking the next expected event and act
on the error conditions as suggested by databook.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

this field will hold the next expected event.

In certain cases, host might fall into some error
condition and ask from us the wrong Control phase.
On such situations, we should stall and restart.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Whenever we issue a Set Stall command on EP0,
the state machine will be restarted and Stall
is cleared automatically, when core receives
the next SETUP packet.

There's no need to track that EP0_STALL state.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

when we're going to issue Set Stall command,
we should clear DWC3_EP_STALL flag, but also
we should clear BUSY, HALTED and all others.
Signed-off-by: NFelipe Balbi <balbi@ti.com>