- 11 Dec, 2008 17 commits
-
-
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 <dbrownell@users.sourceforge.net> Signed-off-by:
Kevin Hilman <khilman@deeprootsystems.com>
-
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 21 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:
-
Jarkko Nikula authored
Signed-off-by:
-
Jarkko Nikula authored
Signed-off-by:
-
Jarkko Nikula authored
This converts new files which are not yet merged upstream including gpio-switch and board files for 3430sdp, Nokia N800 and omap3evm. Signed-off-by:
-
Jarkko Nikula authored
Signed-off-by:
-
Tony Lindgren authored
This reverts commit 41cc3cea. Oops, my mistake, I was diffing wrong branches. Signed-off-by:
-
Kalle Jokiniemi authored
I2C_WE registers were not configured, which caused huge delays in I2C operations while cpu idle was enabled and omap entered WFI. This patch enables all I2C wakeup sources. Signed-off-by:
Kalle Jokiniemi <ext-kalle.jokiniemi@nokia.com> Signed-off-by:
-
Paul Walmsley authored
The I2C controller clears its OCP_SYSCONFIG register after an OCP soft reset. Reprogram OCP_SYSCONFIG for maximum power savings on rev3.6 controllers and beyond. On 2430, this involves setting the module AUTOIDLE bit. On 3430, this includes module AUTOIDLE, wakeup enable, slave smart-idle, and considers only the module functional clock state for idle-ack. Boot-tested on 2430SDP and 3430SDP. Signed-off-by:
-
Paul Walmsley authored
i2c-omap discriminates only between "revision 1" or "greater than revision 1." A following patch introduces code that must also discriminate between rev2.x, rev3.6, and rev3.12 controllers. Support this by storing the full revision data from the I2C_REV register, rather than just a single bit. The revision definitions may need to be extended for other ES levels that aren't currently available here. rev3.6 is what's present on the 2430SDP here (unknown ES revision); rev3.12 is used on the 3430ES2 here. Signed-off-by:
-
Tony Lindgren authored
Sync i2c-omap with patchesg going to mainline tree: - Unify the clock naming for 242x and 243x - Don't try to set a NULL pointer to 100 - Do a readback to flush posted write instead of wmb() Signed-off-by: -
Tony Lindgren authored
This file got out of sync with the earlier strongly ordered patch. Signed-off-by: -
Hugo Villeneuve authored
The PCM3008 is used on the Lyrtech SFFSDR board, in conjunction with an FPGA that generates the bit clock and the master clock Signed-off-by:
Hugo Villeneuve <hugo@hugovil.com> Acked-by:
Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Hugo Villeneuve authored
The PCM3008 is a 16-bit stereo audio codec. It accepts left-justified format for ADC, and right-justified format for DAC. Independent power-down modes for ADC and DAC are provided, as well as a digital de-emphasis filter (4 modes). Signed-off-by:
-
