summaryrefslogtreecommitdiffstats
path: root/arch/arm/plat-omap/include/mach/io.h
Commit message (Collapse)AuthorAgeFilesLines
* omap: headers: Create headers necessary for compile under mach-omap1 and ↵Tony Lindgren2009-10-191-287/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mach-omap2 Create the headers needed for compiling under mach-omap1/include/mach and mach-omap2/include/mach. This was done with the following script: #!/bin/bash mach_files="clkdev.h gpio.h hardware.h io.h irqs.h memory.h \ smp.h system.h timex.h uncompress.h vmalloc.h" omaps="mach-omap1 mach-omap2" mach_dir_old="arch/arm/plat-omap/include/mach" plat_dir_new="arch/arm/plat-omap/include/plat" mkdir -p $plat_dir_new git add $plat_dir_new for dir in $omaps; do mach_dir_new="arch/arm/$dir/include/mach" for header in $mach_files; do file="$mach_dir_new/$header" if [ ! -f $file ]; then echo -ne "/*\n * $file\n */\n\n#include <plat/$header>\n" > $file git add $file if [ ! -f $plat_dir_new/$header ]; then git mv $mach_dir_old/$header $plat_dir_new/$header fi fi done done Signed-off-by: Tony Lindgren <tony@atomide.com>
* omap: Add OMAP4 L3 and L4 peripherals.Santosh Shilimkar2009-10-191-3/+26
| | | | | | | This patch adds few necessary peripherals for OMAP4. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* omap: Remap L3, L4 to get more kernel io address spaceSantosh Shilimkar2009-10-191-38/+59
| | | | | | | | | | | | | | This patch remap L3 and L4 io space to get more kernel address space. With this patch, 512 MB of IO space is reclaimed. Some more combinations are possible but to make it uniform across OMAP24XX, OMAP34XX and OMAP4430, these io combinations are chosen Once this is reviewed and tested sufficiently, a documentation entry can be created to ease up reading and debugging. Like "Documentation/arm/omap/io_map.txt" Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* omap: Split OMAP2_IO_ADDRESS to L3 and L4Santosh Shilimkar2009-10-191-2/+4
| | | | | | | | | | | | | | | This patch splits OMAP2_IO_ADDRESS to OMAP2_L3_IO_ADDRESS and OMAP2_L4_IO_ADDRESS to reclaim more IO space. The omap_read*() and omap_write*() functions will work only over L4 address space. Current omap kernel stack uses these functions only to access registers over L4 io address space Note that these macros should only be used when ioremap does not work. Please use ioremap instead in all new code. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* OMAP: Remove ifdefs for io.hTony Lindgren2009-08-281-8/+29
| | | | | | Remove ifdefs for io.h Signed-off-by: Tony Lindgren <tony@atomide.com>
* OMAP: Remove OMAP_IO_ADDRESS, use OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS insteadTony Lindgren2009-08-281-43/+21
| | | | | | | | | | | Search and replace OMAP_IO_ADDRESS with OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS, and convert omap_read/write into a functions instead of a macros. Also rename OMAP_MPUIO_VBASE to OMAP1_MPUIO_VBASE. In the long run, most code should use ioremap + __raw_read/write instead. Signed-off-by: Tony Lindgren <tony@atomide.com>
* OMAP3 SDRC: add support for 2 SDRAM chip selectsJean Pihet2009-07-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | Some OMAP3 boards (Beagle Cx, Overo, RX51, Pandora) have 2 SDRAM parts connected to the SDRC. This patch adds the following: - add a new argument of type omap_sdrc_params struct* to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params - adapted the OMAP boards files to the new prototype of omap2_init_common_hw - add the SDRC 2nd CS registers offsets defines - adapt the sram sleep code to configure the SDRC for the 2nd CS Note: If the 2nd param to omap2_init_common_hw is NULL, then the parameters are not programmed into the SDRC CS1 registers Tested on 3430 SDP and Beagleboard rev C2 and B5, with suspend/resume and frequency changes (cpufreq). Signed-off-by: Jean Pihet <jpihet@mvista.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP: Fix IOMEM macro for assemblyTony Lindgren2009-06-231-1/+1
| | | | | | Otherwise IOMEM calculations can fail. Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP4: Add minimal support for omap4Santosh Shilimkar2009-05-281-0/+37
| | | | | | | | | | | | This patch adds the support for OMAP4. The platform and machine specific headers and sources updated for OMAP4430 SDP platform. OMAP4430 is Texas Instrument's SOC based on ARM Cortex-A9 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and SCU for cache coherency. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* [ARM] OMAP2 SDRC: add SDRAM timing parameter infrastructurePaul Walmsley2009-02-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | For a given SDRAM clock rate, SDRAM chips require memory controllers to use a specific set of timing minimums and maximums to transfer data reliably. These parameters can be different for different memory chips and can also potentially vary by board. This patch adds the infrastructure for board-*.c files to pass this timing data to the SDRAM controller init function. The timing data is specified in an 'omap_sdrc_params' structure, in terms of SDRC controller register values. An array of these structs, one per SDRC target clock rate, is passed by the board-*.c file to omap2_init_common_hw(). This patch does not define the values for different memory chips, nor does it use the values for anything; those will come in subsequent patches. linux-omap source commit is bc84ecfc795c2d1c5cda8da4127cf972f488a696. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Add a common typesafe __io implementationRussell King2008-11-301-4/+2
| | | | | | | | 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>
* ARM: OMAP3: Add minimal omap3430 supportSyed Mohammed, Khasim2008-10-091-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add minimal omap3430 support based on earlier patches from Syed Mohammed Khasim. Also merge in omap34xx SRAM support from Karthik Dasu and use consistent naming for sram init functions. Also do following changes that make 34xx support usable: - Remove unused sram.c functions for 34xx - Rename IRQ_SIR_IRQ to INTCPS_SIR_IRQ and define it locally in entry-macro.S - Update mach-omap2/io.c to support 2420, 2430, and 34xx - Also merge in 34xx GPMC changes to add fields wr_access and wr_data_mux_bus from Adrian Hunter - Remove memory initialization call omap2_init_memory() until until more generic memory initialization patches are posted. It's OK to rely on bootloader initialization until then. Signed-off-by: Syed Mohammed, Khasim <khasim@ti.com> Signed-off-by: Karthik Dasu<karthik-dp@ti.com> Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* [ARM] omap: Fix IO_ADDRESS() macrosRussell King2008-09-051-23/+27
| | | | | | | | | | | | | OMAP1_IO_ADDRESS(), OMAP2_IO_ADDRESS() and IO_ADDRESS() returns cookies for use with __raw_{read|write}* for accessing registers. Therefore, these macros should return (void __iomem *) cookies, not integer values. Doing this improves typechecking, and means we can find those places where, eg, DMA controllers are incorrectly given virtual addresses to DMA to, or physical addresses are thrown through a virtual to physical address translation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] omap: allow ioremap() to use our fixed IO mappingsRussell King2008-09-051-0/+6
| | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Move include/asm-arm/arch-* to arch/arm/*/include/machRussell King2008-08-071-0/+197
This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>