This patch fixes the Tx abort/teardown logic. We now wait for the teardown
completion interrupt and acknowledge the same by setting the tx_complete
register to 0.
This change is needed to ensure that abort processing works on DM365 platform.
Without this change after completion of abort processing the system is
overwhelmed with continuous stream of abort interrupts.
This change has been tested on all CPPI3.x platforms (DM644x, DM646x, DM35x,
DM36x).
Signed-off-by: Swaminathan S <swami.iyer@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Race condition exists between the cppi_interrupt handler and
davinci_interrupt handler w.r.t completing a TX IO. Since DM646x
has seperate DMA and USB endpoint interrupts cppi_interrupt handler
needs to hold the lock while operating on the endpoint.
Update over previous patch to avoid taking the lock if already
taken. Tested on DM644x, DM355 and DM646x platforms.
Signed-off-by: Swaminathan S <swami.iyer@ti.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On tx channel abort a cppi interrupt is generated for a short time by
setting the lowest bit of the TCPPICOMPPTR register. It is then reset
immediately by clearing the bit. When the interrupt handler is run,
it does not detect an interrupt in the TCPPIMSKSR or RCPPIMSKSR
registers and thus exits early without writing the TCPPIEOIR register.
It appears that this inhibits further cppi interrupts until the handler
is called by chance, f.ex. from davinci_interrupt().
By moving the unmasking of the interrupt below the writes to
TCPPICOMPPTR, no interrupt is generated and no write to TCPPIEOIR is
necessary.
Signed-off-by: Daniel Glöckner <dg@emlix.com>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
As DaVinci DM646x has a dedicated CPPI DMA interrupt, replace
cppi_completion() (which has always been kind of layering
violation) by a complete CPPI interrupt handler.
[ dbrownell@users.sourceforge.net: only cppi_dma.c needs platform
device header, not cppi_dma.h ]
Signed-off-by: Dmitry Krivoschekov <dkrivoschekov@ru.mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Multi-frame isochronous TX URBs transfers in DMA mode never
complete with CPPI DMA because musb_host_tx() doesn't restart
DMA on the second frame, only emitting a debug message.
With Inventra DMA they complete, but in PIO mode. To fix:
- Factor out programming of the DMA transfer from
musb_ep_program() into musb_tx_dma_program();
- Reorder the code at the end of musb_host_tx() to
facilitate the fallback to PIO iff DMA fails;
- Handle the buffer offset consistently for both
PIO and DMA modes;
- Add an argument to musb_ep_program() for the same
reason (it only worked correctly with non-zero
offset of the first frame in PIO mode);
- Set the completed isochronous frame descriptor's
'actual_length' and 'status' fields correctly in
DMA mode.
Also, since CPPI reportedly doesn't like sending isochronous
packets in the RNDIS mode, change the criterion for this
mode to be used only for multi-packet transfers. (There's
no need for that mode in the single-packet case anyway.)
[ dbrownell@users.sourceforge.net: split comment paragraph
into bullet list, shrink patch delta, style tweaks ]
Signed-off-by: Pavel Kiryukhin <pkiryukhin@ru.mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We really want to use DMA mode 1 for all multi-packet transfers;
that's one IRQ on DMA completion, instead of one per packet.
There is an important issue with such transfers, especially on
the host side: when such transfers end with a full-size packet,
we must defer musb_dma_completion() calls until the FIFO empties.
Else we report URB completions too soon, and may clobber data in
the FIFO fifo when writing the next packet (losing data).
The Inventra DMA support uses DMA mode 1, but it ignores that
issue. The CPPI DMA support uses mode 0, but doesn't handle
its TXPKTRDY interrupts quite right either; it can get stale
"packet ready" interrupts, and report transfer completion too
early using slightly different code paths, also losing data.
So I'm solving it in a generic way -- by adding a sort of the
"interrupt filter" into musb_host_tx(), catching these cases
where a DMA completion IRQ doesn't suffice and removing some
needlessly controller-specific logic. When a TXDMA interrupt
happens and DMA request mode 1 is active, that filter resets
to mode 0 and defers URB completion processing until TXPKTRDY,
unless the FIFO is already empty. Related filtering logic in
Inventra and CPPI code gets removed.
Since it should be competely safe now to use the DMA request
mode 1 for host side transfers with the CPPI DMA controller,
set it in musb_h_tx_dma_start() ... now renamed (and shared).
[ dbrownell@users.sourceforge.net: don't introduce more
CamElCase; use more concise explanations ]
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Initializes the actual_len field to 0 before every DMA transaction.
Signed-off-by: Swaminathan S <swami.iyer@ti.com>
Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
These compilation errors are related to incorrect
debugging macro and variable names and generated the
following errors:
drivers/usb/musb/cppi_dma.c:437:5: warning: "MUSB_DEBUG" is not defined
drivers/usb/musb/cppi_dma.c: In function 'cppi_next_rx_segment':
drivers/usb/musb/cppi_dma.c:884: error: 'debug' undeclared (first use in this function)
Signed-off-by: Hugo Villeneuve <hugo@hugovil.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for MUSB and TUSB controllers
integrated into omap2430 and davinci. It also adds support
for external tusb6010 controller.
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>