Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
The goal here is to facilitate ARM single image kernels by removing
includes via the "plat/" symlink.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
[tony@atomide.com: fixed to remove duplicate clock.h includes]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Duplicate arch/arm/plat-omap/clock.c into arch/arm/mach-omap1/clock.c
and arch/arm/mach-omap2/clock.c.  This is to support people who are working
on the ARM single image kernel and the OMAP common clock framework
conversion.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Moving plat/omap-secure.h locally to mach-omap2/
as part of single zImage work
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

omap_reserve() callback is defned only for mach-omap2.
So, moving definition of omap_reserve() to mach-omap2.
This helps is moving plat/omap_secure.h local to
mach-omap2
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

omap_reserve() is a stub for omap1. So dropping
omap_reserve callback from all OMAP1 board files.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We must move this for ARM common zImage support.

Note that neither drivers/media/rc/ir-rx51.c or
drivers/media/platform/omap3isp/ispvideo.c need
to include omap-pm.h, so this patch removes the
include for those files.
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi>
Cc: linux-media@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

This is private to cpu.h and no other places should
need to include it and we can drop the include
in mach-omap2/io.c.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Let's make omap_hwmod local to mach-omap2 for
ARM common zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Let's make omap_device local to mach-omap2 for
ARM common zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We can move this from plat to be local to plat-omap
for common ARM zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We need to move this away from plat for ARM common
zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We cannot keep this in plat/common.h for common zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

There's no need to keep the device related things in the
common i2c.c as omap2+ is using hwmod. Split the code to
mach-omap1 and mach-omap2 parts and only leave common
code to plat-omap/i2c.c.

Note that as omap1 only has one i2c controller, we can
now remove the old device related macros.
Reviewed-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This can be local to mach-omap2.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We cannot keep this in plat as it causes problems
with the ARM single zImage support.

Cc: Felipe Balbi <balbi@ti.com>
Cc: linux-pcmcia@lists.infradead.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

There's no need to have this file in plat/fpga.h. We can
make it local to plat-omap replacing fpga_read/write
functions directly with readb/writeb as that's how
they are already defined in fpga.h.

Note that 2420 based H4 is also using the fpga, so let's
keep the led support around in plat-omap until we flip
over mach-omap2 to device tree.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Cc: Felipe Balbi <balbi@ti.com>
Cc: linux-usb@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

Conflicts:
	arch/arm/mach-omap2/board-omap3logic.c
	arch/arm/mach-omap2/gpmc.c
	drivers/media/platform/omap/omap_vout.c
	drivers/media/platform/omap/omap_vout_vrfb.c

Conflicts:
	arch/arm/mach-omap1/devices.c
	arch/arm/mach-omap2/omap_hwmod_33xx_data.c
	arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
	drivers/mmc/host/omap.c

Conflicts:
	arch/arm/mach-omap2/board-3430sdp.c
	arch/arm/mach-omap2/board-h4.c
	arch/arm/mach-omap2/board-rx51-peripherals.c
	arch/arm/mach-omap2/board-rx51.c
	arch/arm/mach-omap2/pm34xx.c
	drivers/mtd/nand/omap2.c
	drivers/mtd/onenand/omap2.c

Remove arch/arm/plat-omap/include/plat/sdrc.h by folding its contents
into arch/arm/mach-omap2/sdrc.h.  The objective is to assist Tony in
cleaning out arch/arm/plat-omap/, as his upstreams request.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
[tony@atomide.com: updated to remove rotate macros]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Conflicts:
	drivers/crypto/omap-aes.c
	drivers/crypto/omap-sham.c
	drivers/dma/omap-dma.c

Replace cpu_is_*() check with omap_vrfb_supported().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add an exported function omap_vrfb_supported() which returns true if the
vrfb driver has been loaded succesfully. This can be used to decide if
VRFB can be used or not.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that VRFB driver handles its registers independently, we can remove
the VRFB related code from OMAP's sdrc.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>

This patch converts vrfb library into a platform device, in an effort to
remove omap dependencies.

The platform device is registered in arch/arm/plat-omap/fb.c and
assigned resources depending on whether running on omap2 or omap3.

The vrfb driver will parse those resources and use them to access vrfb
configuration registers and the vrfb virtual rotation areas.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

cpu_is_* calls are no longer used in omapdss, so the includes for
<plat/cpu.h> can be removed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Merge tag 'gpmc-czimage' of git://gitorious.org/x0148406-public/linux-kernel into omap-for-v3.8/cleanup-headers-gpmc

gpmc cleanup for common ARM zImage

Use omapdss_version in hdmi.c to select the proper hdmi features.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use omapdss_version in dss.c to select the proper dss features.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use omapdss_version in dispc.c to select the proper dispc features.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Pass the omapdss_version to dss_features.c and use it to select the
proper dss features.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add new enum, omapdss_version, that is used to tell which DSS hardware
version the SoC has. This enum is initialized during platform init, and
passed in the platform data to omapdss driver.

Note that the versions are not "continuous", that is, you cannot check
if the version is less or greater than something, but you need to check
for exact version match. In other words, this is invalid:

/* test if DSS is 3630 or earlier */
if (ver <= OMAPDSS_VER_OMAP3630)
	...
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Drivers should not use cpu_is_omap or cpu_class_is_omap macros,
they should be private to the platform init code. And we'll be
removing plat/cpu.h and only have a private soc.h for the
arch/arm/*omap* code.

This patch is intended as preparation for the core omap changes
and removes the need to include plat/cpu.h from several drivers.
This is needed for the ARM common zImage support.

These changes are OK to do because:

- omap-rng.c does not need plat/cpu.h

- omap-aes.c and omap-sham.c get the proper platform_data
  passed to them so they don't need extra checks in the driver

- omap-dma.c and omap-pcm.c can test the arch locally as
  omap1 and omap2 cannot be compiled together because of
  conflicting compiler flags

Cc: Deepak Saxena <dsaxena@plexity.net>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Venkatraman S <svenkatr@ti.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: linux-kernel@vger.kernel.org
[tony@atomide.com: mmc changes folded in to an earlier patch]
Signed-off-by: NTony Lindgren <tony@atomide.com>

The DSPBridge driver includes arch/arm/plat-omap/include/plat/clock.h.
All of the <plat/ ...> includes are causing problems with the ARM
single image kernel effort.  Remove this one.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Move plat/dma.h to plat-omap/dma-omap.h as part of single
zImage work
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Similar to omap1, some of the omap2+ dma channel definitions are
used by some drivers. For moving omap2+ dma channel definitions
to mach-omap2/, the used ones should be defined locally to driver.
Drivers can eliminate it using DT, platform data, or IORESOURCE_DMA
And moving omap2+ DMA channel definitions to mach-omap2
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Some of the omap1 dma channel definitions are used by some drivers.
For moving omap1 dma channel definitions to mach-omap1/, the used
ones should be defined locally to driver. Driver can eliminate it
by using DT, platform data, or IORESOURCE_DMA.
And moving OMAP1 DMA channel definitions to mach-omap1
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>