From sparse:
warning: cast truncates bits from constant value (100 becomes 0)

The DWC3_TRB_NUM constant is too big for u8. Do the calculation a
slightly different way that should still be optimized out for the case
where DWC3_TRB_NUM == 256.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If the trb->enqueue == trb->dequeue, then it could be full or empty.
This could also happen at TRB index 0, so modify the check to handle
that condition. At index 0, the previous TRB is the one just before the
link TRB.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The TRBs left calculation didn't account for the link TRB taking up one
spot.

If the trb_dequeue < trb_enqueue, then the result includes the link
TRB slot so it must be adjusted.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The current calculation takes dep->trb_dequeue - dep->trb_enqueue to
find the TRB space left.

If you enqueue 1, that results in:
(u8) 0 - (u8) 1 = 0xff = 255 TRBs left.

This is correct if DWC3_TRB_NUM == 256.

If DWC3_TRB_NUM is less than 256 (but still a power of 2) you need to
mod the result by DWC3_TRB_NUM.

For example the same calculation with DWC3_TRB_NUM = 8, results in:
255 % 6 = 7 TRBs left.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If trbs_left == 0, we don't have any space left in the TRB ring so don't
prepare anything.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Clears out all the TRBs in the ring to clean up any stale data that
might be in them from the previous time the endpoint was enabled.

Also removed the existing clear of the LINK trb since the entire ring is
cleard just before.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Make the skipping of the link TRBS built-in to the increment operation.
This simplifies the code wherever we increment the trb index and ensures
that we never end up pointing to a link trb.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Cleans up the sparse warning:
warning: dubious: x | !y

Since we do want a bitwise OR here, don't use a logical (true/false)
value. Probably is not a real issue but it cleans up the warning.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Just like we did for endpoint commands, let's have a
single trace output for the command and its
status. This will improve trace readability
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We want commands to finish ASAP, so let's remove
that udelay() call.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Just like we did for endpoint commands, let's use a
single return point for generic commands as
well. This aids readability.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Instead of printing command's status with a separate
trace printout, let's print it within a single call.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

instead of having infinite loop and always checking
timeout value as a break condition, we can just
decrement timeout inside while's condition.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We don't need the extra %s when command fails.
Let's remove it
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

I really thought this would be useful, but as it
turns out, it creates more problems than fixes. The
amount of times we had to fix this because some
other commit shuffled things around and ended up
regressing this tiny little string manupulation...

Might as well remove it, since it has a negligible
added benefit.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This will allow us to process several endpoints at a
time by making sure that we lock only shared
resources.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

this patch implements the most basic pm_runtime
support for dwc3. Whenever USB cable is dettached,
then we will allow core to runtime_suspend.

Runtime suspending will involve completely tearing
down event buffers and require a full soft-reset of
the IP.

Note that a further optimization could be
implemented once we decide to support hibernation,
which is to allow runtime_suspend with cable
connected when bus is in U3. That's subject to a
separate patch, however.
Tested-by: NBaolin Wang <baolin.wang@linaro.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

when we call dwc3_gadget_giveback(), we end up
releasing our controller's lock. Another thread
could get scheduled and disable the endpoint,
subsequently setting dep->endpoint.desc to NULL.

In that case, we would end up dereferencing a NULL
pointer which would result in a Kernel Oops. Let's
avoid the problem by simply returning early if we
have a NULL descriptor.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

