- 08 Jan, 2009 23 commits
-
-
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 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:
-
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:
-
- 20 Dec, 2008 1 commit
-
-
Sudhakar Rajashekhara authored
Generalizes dm644x pinmux. The existing pinmux layer works only when the PINMUX register has single bit field to enable the secondary function. DM646x can support secondary as well as tertiary pin functions. This new pinmux layer is similar to the one being used by OMAP architecture. Checkpatch script reports a false positive error at line no.465 of this patch. This patch is based on the work originally done by Vladimir Barinov, when he was in MontaVista. Signed-off-by:
Sudhakar Rajashekhara <sudhakar.raj@ti.com> Acked-by:
-
- 18 Dec, 2008 9 commits
-
-
Troy Kisky authored
Commit 178bb537 (use __raw_writel) introduced a bug in davinci_set_dma_params and davinci_get_dma_params. I forgot about CCNT. Signed-off-by:
Troy Kisky <troy.kisky@boundarydevices.com> Signed-off-by:
-
David Brownell authored
Let musb_hdrc on DaVinci use the clock framework, now that it seems to work right. * add USBCLK to dm644x support (it's already there for dm355) * only enable it when the driver asks for that * make the musb_hdrc driver use that clock The original failures seem to have been caused by really buggy code implementing the clock APIs. Now they're working right. Signed-off-by:
-
David Brownell authored
Fix an init sequence bug with the MUSB driver on a DaVinci EVM: don't initialize it until after the pcf8574 GPIO expander is ready. This prevent oopsing. And since the DaVinci GPIOs have been renumbered ... use the new number for the GPIO on that pcf8574 chip. (Eventually that number should be passed through platform_data to the driver.) Signed-off-by:
-
Troy Kisky authored
Fix remaining checkpatch problems. Signed-off-by:
-
David Brownell authored
Make sure that PHYLIB is selected along with TI_DAVINCI_EMAC, to prevent link errors. Signed-off-by:
-
David Brownell authored
Don't register the EMAC device except on chips that have one. Fix lots of goofy whitespace with the EMAC setup. Signed-off-by:
-
David Brownell authored
A "cat /proc/iomem" showed why mmc0 is now broken on dm355: 01e00000-01e00fff : davinci_mmc.1 01e00000-01e00fff : davinci_mmc 01e10000-01e10fff : davinci_mmc.0 01e10000-01e10fff : davinci_nand 01e10000-01e10fff : davinci_mmc 02000000-03ffffff : davinci_nand What was the MMC0 controller address on dm6446 chips is the AEMIF control register bank on dm355 chips, used by the NAND driver. Use the right address, and now MMC0 works. (In PIO mode, and with that ASM-to-C conversion patch reverted.) And for that matter, the dm9000 starts working again. Win! Maybe the NAND driver will be happier too... Signed-off-by: -
Kevin Hilman authored
This reverts commit 5912086e. Signed-off-by:
-
Sudhakar Rajashekhara authored
Fixes the 2.6.28-rc8-davinci1 booting on dm646x EVM. davinci_psc_init is not being called for DM646x EVM, hence davinci_psc_mux is not defined for DM646x. This is resulting in DM646x board not booting up. Signed-off-by:
-
- 16 Dec, 2008 7 commits
-
-
David Brownell authored
Partially parameterize the ALE and CLE masks; there's a bunch of other stuff that should come from platform_data too, but this patch doesn't change that stuff. While we're doing this ... fix the related "sparse" errors. Signed-off-by:
-
David Brownell authored
Start splitting out the board-specific NAND support better, by having board-specific flash init functions. DM355 EVM has a newer and faster chip. It's still in the wrong place, but at least it's better factored now ... which will help later when it's moved to the board-*.c files. (NOTE: sffsdr support is missing; it might not actually need to set the EMIF A1CR register.) Also update the header comment slightly, listing key assumptions made by this driver ... and delete a broken comment in the dm6446 setup code, that's not the value it was writing. Signed-off-by:
-
David Brownell authored
Update/bugfix hardware ECC config handling. The driver should still be able to build without that support enabled (else remove its Kconfig option!); remove frowned-upon inline #ifdeffery. Also suffix all the original ECC logic with _1bit to distinguish it from the DM355's enhanced ECC hardware (corrects 4 single-bit errors per 512 bytes), which should get good support. Note that I think the issue with flash access on the DM355 EVM is likely to be ECC related. Specifically, the original LSP uses that enhanced ECC hardware, and thus needs 10 bytes of data per 512 byte block ... which seems to be stored INLINE rather than in the OOB region, because of a Linux restriction to 32 bytes of ECC data. (One hopes that restriction gets lifted ASAP.) Signed-off-by:
-
David Brownell authored
Update/bugfix partition config handling. This removes some inlines in the body of the driver, bugfixes cmdlinepart handling, bugfixes the "no partitions" cases, and cleans up properly on driver removal. Yes, these bugs are common in MTD drivers; I think the MTD framework should eventually get help, maybe like this, to help un-obfuscate drivers (which almost all have such #ifdeffery today). Signed-off-by:
-
David Brownell authored
Speed up transfers between NAND and RAM by using the io{read,write}*_rep() calls to replace a more limited read-only I/O loop. On a similar arm926 board this gave a significant speedup (ISTR 16%) in a userspace "dd" benchmark. Also add a comment explaining some key assumptions (wiring) this makes. Signed-off-by: -
Felipe Balbi authored
That define was only used for polling for card presence, which now we let mmc core do it in a more reliable way. No need to keep that define here. Signed-off-by:
Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by:
-
Felipe Balbi authored
There's no need for a file included only once, remove it and move the register definition to davinci_mmc.c. Signed-off-by:
-
