Merge tag 'omap-cleanup-sparseirq-for-v3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup

From Tony Lindgren:

This branch contains changes needed to make omap2+
work properly with sparse IRQ. It also removes
dependencies to mach/hardware.h. These help moving
things towards ARM single zImage support.

This branch is based on a commit in tty-next
branch with omap-devel-gpmc-fixed-for-v3.7 and
cleanup-omap-tags-for-v3.7 merged in to keep things
compiling and sort out some merge conflicts.

* tag 'omap-cleanup-sparseirq-for-v3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP1: Move SoC specific headers from plat to mach for omap1
  ARM: OMAP2+ Move SoC specific headers to be local to mach-omap2
  ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+
  ARM: OMAP: Remove unused old gpio-switch.h
  ARM: OMAP1: Move plat/irqs.h to mach/irqs.h
  ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ
  ARM: OMAP2+: Prepare for irqs.h removal
  W1: OMAP HDQ1W: Remove dependencies to mach/hardware.h
  Input: omap-keypad: Remove dependencies to mach includes
  ARM: OMAP: Move gpio.h to include/linux/platform_data
  ARM: OMAP2+: Remove hardcoded twl4030 gpio_base, irq_base and irq_end
  ARM: OMAP2+: Remove unused nand_irq for GPMC
  ARM: OMAP2+: Make INTCPS_NR_IRQS local for mach-omap2/irq.c
  ARM: OMAP1: Define OMAP1_INT_I2C locally
  ARM: OMAP1: Move define of OMAP_LCD_DMA to dma.h

1 files changed, 0 insertions, 91 deletions

diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
deleted file mode 100644
index 287ac3748904..000000000000
--- a/arch/arm/plat-omap/devices.c
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * linux/arch/arm/plat-omap/devices.c
- *
- * Common platform device setup/initialization for OMAP1 and OMAP2
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-#include <linux/gpio.h>
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-#include <linux/slab.h>
-#include <linux/memblock.h>
-
-#include <mach/hardware.h>
-#include <asm/mach-types.h>
-#include <asm/mach/map.h>
-#include <asm/memblock.h>
-
-#include <plat/tc.h>
-#include <plat/mmc.h>
-#include <plat/menelaus.h>
-#include <plat/omap44xx.h>
-
-/*-------------------------------------------------------------------------*/
-
-#if defined(CONFIG_HW_RANDOM_OMAP) || defined(CONFIG_HW_RANDOM_OMAP_MODULE)
-
-#ifdef CONFIG_ARCH_OMAP2
-#define	OMAP_RNG_BASE		0x480A0000
-#else
-#define	OMAP_RNG_BASE		0xfffe5000
-#endif
-
-static struct resource rng_resources[] = {
-	{
-		.start		= OMAP_RNG_BASE,
-		.end		= OMAP_RNG_BASE + 0x4f,
-		.flags		= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device omap_rng_device = {
-	.name		= "omap_rng",
-	.id		= -1,
-	.num_resources	= ARRAY_SIZE(rng_resources),
-	.resource	= rng_resources,
-};
-
-static void omap_init_rng(void)
-{
-	(void) platform_device_register(&omap_rng_device);
-}
-#else
-static inline void omap_init_rng(void) {}
-#endif
-
-/*
- * This gets called after board-specific INIT_MACHINE, and initializes most
- * on-chip peripherals accessible on this board (except for few like USB):
- *
- *  (a) Does any "standard config" pin muxing needed.  Board-specific
- *	code will have muxed GPIO pins and done "nonstandard" setup;
- *	that code could live in the boot loader.
- *  (b) Populating board-specific platform_data with the data drivers
- *	rely on to handle wiring variations.
- *  (c) Creating platform devices as meaningful on this board and
- *	with this kernel configuration.
- *
- * Claiming GPIOs, and setting their direction and initial values, is the
- * responsibility of the device drivers.  So is responding to probe().
- *
- * Board-specific knowledge like creating devices or pin setup is to be
- * kept out of drivers as much as possible.  In particular, pin setup
- * may be handled by the boot loader, and drivers should expect it will
- * normally have been done by the time they're probed.
- */
-static int __init omap_init_devices(void)
-{
-	/* please keep these calls, and their implementations above,
-	 * in alphabetical order so they're easier to sort through.
-	 */
-	omap_init_rng();
-	return 0;
-}
-arch_initcall(omap_init_devices);