commit f3af3651 ("usb: dwc3: gadget: always
enable IOC on bulk/interrupt transfers") ended up
regressing Isochronous endpoints by clearing
DWC3_EP_BUSY flag too early, which resulted in
choppy audio playback over USB.

Fix that by partially reverting original commit and
making sure that we check for isochronous endpoints.

Fixes: f3af3651 ("usb: dwc3: gadget: always enable IOC
		on bulk/interrupt transfers")
Cc: <stable@vger.kernel.org>
Signed-off-by: NKonrad Leszczynski <konrad.leszczynski@intel.com>
Signed-off-by: NRafal Redzimski <rafal.f.redzimski@intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

As a micro-power optimization, let's only resume the
USB2 PHY if we're working on <=HIGHSPEED. If we're
gonna work on SUPERSPEED or SUPERSPEED+, there's no
point in resuming the USB2 PHY.

Fixes: 2b0f11df ("usb: dwc3: gadget: clear SUSPHY bit before ep cmds")
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

by holding gadget's IRQ number in dwc->irq_gadget,
it'll be simpler to free_irq() and disable the IRQ
in case an IRQ fires while we are runtime suspended.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

By adding a pointer to endpoint registers' base
address, we can avoid using our controller-wide
struct dwc3 pointer for everything. At some point
this will allow us to have per-endpoint locks which
will, in turn, let us queue requests to separate
endpoints in parallel.

Because of this change our debugfs interface and io
accessors need to be changed accordingly.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In all call sites of dwc3_send_gadget_ep_cmd() we
already had a valid dep pointer, so instead of
passing dwc and dep->number, which would be used to
fetch the same pointer we already had, just pass dep
directly.

In other words, we're changing:

	struct dwc3_ep *dep = dwc[dep->number];

to just passing struct dwc3_ep *dep as argument.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Instead of using burst size to configure NUMP, we
should be using RxFIFO Size instead. DWC3 is smart
enough to know that it shouldn't burst in case burst
size is 0.
Reported-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

To aid code readability, we're gonna split
__dwc3_gadget_kick_transfer() into its constituent
parts: scatter gather and linear buffers.

That way, it's easier to follow the code and focus
debug effort when one or the other fails.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Instead of returning -EINVAL when someone calls
__dwc3_gadget_wakeup() in speeds > highspeed, let's
return 0. There are no problems for the driver for
calling it in superspeed as we cleanly just return.

This avoids an annoying WARN_ONCE() always
triggering during superspeed enumeration with LPM
enabled.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

When we send an endpoint command, we want that to
complete as soon as possible, so let's remove the
unnecessary udelay(1) call.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

sg_is_last() and list_is_last() will encode the
required information for the driver to make
decisions WRT CHN and LST bits.

While at that, also replace '1' with 'true' for
consistency.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

as it turns out, we don't need the extra 'start_new'
argument as that can be inferred from DWC3_EP_BUSY
flag.

Because of that, we can simplify
__dwc3_gadget_kick_transfer() by quite a bit, even
allowing us to prepare more TRBs unconditionally.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If we're updating transfers, we can also prepare as
many TRBs as we can fit in the ring. Let's start
doing that.

This patch 'solves' a limitation of how many TRBs we
can prepare when we're getting close the end of the
ring. Instead driver to prepare only up to end of
the ring, we check if we have space to wrap around
the ring properly.

Note that this only happens when our enqueue and
dequeue pointers are equal (which is the case for
bulk endpoints after an XferComplete event).
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Instead of trying hard to stay connected to the
host, it's best (and far easier) to disconnect from
the host already.

Anything relying on KEEP_CONNECT will just have that
ignored, but we don't have proper hibernation
implementation yet, so there are no regressions.

In any case, hibernation is only useful for runtime
PM, not system sleep.

While at that, also remove dwc3.dcfg which has been
rendered unnecessary.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

we will be re-using it for suspend/resume, so
instead of duplicating code, let's just re-factor
the functions so they can be re-used.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

As of core revision 2.60a the recommended programming model is to set
the ClearPendIN bit when issuing a Clear Stall EP command for IN
endpoints. This is to prevent an issue where some (non-compliant) hosts
may not send ACK TPs for pending IN transfers due to a mishandled error
condition. Synopsys STAR 9000614252.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that we calculate DCFG.NUMP, we can disable
dwc3's automatic calculation so we maximize our
chances of very high throughtput through the use of
bursts.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

NumP field of DCFG register is used on NumP field of
ACK TP header and it tells the host how many packets
an endpoint can receive before waiting for
synchronization.

Documentation says it should be set to anything
<=bMaxBurst. Interestingly, however, this setting is
not per-endpoint how it should be (different
endpoints could have different burst sizes), but
things seem to work okay right now.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

if Start Transfer command fails, let's try a little
harder to figure out why the command failed and give
slightly better return codes. This will be usefulf
or isochronous endpoints, at least, which could
decide to retry a given request.
Signed-off-by: NKonrad Leszczynski <konrad.leszczynski@intel.com>
Signed-off-by: NRafal Redzimski <rafal.f.redzimski@intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

It makes no sense to interrupt in the middle of
chained transfer. This patch just makes sure we
don't do that.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

trace already adds a newline character for us, we
don't need to do it ourselves.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

instead of limiting link TRB only to Isoc endpoints,
let's use it for all endpoint types, this way we are
more likely to transfer more data before a
XferComplete event.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

By moving our % DWC3_NUM_TRB operation to the
increment helpers, the rest of the driver can be
simplified.

It's also a good practice to make sure we will have
a single place dealing with details about how to
increment our enqueue and dequeue pointers.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>