History log of /drivers/usb/musb/cppi_dma.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
90ab5ee94171b3e28de6bb42ee30b527014e0be7 13-Jan-2012 Rusty Russell <rusty@rustcorp.com.au> module_param: make bool parameters really bool (drivers & misc)

module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.

Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
/drivers/usb/musb/cppi_dma.c
90802ed9c3dbab2e067bd9fc67a30e66e6774e8f 05-Dec-2011 Paul Bolle <pebolle@tiscali.nl> treewide: Fix comment and string typo 'bufer'

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
/drivers/usb/musb/cppi_dma.c
f847a79ab3c1faca3022061045cd22e4678c1b1c 03-Aug-2011 Per Forlin <per.forlin@linaro.org> usb: musb: cppi: fix build errors due to DBG and missing musb variable

Replace DBG with dev_dbg and fix invalid access of musb->controller.
With this patch cppi_dma builds successfully.

Cc: <stable@kernel.org>
Signed-off-by: Per Forlin <per.forlin@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
/drivers/usb/musb/cppi_dma.c
5c8a86e10a7c164f44537fabdc169fd8b4e7a440 10-May-2011 Felipe Balbi <balbi@ti.com> usb: musb: drop unneeded musb_debug trickery

We have a generic way of enabling/disabling
different debug messages on a driver called
DYNAMIC_PRINTK. Anyone interested in enabling
just part of the debug messages, please read
the documentation under:

Documentation/dynamic-debug-howto.txt

for information on how to use that great
infrastructure.

Signed-off-by: Felipe Balbi <balbi@ti.com>
/drivers/usb/musb/cppi_dma.c
2e10f5e70f670d981f789075e3ebc394f5bb51e3 20-Mar-2011 Dan Carpenter <error27@gmail.com> USB: musb: dereferencing an iomem pointer

"tx_ram" points to io memory. We can't dereference it directly. Sparse
complains about this: "drivers/usb/musb/cppi_dma.c:1205:25: warning:
dereference of noderef expression"

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
/drivers/usb/musb/cppi_dma.c
2fbcf3fa43af809ebf4e4ad33c2f0a17e903385c 20-Mar-2011 Dan Carpenter <error27@gmail.com> USB: musb: silence printk format warning

Gcc gives the following warnings:

drivers/usb/musb/cppi_dma.c: In function ‘cppi_next_tx_segment’:
drivers/usb/musb/cppi_dma.c:600: warning: format ‘%x’ expects type ‘unsigned int’, but argument 8 has type ‘dma_addr_t’
drivers/usb/musb/cppi_dma.c: In function ‘cppi_next_rx_segment’:
drivers/usb/musb/cppi_dma.c:822: warning: format ‘%x’ expects type ‘unsigned int’, but argument 9 has type ‘dma_addr_t’
drivers/usb/musb/cppi_dma.c: In function ‘cppi_rx_scan’:
drivers/usb/musb/cppi_dma.c:1042: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 4 has type ‘dma_addr_t’
drivers/usb/musb/cppi_dma.c:1114: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’

dma_addr_t is sometimes 32 bit and sometimes 64. We normally cast them
to unsigned long long for printk().

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
/drivers/usb/musb/cppi_dma.c
aca7f353219abfb7b8a1530fbba1b1acf0e30da4 20-Mar-2011 Dan Carpenter <error27@gmail.com> USB: musb: using 0 instead of NULL

Sparse complains (and rightly so):
drivers/usb/musb/cppi_dma.c:1458:33:
warning: Using plain integer as NULL pointer

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
/drivers/usb/musb/cppi_dma.c
ec63bf6c06b01ceeb6048a2b9fa9e73060259307 20-Mar-2011 Dan Carpenter <error27@gmail.com> USB: musb: add missing unlock in cppi_interrupt()

We should unlock before returning here.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
/drivers/usb/musb/cppi_dma.c
fcf173e4511193b1efeccb0f22a8c641b464353b 29-Sep-2010 Hema Kalliguddi <hemahk@ti.com> usb: musb: add names for IRQs in structure resource

