summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-davinci/dma.c
Commit message (Collapse)AuthorAgeFilesLines
* arm: mach-davinci: check irq2ctlr() resultKulikov Vasiliy2010-09-241-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | If irq2ctlr() fails return IRQ_NONE. Also as it can fail make 'ctlr' signed. The semantic patch that finds this problem (many false-positive results): (http://coccinelle.lip6.fr/) // <smpl> @ r1 @ identifier f; @@ int f(...) { ... } @@ identifier r1.f; type T; unsigned T x; @@ *x = f(...) ... *x > 0 Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: support for EDMA resource sharingRajashekhara, Sudhakar2010-08-051-1/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current EDMA driver is not taking care of EDMA channels/slots which are allocated from other processor, say DSP. If a channel/slot is allocated from DSP, the existing EDMA driver can still allocate the same resource on ARM. This patch enables the user to pass the channel/slots reserved for DSP as platform data. EDMA driver scans this list during probe and prepares a bitmap of channel/slots which can be used on ARM side. Trying to reserve channels by doing a 'pre-allocate' using edma_alloc_{slot|channel}() API does not work because 1) The reservation should be done in probe() to avoid race with other ARM side driver trying to use EDMA 2) The alloc channel API sets up the access through shadow region 0 which will be incorrect for DSP usage. It also sets up the channel <-> queue number mapping which is not required as DSP will likely do its own mapping anyway. 3) (minor) There is no API to allocate channels in bulk. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: edma: provide ability to detect insufficient CC info dataSekhar Nori2010-08-051-11/+10
| | | | | | | | | | | | | | | | This patch modifies the EDMA driver to expect the channel controller (CC) infomation passed on by the platform as a fixed size (EDMA_MAX_CC) array of pointers to structures. Doing so helps catch errors of the sort where the resource structure has information for more channel controllers than the number channel controller info structures defined. Such insufficient platform data would lead to illegal memory accesses. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: edma: fix coding style issue related to breaking linesSekhar Nori2010-05-131-6/+6
| | | | | | | | | | In the edma driver, most of the long lines in 'if condition' are broken after the logical operator '&&' except two instances. This patch fixes that to bring consistency across the file. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: edma: use BIT() wherever possibleSekhar Nori2010-05-131-21/+21
| | | | | | | | This patch replaces occurences of (1 << x) with BIT(x) as it makes for much better reading. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: edma: fix coding style issue related to usage of bracesSekhar Nori2010-05-061-8/+7
| | | | | | | | | | | | | In the edma driver, there are couple of instances where braces are used for a single statement 'if' construct. There are other instances where 'else' part of the if-else construct does not use braces even if the 'if' part is a multi-line statement. This patch fixes both. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: edma: use a more intuitive name for edma_infoSekhar Nori2010-05-061-81/+77
| | | | | | | | | | | | 'edma_info' structure inside the edma driver represents a single instance of edma channel controller. Call it 'edma_cc' instead. This also avoids readers confusing it with an instance of edma_soc_info structre which carries the platform data for a single channel controller instance. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: edma: clear interrupt status for interrupt enabled channels onlyAnuj Aggarwal2010-05-061-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Currently, the ISR in the EDMA driver clears the pending interrupt for all channels without regard to whether that channel has a registered callback or not. This causes problems for devices like DM355/DM365 where the multimedia accelerator uses EDMA by polling on the interrupt pending bits of some of the EDMA channels. Since these channels are actually allocated through the Linux EDMA driver (by an out-of-kernel module), the same shadow region is used by Linux and accelerator. There a race between the Linux ISR and the polling code running on the accelerator on the IPR (interrupt pending register). This patch fixes the issue by making the ISR clear the interrupts only for those channels which have interrupt enabled. The channels which are allocated for the purpose of being polled on by the accelerator will not have a callback function provided and so will not have IER (interrupt enable register) bits set. Tested on DM365 and OMAP-L137/L138 with audio and MMC/SD (as EDMA users). Signed-off-by: Anuj Aggarwal <anuj.aggarwal@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> CC: Archith John Bency <archith@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* Merge branch 'davinci-fixes-for-linus' of ↵Linus Torvalds2010-04-071-1/+2
|\ | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci * 'davinci-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci: davinci: fix compile warning: <mach/da8xx.h>: #include <linux/platform_device.h> davinci: DM365: fix duplicate default IRQ priorities davinci: edma: clear events in edma_start() davinci: da8xx/omap-l1: fix build error when CONFIG_DAVINCI_MUX is undefined davinci: timers: don't enable timer until clocksource is initialized
| * davinci: edma: clear events in edma_start()Brian Niebuhr2010-04-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an issue where a DMA channel can erroneously process an event generated by a previous transfer. A failure case is where DMA is being used for SPI transmit and receive channels on OMAP L138. In this case there is a single bit that controls all event generation from the SPI peripheral. Therefore it is possible that between when edma_stop() has been called for the transmit channel on a previous transfer and edma_start() is called for the transmit channel on a subsequent transfer, that a transmit event has been generated. The fix is to clear events in edma_start(). This prevents false events from being processed when events are enabled for that channel. Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* | include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-301-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* davinci: build list of unused EDMA events dynamicallySudhakar Rajashekhara2010-02-041-12/+43
| | | | | | | | | | | | | | | | Currently, the edma_noevent list is passed from platform data. But on some architectures, there will be many EDMA channels which will not be used at all. This patch scans all the platform devices and then builds a list of events which are not being used. The unused event list will be used to allocate EDMA channels in case of EDMA_CHANNEL_ANY usage instead of the edma_noevent being used earlier for this purpose. This patch is based on David Brownells's suggestion at http://article.gmane.org/gmane.linux.davinci/15176. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY caseSudhakar Rajashekhara2010-02-041-2/+4
| | | | | | | | | | | Though edma_alloc_channel api was looping through the available channel controllers in EDMA_CHANNEL_ANY case, it was never returning the channel for 2nd channel controller, if 1st channel controller had no free channels. This issue has been fixed with this patch. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: Keep count of channel controllers on a platformSudhakar Rajashekhara2010-02-041-1/+3
| | | | | | | | | | | Some architectures have only one channel controller, but the edma_alloc_channel api loops twice to findout the free channel available in EDMA_CHANNEL_ANY case. A new variable has been introduced to keep count of number of channel controllers being used on a particular architecture. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: Correct return value of edma_alloc_channel apiSudhakar Rajashekhara2010-02-041-1/+1
| | | | | | | | | | | | | Currently, edma_alloc_channel api is returning the channel number without prepending the controller on which the channel was allocated. So, if a channel is allocated on 2nd controller, calls subsequent to edma_alloc_channel would never know that channel was allocated on the 2nd controller, and continue to operate on 1st controller, resulting in edma failure. This patch fixes this issue. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* DaVinci: remove unneeded #include'sSergei Shtylyov2009-11-251-9/+0
| | | | | | | | | | There have accumulated quite a lot of them after the code reorganizations... In several cases I had to replace #include <linux/dma-mapping.h> which wasn't needed directly but happened to #include <linux/err.h> which was needed. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* DaVinci: EDMA: Updating terminlogy in EDMA driverSandeep Paulraj2009-11-251-32/+33
| | | | | | | | | | | | The patch itself does not change the functionality of any existing code. PARAM entries in the present GIT kernel are referred to as slots. New API's being added to the EDMA driver were referring to these PARAM entries as "params". This patch updates the terminolgy used in the EDMA driver. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* DaVinci: EDMA: Fix Bug while obtaining contiguous paramsSandeep Paulraj2009-11-251-8/+24
| | | | | | | | | | | | | The reserve_contiguous_params function is used to reserve a set of contiguous PARAMs. If we do not find a complete set of contiguous PARAMs, the functions still has to free every PARAM that it found to be free in the process of finding a complete set and thus marked as "in use". This patch mainly deals with correctly handling the freeing of PARAMs. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* DaVinci: EDMA: Fix Bug in edma_alloc_cont_slots APISandeep Paulraj2009-11-251-2/+3
| | | | | | | | | | | | | | | | | The edma_alloc_cont_slots API is used for obtaining a set of contiguous slots. When we use the "_ANY" option with this API, by definition of this option it is suppossed to start looking for a set of contiguous slots starting from slot 64 for DaVinci SOC's and 32 for DA8xx SOC's. This has been explained in the API description in the driver itself. So when we use the "_ANY" option with this API, the slot number passed as an argument should be a "don't care". This patch takes care of this condition mentioned above. When checking to see if the starting slot is a valid number, it checks to make sure that the "_ANY" option is not used. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* DaVinci: EDMA: Fix bug in edma_free_cont_slots APISandeep Paulraj2009-11-251-4/+4
| | | | | | | | | In the edma_free_cont_slots API, the variable slot was being modified and then used in the for loop. This results in incorrect behaviour when the API is used. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* DaVinci: EDMA: Adding 2 new APIs for allocating/freeing PARAMsSandeep Paulraj2009-08-261-0/+137
| | | | | | | | | | | | For best performance, codecs often setup linked triggered transfers with a contiguous block of params, and that is when this API is used. Setup/configuration of these parameter RAMs is most efficient if they are contiguous. There is an API to allocate a set of contiguous parameter RAMs and a corresponding API to free a set of contiguous parameter RAMs Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* DaVinci: EDMA: Updating default queue handlingSandeep Paulraj2009-08-261-1/+6
| | | | | | | | | | | | | | | | EDMA queues in DM365 are a little different than those on other DaVinci's. On DM365 Q0 and Q1 have the larger FIFO size. We want Q0 and Q1 to be used by codecs and DVSDK demos. MMC driver is the only driver which uses the flag 'EVENTQ_DEFAULT'. So MMC driver should be using Q2 instead of Q1 on DM365. This patch allows us to declare a "default queue" from SOC specific code. If it is not declared then the EDMA driver assumes a default of queue 1. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: EDMA: multiple CCs, channel mapping and API changesSudhakar Rajashekhara2009-08-261-289/+522
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - restructure to support multiple channel controllers by using additional struct resources for each CC - interface changes visible to EDMA clients Introduce macros to build IDs from controller and channel number, and to extract them. Modify the edma_alloc_slot function to take an extra argument for the controller. Also update ASoC drivers to use API. ASoC changes Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> - Move queue related mappings to dm<soc>.c EDMA in DM355 and DM644x has two transfer controllers while DM646x has four transfer controllers. Moving the queue to tc mapping and queue priority mapping to dm<soc>.c will be helpful to probe these mappings from platform device so that the machine_is_* testing will be avoided. - add channel mapping logic Channel mapping logic is introduced in dm646x EDMA. This implies that there is no fixed association for a channel number to a parameter entry number. In other words, using the DMA channel mapping registers (DCHMAPn), a PaRAM entry can be mapped to any channel. While in the case of dm644x and dm355 there is a fixed mapping between the EDMA channel and Param entry number. Signed-off-by: Naresh Medisetty <naresh@ti.com> Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Reviewed-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* davinci: add EDMA driverKevin Hilman2009-04-271-0/+1135
Original code for 2.6.10 and 2.6.28 series done by Texas Instruments and MontaVista, but major updates and rework done by Troy Kisky and David Brownell. Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Troy Kisky <troy.kisky@boundarydevices.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>