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: Felipe 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: Felipe 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: Felipe 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: Felipe 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: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg 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: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg 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: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg 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: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cache the contents of GHWPARAMS* registers in
our device structure for easy access.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
That structure will hold a copy of readonly
GHWPARAMS* registers for ease accessing by
the driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg 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: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We already have the value from gadget drivers,
just need to pass it to our controller.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg 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: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg 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: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg 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: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.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>
Use "ep0in" and "ep0out" instead "ep1in" and "ep0out" which is confusing
and not consistent with the remaining output.
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>
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: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The way it was before was really meaningless.
Now it looks saner.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We don't need to care about direction on a two stage
transfer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg 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: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg 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: Felipe 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: Felipe 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: Felipe 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: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe 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: 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>
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: Felipe 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: Felipe 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: Felipe Balbi <balbi@ti.com>
There are two spots where we wait until the HW finishes processing a
certain command. Initially we had a few problems and we used 500ms as a
limit to be on a the safe side. Paul Zimmerman mentioned this is little too
much. After a debugging session, we noticed that we hardly ever go over 20us
and didn't pass 30usec so far. Using mdelay() seems way overloaded.
Giving the current numbers 500usec as the upper limit is more than enough.
Should it ever timeout then something is definitely wrong.
While here, also replace the type with u32 since long does not really
fit here.
Cc: Paul Zimmerman <paul.zimmerman@synopsys.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