Soon resource data will get automatically
populated from a set of autogenerated data
from TI's hardware database for the OMAP
platform.

Such database, might not have resources at
the expected order by the current drivers.

While we could hack in some exceptions to
that tool to generate resources in a specific
order, it seems less fragile to use the
resource name instead. That way, no matter
what order the resources are generated, the
driver still work.

Modified the OMAP, Blackfin and Davinci
architecture files to add the name of the IRQs
in the resource structures and musb driver to
use the platform_get_irq_byname() api to get
the device and dma irq numbers instead of using
the index.

Cc: Tony Lindgren <tony@atomide.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
/drivers/usb/musb/cppi_dma.c
2f8d5cd6bcf814411ec356bcdbc666d07bbc6026 24-Sep-2010 Jon Povey <jon.povey@racelogic.co.uk> USB: musb: suppress warning about unused flags

Wrap flags with uninitialized_var() to suppress this:

drivers/usb/musb/cppi_dma.c:1158: warning: 'flags' may be used uninitialized
in this function

Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
/drivers/usb/musb/cppi_dma.c
66af83ddf7b5a4ea94e79cbeadaa0aeed4def5f7 20-Sep-2010 Ming Lei <tom.leiming@gmail.com> usb: musb: gadget: fix dma length in txstate

DMA length should not go beyond the availabe space
of request buffer, so fix it.

Also set max_len of cppi dma channel as max size of
int type, so make musb dma handling happier.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
/drivers/usb/musb/cppi_dma.c
5a0e3ad6af8660be21ca98a971cd00f331318c05 24-Mar-2010 Tejun Heo <tj@kernel.org> include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
/drivers/usb/musb/cppi_dma.c
565969237ab6e73ce7192684d00d5b890ee308fa 28-Dec-2009 Swaminathan S <swami.iyer@ti.com> usb: musb: Fix cppi_channel_abort() function to handle Tx abort correctly

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>
/drivers/usb/musb/cppi_dma.c
93aa3dab008421789aa0f8865a62a52ae13269a3 15-Dec-2009 Swaminathan S <swami.iyer@ti.com> USB: musb: fix for crash in DM646x USB when (CPPI)DMA is enabled

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>
/drivers/usb/musb/cppi_dma.c
8d6499e5bde91ad05dea4f666bdfe79e65e7cf96 17-Nov-2009 Daniel Glöckner <dg@emlix.com> USB: musb: Fix CPPI IRQs not being signaled

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>
/drivers/usb/musb/cppi_dma.c
91e9c4fec7ee777213859aa1a18bf0b885527637 27-Mar-2009 Sergei Shtylyov <sshtylyov@ru.mvista.com> musb: split out CPPI interrupt handler

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>
/drivers/usb/musb/cppi_dma.c
6b6e97107f12f3a9f7b5b43a6c3b94409240bcff 27-Mar-2009 Sergei Shtylyov <sshtylyov@ru.mvista.com> USB: musb: fix isochronous TXDMA (take 2)

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>
/drivers/usb/musb/cppi_dma.c
c7bbc056a92476b3b3d70a8df7cc746ac5d56de7 27-Mar-2009 Sergei Shtylyov <sshtylyov@ru.mvista.com> USB: musb: bugfixes for multi-packet TXDMA support

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>
/drivers/usb/musb/cppi_dma.c
191b776616838f035c2fe7eecc882b5c1f134353 25-Jan-2009 Swaminathan S <swami.iyer@ti.com> USB: musb cppi dma fix

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>
/drivers/usb/musb/cppi_dma.c
704a14854aaf9758a1248ea36a7d1b8cc42a4b3e 25-Jan-2009 Hugo Villeneuve <hugo@hugovil.com> USB: musb cppi bugfixes

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>
/drivers/usb/musb/cppi_dma.c
550a7375fe720924241f0eb76e4a5c1a3eb8c32f 23-Jul-2008 Felipe Balbi <felipe.balbi@nokia.com> USB: Add MUSB and TUSB support

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>
/drivers/usb/musb/cppi_dma.c