- 11 Dec, 2008 29 commits
-
-
Troy Kisky authored
Change %d to %x in dev_dbg prints. Signed-off-by:
Troy Kisky <troy.kisky@boundarydevices.com> Signed-off-by:
Kevin Hilman <khilman@deeprootsystems.com>
-
Troy Kisky authored
Use arrays to simplify code Signed-off-by:
-
Troy Kisky authored
Improve the readability of the code. Signed-off-by:
-
Troy Kisky authored
davinci_start_dma should return -EINVAL instead of EINVAL. Signed-off-by:
-
Troy Kisky authored
Use macro DAVINCI_EDMA_IS_Q to make code easier to read Signed-off-by:
-
Troy Kisky authored
In request_dma_interrupt, set the irq parameters before enabling the interrupt. Signed-off-by:
-
Troy Kisky authored
A copy/paste bug causes missed dma events 32-63 (i.e. underrun) to be missed. Signed-off-by:
-
Troy Kisky authored
This patch removes reads of the following registers: esr, esrh, eesr, eesrh, iesr, iesrh, qeesr are write 1 to set registers ecr, ecrh, eecr, eecrh, emcr, emcrh, icr, icrh, secr, secrh, ccerrclr, qeecr, qemcr, qsecr, are write 1 to clear registers Signed-off-by:
-
Chaithrika U S authored
Adds LSI ET1011C PHY driver. This driver is used by TI DM646x EVM. Signed-off-by:
Chaithrika U S <chaithrika@ti.com> Signed-off-by:
-
David Brownell authored
Remove remnants of an old OSS-audio-for-DaVinci patch, which tried to make some OMAP-specific AIC23 code do double duty as DaVinci AIC33 codec support. Nowadays there's sane ASoC support for both AIC23 and AIC33 codecs, and there seems to be no need for this OSS remnant. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Kevin Hilman authored
This reverts commit 2a899dac. Oops, removed omap version instead of davinci version.
-
David Brownell authored
Update DM6466 EVM to support the new MMC board config data. This provides a miniature I2C driver in the board-dm644x-evm.c file ... unusual, but it does make it easier to pass the key information easily to the MMC driver. There's no attempt to use the gpio_to_irq(GPIO(7)) signals that are issued when the various card detect signals change, or when the IR remote sends a command. Signed-off-by:
-
David Brownell authored
Inital support for new MMC init logic, where boards can say how to initialize what, and also provide functions to sense card detect and writeprotect switches. This also removes some static driver configuration forcing it to always use 4-bit parallel data channels; boards can now override that. This patch stubs in support for the two EVM boards with MMC/SD support, equivalent to current behavior ... later patches will update these. SFFSDR presumably needs something too. Note that this doesn't currently handle card detect IRQs. Signed-off-by:
-
David Brownell authored
Sure would be nice to have the watchdog device node created, so the watchdog driver (already in mainline) binds to something. Signed-off-by:
-
David Brownell authored
Finish basic updates to let the DaVinci MMC driver talk to the second MMC controller on dm355: - Update the MMC driver to use clk_get() correctly * use logical "mmc" clockname * fix its error handling logic (!) - Bugfixes to probe(): * call mmc_add_host() only *after* everything is set up * check for mmc_add_host() errors * call request_irq() only after the host was added * start timer polling only after the host was added - And some cosmetic bits: * use more modern timer setup calls * request_irq() says mmc0 or mmc1, matching custom So now it comes up on both MMC controllers, and starts collecting interrupts on the second ... so there's progress. But it can't see a card in either slot of a dm355 yet. Signed-off-by: -
David Brownell authored
Update the davinci_mmc driver to stop hard-wiring use of mmc0 DMA channels: look them up during probe, record them, and use the recorded values everywhere, not constants. Add a previously-missing diagnostic if probe() fails. Also fix a seeming bug in the rarely-used davinci_abort_dma() call. It was aborting the wrong channel ... the idle one, not the active one. Signed-off-by:
-
David Brownell authored
Update MMC/SD device initialization to handle more chips, in particular the DM355 with its second MMC/SD controller: - Chip-specific stuff: * dm646x chips have no MMC * if this is a dm355, declare the second controller - Completeness/correctness: * use new davinci_clk_associate(), clockname "mmc" * provide DMA channel resources * provide SDIO IRQ resources * device numbering starts from zero, not one - Claim enough I/O space for all mmc/sd registers ... in fact, the whole page that's being ioremapped! Note that this doesn't address the basic problem that there's no way now for board init code to say which controllers to initialize, or how to do so. Seems to not be an issue for any of the boards currently in the DaVinci GIT tree. Signed-off-by: -
David Brownell authored
Update the DaVinci clock framework to handle clk_get(dev, name) better, adding davinci_clk_associate() method letting logical names be associated with devices. This lets drivers move away from using "physical" clock names, which are changed in new chip versions and by adding more controller instances. Plus a few unrelated fixes to the DM355 clock tree: it doesn't have IDE or EMAC, or their clocks, so don't list them. But it does have two more SPI controllers ... list them instead. Signed-off-by:
-
David Brownell authored
Teach the "davinci-evm" ASoC support to handle both DM6446 and DM355 EVM boards by recognizing which board they're using, then setting up appropropriately. The only particularly ugly bit here is clock handling, where we need to "know" the right clock name to use. This solution is simple, but may not work on some yet-to-be-seen boards that would want "McBSPCLK0". Note that this includes a minor bugfix: now that DaVinci kernels can support multiple boards, board-specific ASoC components need to verify they're running on the right board before initializing. Signed-off-by:
-
David Brownell authored
Generalize the psc_mux() stuff to stop assuming there are only DM6446 chips, and specifically to handle things the DM355 EVM will need: SPI0, MMC0, MMC1, ASP1. Note that I think the clock framework (PSC) and pinmux framework really ought to be properly separated. The pinmux stuff seems like it should fit well into devices-dmXXX.c logic, with boards declaring what device they use and how they're configured. That works cleanly on other platforms. Likewise with muxing IRQ and EDMA channels. Do it all as part of device setup. (And maybe let it be reconfigured at runtime for oddball systems.) Signed-off-by:
-
David Brownell authored
The DaVinci <mach/mcbsp.h> is full of useless stuff: (a) It's used with chips that don't *have* a McBSP; instead, they have an ASP. (b) Most of the registers and utilities apply to nothing I can find. Not ASP; not the McBSP on chips like dm642. Replace with <mach/asp.h> since these DaVinci chips *do* have one or more ASP modules. Signed-off-by: -
David Brownell authored
Minor bugfix: now that DaVinci kernels can support multiple boards, board-specific ASoC components need to verify they're running on the right board before initializing. Signed-off-by:
-
David Brownell authored
Remove remnants of an old OSS-audio-for-DaVinci patch, which tried to make some OMAP-specific AIC23 code do double duty as DaVinci AIC33 codec support. Nowadays there's sane ASoC support for both AIC23 and AIC33 codecs, and there seems to be no need for this OSS remnant. Signed-off-by:
-
David Brownell authored
Let the DM355 EVM use its dm9000 ethernet controller; just declare it. Relies on the patch fixing GPIO IRQs. Signed-off-by:
-
David Brownell authored
Simple input driver support for the events reported by the MSP430 firmware on the DM355 EVM. Verified using the remote included with the kit; docs weren't quite right. Some of the keycode selections might need improvement; I'm hoping I implemented the remapping support right, so there's at least a runtime workaround. Keys on the remote seem to repeat undesirably. Someone might want to see what's up with that, and fix it; it might just be an issue of tracking RC5 state and using the toggle. Signed-off-by:
-
David Brownell authored
Simple RTC driver for the MSP430 firmware on the DM355 EVM board. Other than not supporting atomic reads/writes of all four bytes, this is quite reasonable as a basic no-alarm RTC. Signed-off-by:
-
David Brownell authored
Board support for the dm355evm_msp MFD driver. This provides I2C initialization for new-style drivers, as used by that MFD driver and by mainline drivers for this board's audio and video codecs. It also updates the I2C bus to use 400 kHz. The 20 kHz value was leftover from the DM6446 EVM, where the msp430 used an execrable bit-banged I2C implementation. The msp430 on the DM355 EVM uses hardware I2C, and appears to have no such problems. Signed-off-by:
-
David Brownell authored
Basic MFD framework for the MSP430 microcontroller firmware used on the dm355evm board: - Provides an interface for other drivers: register read/write utilities, and register declarations. - Directly exports: * Many signals through the GPIO framework + LEDs + SW6 through gpio sysfs + NTSC/nPAL jumper through gpio sysfs + ... more could be added later, e.g. MMC signals * Child devices: + LEDs, via leds-gpio child (and default triggers) + RTC, via rtc-dm355evm child device + Buttons and IR control, via dm355evm_keys - Supports power-off system call. Use the reset button to power the board back up; the power supply LED will be on, but the MSP430 waits to re-activate the regulators. - On probe() this: * Announces firmware revision * Turns off the banked LEDs * Exports the resources noted above * Hooks the power-off support * Muxes tvp5146 -or- imager for video input Unless the new tvp514x driver (tracked for mainline) is configured, this assumes that some custom imager driver handles video-in. This completely ignores the registers reporting the output voltages on the various power supplies. Someone could add a hwmon interface if that seems useful. Signed-off-by: -
David Brownell authored
Update the DaVinci GPIO code to work better on non-dm6446 parts, notably the dm355: - Only handle the number of GPIOs the chip actually has. So for example on dm6467, GPIO-42 is the last GPIO, and trying to use GPIO-43 now fails cleanly; or GPIO-72 on dm6446. - Enable GPIO interrupts on each 16-bit GPIO-irq bank ... previously, only the first five were enabled, so GPIO-80 and above (on dm355) wouldn't trigger IRQs. - Use the right IRQ for each GPIO bank. The wrong values were used for dm355 chips, so GPIO IRQs got routed incorrectly. - Handle up to four pairs of 16-bit GPIO banks ... previously only three were handled, so accessing GPIO-96 and up (e.g. on dm355) would oops. - Update several comments that were dm6446-specific. Verified by receiving GPIO-1 (dm9000) and GPIO-5 (msp430) IRQs on the DM355 EVM. One thing this doesn't do is handle the way some of the GPIO numbers on dm6467 are reserved but aren't valid as GPIOs. Some bitmap logic could fix that if needed. Signed-off-by:
-
- 22 Nov, 2008 2 commits
-
-
Kevin Hilman authored
-
Kevin Hilman authored
Signed-off-by:
-
- 21 Nov, 2008 9 commits
-
-
Paul Walmsley authored
During _omap3_noncore_dpll_lock(), if a DPLL has no active downstream clocks and DPLL autoidle is enabled, the DPLL may never lock, since it will enter autoidle immediately. To resolve this, disable DPLL autoidle while locking the DPLL, and unconditionally wait for the DPLL to lock. This fixes some bugs where the kernel would hang when returning from retention or return the wrong rate for the DPLL. This patch is a collaboration with Peter de Schrijver <peter.de-schrijver@nokia.com> and Kevin Hilman <khilman@deeprootsystems.com>. Signed-off-by:
Paul Walmsley <paul@pwsan.com> Cc: Peter de Schrijver <peter.de-schrijver@nokia.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
The DPLL FREQSEL jitter correction bits are set based on a table in the 34xx TRM, Table 4-38, according to the DPLL's internal clock frequency "Fint." Several Fint frequency ranges are missing from this table. Previously, we allowed these Fint frequency ranges to be selected in the rate rounding code, but did not change the FREQSEL bits. Correspondence with the OMAP hardware team indicates that Fint values not in the table should not be used. So, prevent them from being selected during DPLL rate rounding. This removes warnings and also can prevent the chip from locking up. The first pass through the rate rounding code will update the DPLL max and min dividers appropriately, so later rate rounding passes will run faster than the first. Peter de Schrijver <peter.de-schrijver@nokia.com> put up with several test cycles of this patch - thanks Peter. Signed-off-by:
-
Paul Walmsley authored
The previous DPLL rate rounding algorithm counted the divider (N) down from the maximum to 1. Since we currently use a broad DPLL rate tolerance, and lower N values are more power-efficient, we can often bypass several iterations through the loop by counting N upwards from 1. Peter de Schrijver <peter.de-schrijver@nokia.com> put up with several test cycles of this patch - thanks Peter. Signed-off-by:
-
Paul Walmsley authored
Remove some clutter from omap2_dpll_round_rate(). Signed-off-by:
-
Jarkko Nikula authored
Signed-off-by:
Jarkko Nikula <jarkko.nikula@nokia.com> Signed-off-by:
-
Jarkko Nikula authored
Signed-off-by:
-
Jarkko Nikula authored
Signed-off-by:
-
Jarkko Nikula authored
Signed-off-by:
-
Jarkko Nikula authored
Signed-off-by:
-
