aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/mach-davinci/include
AgeCommit message (Collapse)Author
2009-05-28davinci: add SRAM allocatorDavid Brownell
Provide a generic SRAM allocator using genalloc, and vaguely modeled after what AVR32 uses. This builds on top of the static CPU mapping set up in the previous patch, and returns DMA mappings as requested (if possible). Compared to its OMAP cousin, there's no current support for (currently non-existent) DaVinci power management code running in SRAM; and this has ways to deallocate, instead of being allocate-only. The initial user of this should probably be the audio code, because EDMA from DDR is subject to various dropouts on at least DM355 and DM6446 chips. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: soc-specific SRAM setupDavid Brownell
Package on-chip SRAM. It's always accessible from the ARM, so set up a standardized virtual address mapping into a 128 KiB area that's reserved for platform use. In some cases (dm6467) the physical addresses used for EDMA are not the same as the ones used by the ARM ... so record that info separately in the SOC data, for chips (unlike the OMAP-L137) where SRAM may be used with EDMA. Other blocks of SRAM, such as the ETB buffer or DSP L1/L2 RAM, may be unused/available on some system. They are ignored here. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: remove remnants of IRAM allocatorDavid Brownell
Remove remnants of dm6446-specific SRAM allocator, as preparation for a more generic replacement. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: cleanup: move dm355 UART2 define to dm355.cKevin Hilman
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Move PINMUX defines to SoC filesMark A. Greer
Different SoC have different numbers of pinmux registers and other resources that overlap with each other. To clean up the code and eliminate defines that overlap with each other, move the PINMUX defines to the SoC specific files. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Add compare register support to timer codeMark A. Greer
The Timer64p timer has 8 compare registers that can be used to generate interrupts when the timer value matches the compare reg's value. They do not disturb the timer itself. This can be useful when there is only one timer available for both clock events and clocksource. When enabled, the clocksource remains a continuous 32-bit counter but the clock event will no longer support periodic interrupts. Instead only oneshot timers will be supported and implemented by setting the compare register to the current timer value plus the period that the clock event subsystem is requesting. Compare registers support is enabled automatically when the following conditions are met: 1) The same timer is being used for clock events and clocksource. 2) The timer is the bottom half (32 bits) of the 64-bit timer (hardware limitation). 3) The the compare register offset and irq are not zero. Since the timer is always running, there is a hardware race in timer32_config() between reading the current timer value, and adding the period to the current timer value and writing the compare register. Testing on a da830 evm board with the timer clocked at 24 MHz and the processor clocked at 300 MHz, showed the number of counter ticks to do this ranged from 20-53 (~1-2.2 usecs) but usually around 41 ticks. This includes some artifacts from collecting the information. So, the minimum period should be at least 5 usecs to be safe. There is also an non-critical lower limit that the period should be since there is no point in setting an event that is much shorter than the time it takes to set the event, and get & handle the timer interrupt for that event. There can also be all sorts of delays from activities occuring elsewhere in the system (including hardware activitis like cache & TLB management). These are virtually impossible to quantify so a minimum period of 50 usecs was chosen. That will certianly be enough to avoid the actual hardware race but hopefully not large enough to cause unreasonably course-grained timers. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Integrate cp_intc support into low-level irq codeMark A. Greer
Integrate the Common Platform Interrupt Controller (cp_intc) support into the low-level irq handling for davinci and similar platforms. Do it such that support for cp_intc and the original aintc can coexist in the same kernel binary. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Factor out emac mac address handlingMark A. Greer
Factor out the code to extract that mac address from i2c eeprom. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Remove unused i2c eeprom_read/write routinesMark A. Greer
The dm644x and dm646x board files have i2c eeprom read and write routines but they are not used so remove them. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Move emac platform_data to SoC-specific filesMark A. Greer
Since most of the emac platform_data is really SoC specific and not board specific, move it to the SoC-specific files. Put a pointer to the platform_data in the soc_info structure so the board-specific code can set some of the platform_data if it needs to. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Move serial platform_device into SoC-specific filesMark A. Greer
Currently, there is one set of platform_device and platform_data structures for all DaVinci SoCs. The differences in the data between the various SoCs is handled by davinci_serial_init() by checking the SoC type. However, as new SoCs appear, this routine will become more & more cluttered. To clean up the routine and make it easier to add support for new SoCs, move the platform_device and platform_data structures into the SoC-specific code and use the SoC infrastructure to provide access to the data. In the process, fix a bug where the wrong irq is used for uart2 of the dm646x. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Make GPIO code more genericMark A. Greer
The current gpio code needs to know the number of gpio irqs there are and what the bank irq number is. To determine those values, it checks the SoC type. It also assumes that the base address and the number of irqs the interrupt controller uses is fixed. To clean up the SoC checks and make it support different base addresses and interrupt controllers, have the SoC-specific code set those values in the soc_info structure and have the gpio code reference them there. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Add watchdog base address flexibilityMark A. Greer
The watchdog code currently hardcodes the base address of the timer its using. To support new SoCs, make it support timers at any address. Use the soc_info structure to do this. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Add base address and timer flexibilityMark A. Greer
The davinci timer code currently hardcodes the timer register base addresses, the timer irq numbers, and the timers to use for clock events and clocksource. This won't work for some a new SoC so put those values into the soc_info structure and set them up in the SoC-specific files. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Move interrupt ctlr info to SoC infrastructureMark A. Greer
Use the SoC infrastructure to hold the interrupt controller information (i.e., base address, default priorities, interrupt controller type, and the number of IRQs). The interrupt controller base, although initially put in the soc_info structure's intc_base field, is eventually put in the global 'davinci_intc_base' so the low-level interrupt code can access it without a dereference. These changes enable the SoC default irq priorities to be put in the SoC-specific files, and the interrupt controller to be at any base address. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Move pinmux setup info to SoC infrastructureMark A. Greer
The pinmux register base and setup can be different for different SoCs so move the pinmux reg base, pinmux table (and its size) to the SoC infrastructure. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Add support for multiple PSCsMark A. Greer
The current code to support the DaVinci Power and Sleep Controller (PSC) assumes that there is only one controller. This assumption is no longer valid so expand the support to allow greater than one PSC. To accomplish this, put the base addresses for the PSCs in the SoC infrastructure so it can be referenced by the PSC code. This also requires adding an extra parameter to davinci_psc_config() to specify the PSC that is to be enabled/disabled. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Add clock init call to common init routineMark A. Greer
All of the davinci SoCs need to call davinci_clk_init() so put the call in the common init routine. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Support JTAG ID register at any addressMark A. Greer
The Davinci cpu_is_davinci_*() macros use the SoC part number and variant retrieved from the JTAG ID register to determine the type of cpu that the kernel is running on. Currently, the code to read the JTAG ID register assumes that the register is always at the same base address. This isn't true on some newer SoCs. To solve this, have the SoC-specific code set the JTAG ID register base address in soc_info structure and add a 'cpu_id' member to it. 'cpu_id' will be used by the cpu_is_davinci_*() macros to match the cpu id. Also move the info used to identify the cpu type into the SoC-specific code to keep all SoC-specific code together. The common code will read the JTAG ID register, search through an array of davinci_id structures to identify the cpu type. Once identified, it will set the 'cpu_id' member of the soc_info structure to the proper value and the cpu_is_davinci_*() macros will now work. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Encapsulate SoC-specific data in a structureMark A. Greer
Create a structure to encapsulate SoC-specific information. This will assist in generalizing code so it can be used by different SoCs that have similar hardware but with minor differences such as having a different base address. The idea is that the code for each SoC fills out a structure with the correct information. The board-specific code then calls the SoC init routine which in turn will call a common init routine that makes a copy of the structure, maps in I/O regions, etc. After initialization, code can get a pointer to the structure by calling davinci_get_soc_info(). Eventually, the common init routine will make a copy of all of the data pointed to by the structure so the original data can be made __init_data. That way the data for SoC's that aren't being used won't consume memory for the entire life of the kernel. The structure will be extended in subsequent patches but initially, it holds the map_desc structure for any I/O regions the SoC/board wants statically mapped. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: EMAC platform supportKevin Hilman
Add SoC and platform-specific data and init for DaVinci EMAC network driver. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: MMC platform supportKevin Hilman
Add SoC and platform-specific data and init for MMC driver. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: DM646x: add base SoC and board supportKevin Hilman
Add support for DM646x SoC (a.k.a DaVinci HD) and its Evalution Module (EVM.) Original support done by Sudhakar Rajashekhara. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: DM355: add base SoC and board supportKevin Hilman
In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: INTC: add support for TI cp_intcSergei Shtylyov
Add support for Texas Instuments Common Platform Interrupt Controller (cp_intc) used on DA830/OMAP-L137. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mark Greer <mgreer@mvista.com> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: support different UART bases for zImage uncompressMark A. Greer
The davinci pre-kernel boot code assumes that all platforms use the same UART base address for the console. That assumption is not longer valid with some newer SoCs so determine the console UART base address from the machine number passed in from bootloader. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: interrupts: get_irqnr_and_base: save an instructionTroy Kisky
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: use 32-bit accesses for low-level debug macrosChaithrika U S
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>
2009-05-15Merge branch 'fix/asoc' into for-linusTakashi Iwai
* fix/asoc: ASoC: DaVinci EVM board support buildfixes ASoC: DaVinci I2S updates ASoC: davinci-pcm buildfixes pxa2xx-ac97: fix reset gpio mode setting ASoC: soc-core: fix crash when removing not instantiated card
2009-05-15ASoC: DaVinci EVM board support buildfixesDavid Brownell
This is a build fix, resyncing the DaVinci EVM ASoC board code with the version in the DaVinci tree. That resync includes support for the DM355 EVM, although that board isn't yet in mainline. (NOTE: also includes a bugfix to the platform_add_resources call, recently sent by Chaithrika U S <chaithrika@ti.com> but not yet merged into the DaVinci tree.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2009-04-27davinci: update DM644x support in preparation for more SoCsKevin Hilman
Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-27davinci: update pin-multiplexing supportKevin Hilman
Update MUX support to be more general and useful across multiple SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-27davinci: serial: generalize for more SoCsKevin Hilman
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-27davinci: DM355 IRQ Definitionss-paulraj@ti.com
Adding IRQ defintions for DaVinci DM355 and default interrupt priorities for DM355 Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-27davinci: DM646x: add interrupt number and prioritiesSudhakar Rajashekhara
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-27davinci: gpio bugfixesDavid Brownell
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: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-27davinci: add EDMA driverKevin Hilman
Original code for 2.6.10 and 2.6.28 series done by Texas Instruments and MontaVista, but major updates and rework done by Troy Kisky and David Brownell. Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Troy Kisky <troy.kisky@boundarydevices.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-23davinci: add arch_ioremap() which uses existing static mappingsKevin Hilman
Add arch-specific ioremap() which uses any existing static mappings in place of doing a new mapping. From now on, drivers should always use ioremap() instead of IO_ADDRESS(). In addition, remove the davinci_[read|write]* macros in favor of using ioremap. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-23davinci: major rework of clock, PLL, PSC infrastructureKevin Hilman
This is a significant rework of the low-level clock, PLL and Power Sleep Controller (PSC) implementation for the DaVinci family. The primary goal is to have better modeling if the hardware clocks and features with the aim of DVFS functionality. Highlights: - model PLLs and all PLL-derived clocks - model parent/child relationships of PLLs and clocks - convert to new clkdev layer - view clock frequency and refcount via /proc/davinci_clocks Special thanks to significant contributions and testing by David Brownell. Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-23davinci: add runtime CPU detection supportKevin Hilman
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-06Merge git://git.infradead.org/mtd-2.6Linus Torvalds
* git://git.infradead.org/mtd-2.6: (53 commits) [MTD] struct device - replace bus_id with dev_name(), dev_set_name() [MTD] [NOR] Fixup for Numonyx M29W128 chips [MTD] mtdpart: Make ecc_stats more realistic. powerpc/85xx: TQM8548: Update DTS file for multi-chip support powerpc: NAND: FSL UPM: document new bindings [MTD] [NAND] FSL-UPM: Add wait flags to support board/chip specific delays [MTD] [NAND] FSL-UPM: add multi chip support [MTD] [NOR] Add device parent info to physmap_of [MTD] [NAND] Add support for NAND on the Socrates board [MTD] [NAND] Add support for 4KiB pages. [MTD] sysfs support should not depend on CONFIG_PROC_FS [MTD] [NAND] Add parent info for CAFÉ controller [MTD] support driver model updates [MTD] driver model updates (part 2) [MTD] driver model updates [MTD] [NAND] move gen_nand's probe function to .devinit.text [MTD] [MAPS] move sa1100 flash's probe function to .devinit.text [MTD] fix use after free in register_mtd_blktrans [MTD] [MAPS] Drop now unused sharpsl-flash map [MTD] ofpart: Check name property to determine partition nodes. ... Manually fix trivial conflict in drivers/mtd/maps/Makefile
2009-03-20[MTD] [NAND] davinci_nand driverDavid Brownell
This is a device driver for the NAND flash controller found on the various DaVinci family chips. It handles up to four SoC chipselects, and some flavors of secondary chipselect (e.g. based on upper bits of the address bus) as used with some multichip packages. (Including the 2 GiB chips used on some TI devel boards.) The 1-bit ECC hardware is supported (3 bytes ECC per 512 bytes data); but not yet the newer 4-bit ECC (10 bytes ECC per 512 bytes data), as available on chips like the DM355 or OMAP-L137 and needed with the more error-prone MLC NAND chips. This is a cleaned-up version of code that's been in use for several years now; sanity checked with the new drivers/mtd/tests. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-03-19[ARM] pass reboot command line to arch_reset()Russell King
OMAP wishes to pass state to the boot loader upon reboot in order to instruct it whether to wait for USB-based reflashing or not. There is already a facility to do this via the reboot() syscall, except we ignore the string passed to machine_restart(). This patch fixes things to pass this string to arch_reset(). This means that we keep the reboot mode limited to telling the kernel _how_ to perform the reboot which should be independent of what we request the boot loader to do. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-01-08[ARM] fix AT91, davinci, h720x, ks8695, msm, mx2, mx3, netx, omap1, omap2, ↵Russell King
pxa, s3c arch/arm/mach-at91/at91cap9.c:337: error: 'NR_AIC_IRQS' undeclared here (not in a function) arch/arm/mach-at91/at91rm9200.c:301: error: 'NR_AIC_IRQS' undeclared here (not in a function) arch/arm/mach-at91/at91sam9260.c:351: error: 'NR_AIC_IRQS' undeclared here (not in a function) arch/arm/mach-at91/at91sam9261.c:287: error: 'NR_AIC_IRQS' undeclared here (not in a function) arch/arm/mach-at91/at91sam9263.c:312: error: 'NR_AIC_IRQS' undeclared here (not in a function) arch/arm/mach-at91/at91sam9rl.c:304: error: 'NR_AIC_IRQS' undeclared here (not in a function) arch/arm/mach-h720x/h7202-eval.c:38: error: implicit declaration of function 'IRQ_CHAINED_GPIOB' arch/arm/mach-ks8695/devices.c:46: error: 'KS8695_IRQ_WAN_RX_STATUS' undeclared here (not in a function) arch/arm/mach-msm/devices.c:28: error: 'INT_UART1' undeclared here (not in a function) arch/arm/mach-mx2/devices.c:233: error: 'MXC_GPIO_IRQ_START' undeclared here (not in a function) arch/arm/mach-mx3/devices.c:128: error: 'MXC_GPIO_IRQ_START' undeclared here (not in a function) arch/arm/mach-omap1/mcbsp.c:140: error: 'INT_730_McBSP1RX' undeclared here (not in a function) arch/arm/mach-omap1/mcbsp.c:165: error: 'INT_McBSP1RX' undeclared here (not in a function) arch/arm/mach-omap1/mcbsp.c:200: error: 'INT_McBSP1RX' undeclared here (not in a function) arch/arm/mach-omap2/board-apollon.c:286: error: implicit declaration of function 'omap_set_gpio_direction' arch/arm/mach-omap2/mcbsp.c:154: error: 'INT_24XX_MCBSP1_IRQ_RX' undeclared here (not in a function) arch/arm/mach-omap2/mcbsp.c:181: error: 'INT_24XX_MCBSP1_IRQ_RX' undeclared here (not in a function) arch/arm/mach-pxa/e350.c:36: error: 'IRQ_BOARD_START' undeclared here (not in a function) arch/arm/plat-s3c/dev-i2c0.c:32: error: 'IRQ_IIC' undeclared here (not in a function) ... Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-30[ARM] davinci: asm/memory.h is not required for mach/vmalloc.hRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-30[ARM] Ensure that both MAX_DMA_ADDRESS and ISA_DMA_THRESHOLD are definedRussell King
Both of these symbols should be defined by a platform, or neither should be defined. Ensure that all platforms conform. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-30[ARM] Add a common typesafe __io implementationRussell King
As Al did for Versatile in 2ad4f86b60b649fd7428265c08d73a3bd360c81b, add a typesafe __io implementation for platforms to use. Convert platforms to use this new simple typesafe implementation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-29[ARM] Hide ISA DMA API when ISA_DMA_API is unsetRussell King
When ISA_DMA_API is unset, we're not implementing the ISA DMA API, so there's no point in publishing the prototypes via asm/dma.h, nor including the machine dependent parts of that API. This allows us to remove a lot of mach/dma.h files which don't contain any useful code. Unfortunately though, some platforms put their own private non-ISA definitions into mach/dma.h, so we leave these behind and fix the appropriate #include statments. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-29[ARM] move MAX_DMA_ADDRESS to mach/memory.hRussell King
Move the definition of MAX_DMA_ADDRESS from mach/dma.h to mach/memory.h, thereby placing it along side its relative, ISA_DMA_THRESHOLD. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-28[ARM] remove a common set of __virt_to_bus definitionsNicolas Pitre
Let's provide an overridable default instead of having every machine class define __virt_to_bus and __bus_to_virt to the same thing. What most platforms are using is bus_addr == phys_addr so such is the default. One exception is ebsa110 which has no DMA what so ever, so the actual definition is not important except only for proper compilation. Also added a comment about the special footbridge bus translation. Let's also remove comments alluding to set_dma_addr which is not (and should not) be commonly used. Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>