- 12 Jan, 2009 1 commit
-
-
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:
-
- 08 Jan, 2009 37 commits
-
-
Kevin Hilman authored
Conflicts: drivers/usb/musb/davinci.c
-
Hugo Villeneuve authored
Signed-off-by:
Hugo Villeneuve <hugo@hugovil.com> Signed-off-by:
-
Hugo Villeneuve authored
Signed-off-by:
-
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 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 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 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 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 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 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 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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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 authored
This patch should be merged into the "MAP3: PM: UART: disable clocks when idle" patch for omap-pm-upstream. Signed-off-by: -
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 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 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 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 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 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 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 authored
Learn that the dm355 and dm644x chips have different sets of valid DMA event channels. Those channels are now represented using a bitmap, which is small and much quicker to test than the previous array. MMC1 DMA now works on dm355; it uses channels that dm6446 doesn't. Minor cleanups of the DMA code: spelling/grammar, and marking const data arrays as such. Shrink some data. Signed-off-by:
-
David Brownell authored
More cleanup of DaVinci DMA code: - Make "sparse" ("too many warnings") happy. - Properly register the EDMA device, it's resources, and the driver. - Rename the init call so it's not confused with <asm/mach/dma.h> infrastructure. - It's pointless to bzero BSS data. This is pure housekeeping cleanup, also saving about 50 bytes. Signed-off-by: -
David Brownell authored
Streamline IRQ handling in the DaVinci DMA code: - Indirection (through mis-typed calls, no less!) and deferring registration are pointless. - Don't bother registering the two transfer controller error handlers (or muxing their events, on dm355) so long as they are complete NOPs. Pure cleanup and code shrink (~380 bytes); no functional changes. Signed-off-by:
-
David Brownell authored
Generalize the new mux_cfg code to support interrupt and EDMA event muxing on dm355. Move the MMC0 event mux logic to the device setup code, away from clock enable code where it doesn't belong. Mux the EDMA error interrupts. Signed-off-by:
-
David Brownell authored
Move DM355 MMC/SD pinmux to the device setup code; it shouldn't be coupled to clock activation. This is a small cleanup which doesn't yet support options like not muxing all MMCSD1 pins when they're not needed (e.g. hard-wired to an SDIO WLAN adapter). Signed-off-by:
-
David Brownell authored
Board support for USB on the DM355 EVM. MUSB driver updates are also needed. Signed-off-by:
-
David Brownell authored
Update musb/davinci.c and Kconfig for the newish DM355 chips: - Support new controls: * PHY control bits for swapping D+/D- signals, OTG powerdown * DRVVBUS control bits - The DM355 EVM board swaps D+/D- for better signal integrity - Use clk_enable()/clk_disable() now that they work right Plus some minor cleanup: "void __iomem *" pointers work right now (after some arch/arm changes), the DM6446 EVM stuff vanishes more completely on other boards. Eventually the board-specific stuff should move out of this part of the driver, but that will affect more generic MUSB code. Signed-off-by: -
David Brownell authored
Let's have audio playback not sound like chipmunks, 'k? :) ASP1 on the DM355 EVM uses a 27 MHz external audio clock, not the slower clock used with ASP0 on the DM6446 EVM. Also, that slower ASP0 clock on the DM6446 is 12.288 MHz, not 22.5792 MHz ... 48 KHz sample rate (x256), not a double speed 44.1 KHz sample rate (which could be done, but isn't what the board init code now sets up). Signed-off-by:
-
David Brownell authored
Minor cleanup of gpio init: since the gpio code enables its clock, the PSC code doesn't need to do that too. And when enabling that clock triggers an error, report it in the standard way. Signed-off-by:
-
David Brownell authored
Export davinci_rev() so that users of <mach/cpu.h> CPU test code don't need to be statically linked. Signed-off-by:
-
David Brownell authored
Parent the MII bus properly: it's a child of the EMAC device, not a free-standing beastie. Signed-off-by:
-
- 07 Jan, 2009 1 commit
-
-
Kevin Hilman authored
Rogue bootloaders may enable the modem and thus keep the D2D power- and clock-domains from going into retention. Reset modem on boot to be sure it is in known state. Signed-off-by:
-
