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
|