- 19 Jan, 2009 6 commits
-
-
David Brownell authored
This patch primarily renames functions to use an edma_ prefix and remove a needless infix "_dma_" token ... except that "src_params" became "src", and "dest_params" became "dest". Parameters which identify parameter RAM slots were renamed as "slot" from "lch". Also, the slot numbers become unsigned (supporting a minor code shrink), and a handful of needless temporary variables were removed. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
These functions now only accept channels, since reload slots can never be independently active. Change parameter to unsinged, to allow a minor code shrink. Remove pointless foof in edma_stop(): the channel's parameter RAM slot must be reinitialized, so there is no reason to modify it unless chaining is being misused; and just updating the link register can't protect aginst chain bugs. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
EDMA interface update for channel and parameter RAM slot alloc/free. This is the biggest of these changes, since it's non-cosmetic. - Stop talking about "master" and "slave"! Instead, use the notions exposed by the hardware: a DMA "channel", and a PaRAM slot. This is a general doc/comment update, and affects calling conventions. - Split davinci_request_dma() into two simpler routines: * edma_alloc_channel() with three fewer parameters * edma_alloc_slot() with just one parameter (may be a wildcard) The test for successful returns is "value < 0", not "value != 0"; non-negative values are the returned channel or slot number. - Split davinci_free_dma() into two routines, both of which update the now-free parameter RAM slot to hold a dummy transfer. * void edma_free_channel(unsigned channel) * void edma_free_slot(unsigned slot); - Fill all PaRAM slots with dummy transfers when they're not in use. - Change the channel and slot numbers to "unsigned" in some cases so we can avoid some tests for invalid parameters. A key notion here is to *stop* fuzzing distinctions between DMA channels and parameter RAM slots. This makes it easier to match these calls to hardware docs, and harder to get confused by differences; channels are (potentially) active, while slots are always passive. Transfer Completion Code (TCC) values are no longer supported except through the calls which manipulate entire parameter RAM sets. This means that completion IRQ setup (for audio) is a bit different. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Another EDMA interface update. Fixes documentation for the linking calls to be kerneldoc style. Rename parameters so they're meaningful (from/to vs lch/lch_que) and unsigned (eliminates some error checks). Remove unused edma_unlink() parameter. Move this code so it's grouped with the other calls which only modify parameter RAM. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
This renames two parameter RAM calls that read and write entire param sets, and re-focusses their descriptions on the fact that they update parameter RAM. That has nothing *directly* to do with any hardware DMA channel. Switch to unsigned params, letting some error checks be removed. It also starts updating the dma.c comments to reflect the different structural blocks of the programming interface, calling out the two groups of parameter RAM operations and channel control operations. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Chaithrika U S authored
This patch defines debug macros for low-level debugging for Davinci based platforms Tested on : - DM644x DaVinci EVM - DM646X DaVinciHD EVM - DM355 EVM This patch attempts to solve the low-level debug issue in DM646x. The UART on DM646x SoC allows only 32-bit access. The existing debug-macro.S uses the macros from debug-8250.S file. This led to garbage serial out in the case of DM646x. The inclusion of debug-8250.S does not allow for run time fix for this issue. There are compile time errors due to multiple definitions of the macros. Also when building a single image for multiple DaVinci Platforms, the ifdefs cannot be relied upon. The solution below does not include the debug-8250.S file and defines the necessary macros. This solution was arrived at after observing that word access does not affect the low-level debug messages on DM644x/DM355. The other approach to this issue is to use the UART module information available in the peripheral registers to decide the access mechanism. But this will have to be done for every access of UART specifically for DM646x. Also this calls for a modification of the debug-8250.S file. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
- 16 Jan, 2009 5 commits
-
-
Hugo Villeneuve authored
Signed-off-by: Hugo Villeneuve <hugo@hugovil.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Hugo Villeneuve authored
Signed-off-by: Hugo Villeneuve <hugo@hugovil.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Hugo Villeneuve authored
In <asm/mach-types.h>, the SFFSDR board is defined as MACH_SFFSDR. Signed-off-by: Hugo Villeneuve <hugo@hugovil.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Whoops -- dm6446 can't clock MMC as fast as dm355 can. Don't tempt it. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Address feedback from Dmitry: - input_sync() per event - maintain dev->keybit when remapping keys - since we handle remapping, keycodemax and keycodesize aren't used - on probe error, don't input_free_device() unless it registered Also: - avoid reporting excess events - more bad-parameter paranoia in the remapping code The excess event issue is basically that we don't have a way to distinguish "button press" events from "button release" ones or autorepeat events, so we should try being a bit smarter about synthesizing them. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
- 12 Jan, 2009 2 commits
-
-
David Brownell authored
Finish removing the typedef from the EDMA programming interface. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Split DMA transfer setup in two parts: template setup, where all of the stable transfer parameters get arranged; and transfer setup, where the template is populated with the right buffer. Later, the template is used with each scatterlist segment. (Minor runtime code shrink.) Disable transfer completion IRQs; we don't use them, there's no point in wasting time in the IRQ handling stack. We only care about DMA callbacks for error detection. (Minor runtime speedup.) Stop using the typedef for "struct edmacc_param". Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
- 09 Jan, 2009 1 commit
-
-
Kevin Hilman authored
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
- 08 Jan, 2009 26 commits
-
-
Kevin Hilman authored
Conflicts: drivers/usb/musb/davinci.c
-
Hugo Villeneuve authored
Signed-off-by: Hugo Villeneuve <hugo@hugovil.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Hugo Villeneuve authored
Signed-off-by: Hugo Villeneuve <hugo@hugovil.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Use memcpy_{from,to}io() to read and write entire parameter RAM slots, saving a surprising 268 bytes over the existing code. Renames those parameters to be more sensible than "temp". Fix a minor glitch and ensure all DMA channels are initialized with a dummy transfer with all options zeroed, so it's not possible to accidentally start getting intermediate completion callbacks or event chaining by accident. Save eight bytes while doing that. Shrink davinci_stop_dma() by not testing if the bits are already cleared; if they were, clearing again is harmless. And shrink map_dmach_queue() by avoiding a superfluous test. EDMA runtime code footprint is now under 2700 bytes, and there are still further cleanups that could be done... Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Mr. Grep reports that the EDMA chain/unchain calls are unused. Same in the old 2.6.10 code; there seems to be no value in those routines. Delete! Saves a few bytes. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Lots of simple code cleanup for EDMA: - KernelDoc updates (biggest part by volume): fixes; keep only one copy of the function description, next to its definition; convert most function descriptions to kerneldoc. - Message fixup in EDMA support: use just newline, not CRNL; use %08x for 32 bit values. - Comment a couple fault handling glitches, and fix one. - Change parameters of the davinci_set_dma_{src,dest}_index() and davinci_set_dma_transfer_params() functions to use explicit widths (s16, u16) not implicit (short, unsigned short). - Switch davinci_set_dma_{src,dest}_params() to use dma_addr_t for DMA addresses. No functional changes here, except insisting that davinci_stop_dma() do nothing unless it's given a valid DMA channel. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
More cleanup: - We don't actually need "dma_chan[X].param_no", since we can always write "X" instead. Remove "param_no". - That means dma_chan[] itself can go. Yay! - A few more arrays can be __initconst. - Comment updates: make the top look normal, add section markers. - Stop using that typedef internally. - Sanity checked #defines for edmacc_param.opt: remove three bits that are reserved/zero in documentation, line up the others. Except for the "in use" bitmask and the IRQ callback data, there doesn't need to be much DMA driver state outside of EDMA registers and parameter RAM. Saves about 700 bytes of space, mostly data. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Remove some significant duplication: - We only need a single bitmap to record which PARAM slots are in use, and it only needs to have enough bits to cover the slots that exist. - By using the atomic bitops for that, we eliminate the current need for a private spinlock. - We don't need to record 'tcc' either, it's only needed inside davinci_request_dma(). Remove it: be clearer and more correct (it can change with PARAM operations), save space. This change highlighted some existing bugs in terms of fault returns when davinci_request_dma() couldn't return a resource of the relevant type; unlikely for anyone to have hit them, so far. Switch to standard kerneldoc for davinci_request_dma(). The two previous descriptive comments were inconsistent, so fix that too. Explain the callback usage a bit. Minor new feature: allow explicit allocation of slave channels too, allowing pre-allocation of *any* DMA channel on behalf of DSP code. This saves about 2 KB of space (half is data) as well as making allocation and deallocation code a LOT simpler. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
More EDMA misfeature removal: - Static bitmask for channels allocated for DSP. There may be no DSP, and different DSP firmware may use different channels. To allocate a channel for a DSP, davinci_request_dma() works. - A similar bit mask of PARAM slots, which oddly enough had four times as many entries as PARAM slots. - Unused fields in the dma_chan[] data structure: * "dma_running" was completely unused * "dev_id" was only written, never read * "link_lch" was only (sometimes!) written, never read In the future it might be worth providing some init mechanism to preallocate channels for the DSP firmware that's used, so master channels can't be modified from the shadow region used by the ARM. (That is, *after* there's DSP support in DaVinci GIT kernels...) Saves about 1.7 KBytes, mostly data from the unused fields. (Each field wasted 512 bytes.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Remove more needless complexity from the EDMA code: the bitmap recording whether a given master channel's IRQ is in use. This is redundant with respect to the flag saying whether that channel is itself in use. Plus minor bugfixes: actually disable the IRQ; scrub out old IRQ status before enabling; handle TCC more consistently. Saves about 270 bytes. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Remove the QDMA hooks from the Linux EDMA code. No Linux code in the DaVinci GIT tree or the latest DVSDK code from MV/TI needs QDMA, so it's just a needless mechanism cluttering this code and complicating a merge to mainline. QDMA likely deserves a new programming interface anyway. Saves about 1400 bytes of object code. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
Paul Walmsley authored
The McBSP driver uses virtual clocks to handle enabling and disabling its hardware clocks. These virtual clocks have no associated clockdomain. After commit 60b8b431, this prevents the McBSP clocks from registering correctly. Resolve this for the short term by using virt_opp_clkdm for these clocks. These McBSP virtual clocks should be removed, but such a fix would require significant changes to the McBSP drivers that would require testing on OMAP1, 2, and 3 platforms. Tested on 2430SDP and 3430SDP GP ES2.1. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Eero Nurkkala <ext-eero.nurkkala@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Josh Karabin authored
This patch adds support for detecting NAND flash on OMAP3 EVM boards. It clones similar code from the 3430 SDP board files. Signed-off-by: Josh Karabin <gkarabin@vocollect.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Eero Nurkkala authored
The prescalers for 100 kHz and 400 kHz mode are wrong for omap 3430 and omap 2430. The internal clock is the fclock divided by the prescaler. The PSC is an 8 bit field in omap3430 and omap2430. Moreover, the scll and sclh values should be adjusted properly. Having the correct prescaler is important in the process of getting a finite i2c clock. In addition, the prescaler is used in the process of activating the correct noise filter and thus, lets more error resilient i2c communications. Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Eero Nurkkala authored
The number of bytes to be received is read from wrong place with all OMAPs with highspeed I2C support, which involves a FIFO and BUFSTAT_REG. It is the 6 bits starting from the bit 8 in the BUFSTAT_REG that indicate this amount of bytes to be read. Moreover, only the 6 LSB:s are relevant for the TXSTAT field. Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Anand Gadiyar authored
Bug in existing code causes synchro control to be set +32 if request line greater than 63 is used. Reported by Wenbiao Wang Signed-off-by: Anand Gadiyar <gadiyar@ti.com> +++ linux-omap-2.6/arch/arm/plat-omap/dma.c 2009-01-08 14:44:46.000000000 +0200 @@ -279,10 +279,7 @@ void omap_set_dma_transfer_params(int lc val = dma_read(CCR(lch)); val &= ~(3 << 19); - if (dma_trigger > 63) - val |= 1 << 20; - if (dma_trigger > 31) - val |= 1 << 19; + val |= ((dma_trigger & ~(0x1f)) << 14); val &= ~(0x1f); val |= (dma_trigger & 0x1f); Signed-off-by: Tony Lindgren <tony@atomide.com>
-
matti.halme@nokia.com authored
A triggering RTC alarm should be able to power on a device that has been powered off. This patch enables that on twl4030 by not masking the alarm interrupt at shutdown. Signed-off-by: Matti Halme <matti.halme@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Manikandan Pillai authored
Default MUX configurations for GPIO on OMAP3 EVM boards are added. Fixed for "_UP" naming convention for GPIOs comment. Signed-off-by: Manikandan Pillai <mani.pillai@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
This patch should be merged into the "MAP3: PM: UART: disable clocks when idle" patch for omap-pm-upstream. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
David Brownell authored
Rip out the old semi-broken support for DMA channel linkage, in preparation for replacing it with something more capable. Performance is fine if CONFIG_MMC_BLOCK_BOUNCE is enabled, although that bounce buffer wastes memory and CPU time. (In fact it's probably faster than trying to use the dma chaining code this patch removes.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Fix several problems uncovered by the mmc_test driver, so most tests pass (for DMA and for PIO) except two for unusual size block reads. - Resolve a DMA test hang by removing most of the remaining (undesirable) cmd->opcode -specfic handlng. - Remove an oops in an IRQ handler message for a CRC error. - Never report data read timeout errors as command errors. - On data phase termination, clean up more carefully: always abort exactly once, always send any STOP command, only set the transfer length on success paths - Handle shared data phase error reporting paths for writes: both CRC and timeout errors get the same IRQ. We seem to be able to distinguish them using the MMCDRSP register though. Plus semi-related fixes: - Have some IRQ messages use the correct version of "status". - Comment some bits of the PIO logic and data. This still wimps out on reporting correct data transfer lengths after faults; it should use the MMCNBLC register. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Simplify mmc_davinci_send_dma_request() by relying on constraints provided through its call stack. Document those constraints a bit better. Lift the unnecessary constraint that blocks not cross scatterlist segments. If we handle multi-segment transfers at all, there's no need for such a restriction. (This is a code shrink that *should* change no behavior.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Start cleaning up mmc_davinci_send_dma_request(): - Partial cleanup of variables * remove several of the needless ones * match hardware types: + unsigned 16-bit types for a/b/c counts + signed 16-bit types src/dst b/c offsets + unsigned 32-bit types for src/dst addresses - Add some comments summarizing how EDMA is used for each scatterlist segment. This is just a code shrink and simplification. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Get rid of some needless symbol duplication: - Use MMCST0_* symbols for both MMCST0 (irq status) and MMCIM (irq mask) registers. - Use MMCST0_* symbols instead of MMCSD_EVENT_* enums; the enum names obfuscated code with respect to chip specs. - Use mmc_resp_type() directly; RSP_TYPE() isn't needed. Also: - Switch the MMCST0_* symbols to the more compact BIT() syntax, and add matching "what does this do?" comments. - Use the already-defined MMCCMD_* symbols, not magic numbers. - Remove obsolete lament about protocol layer not providing something which it now provides. Minor functional changes that shouldn't affect behavior, and were suggested by the above changes: - Don't enable read IRQs when writing data, and vice versa. - Shrink the PIO loop in the IRQ handler. Overall, this code should now be easier to cross-check against specs and thus more clear in several ways. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
Minor MMC cleanup, mostly for DMA: - Tighten some parts of scatterlist handling: * switch to a NR_SG parameter (like other drivers), and use it to disable some code; * make max_seg_size reflect the EDMA limit (usually 2 MBytes) not the controller's multiblock request limit (64x bigger); * use standard scatterlist accessors. - Use more section annotations to shrink runtime driver footprint. - Fix whitespace glitches and remove an unused struct member, both left over from the "rip out 1/4..." patch. - Move some bits of code earlier, to simplify later patches. - Fix a few messages to terminate properly, with just a newline. - Report -EIO for DMA errors. There should be at most very minor functional changes here. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-
David Brownell authored
In place of a FIXME, enable high speed SD (and MMC) support. I've seen comfortably more than 6 MByte/sec with "hdparm -tT". Plus minor fixes: cleanly fall back to PIO if for some reason DMA init fails; report the *actual* mode (DMA/PIO) not the one that was attempted; use more conventional labels in /proc/iomem; and remove an end-of-line whitespace. Note that on the DM355 EVM cards won't clock over 27 MHz since the functional clock is at 108 MHz, and the divider doesn't allow a divide-by-three. Hmm, the MMC controller specs say that it only supports up to 100 MHz for a functional clock... Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
-