Get rid of the mach-omap2/common.c globals by moving the global
initialization for IP block addresses that must occur early into
mach-omap2/io.c.  In the process, remove the *_map_common_io*() and
SoC-specific *set_globals* functions.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>

For omap1, we'll keep mach/serial.h around for 8250.c hardware
workarounds. For omap2+, we no longer need mach/serial.h and
can make it local to mach-omap2.
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>

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>

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>

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>

As the plat and mach includes need to disappear for single zImage work,
we need to remove plat/hardware.h.

Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.

The old plat/hardware.h already has omap1 only defines, so it gets moved
to mach/hardware.h for omap1. For omap2+, we use the local soc.h
that for now just includes the related SoC headers to keep this patch more
readable.

Note that the local soc.h still includes plat/cpu.h that can be dealt
with in later patches. Let's also include plat/serial.h from common.h for
all the board-*.c files. This allows making the include files local later
on without patching these files again.

Note that only minimal changes are done in this patch for the
drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
patches are needed to eventually remove cpu_is_omap usage in the drivers.

Also only minimal changes are done to sound/soc/omap/* to remove the
unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
no need to include omap44xx.h.

While at it, also sort some of the includes in the standard way.

Cc: linux-watchdog@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Acked-by: NWim Van Sebroeck <wim@iguana.be>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As the interrupts should only be defined in the platform_data, and
eventually coming from device tree, there's no need to define them
in header files.

Let's remove the hardcoded references to irqs.h and fix up the includes
so we don't rely on headers included in irqs.h. Note that we're
defining OMAP_INTC_START as 0 to the interrupts. This will be needed
when we enable SPARSE_IRQ. For some drivers we need to add
#include <plat/cpu.h> for now until these drivers are fixed to
remove cpu_is_omapxxxx() usage.

While at it, sort som of the includes the standard way, and add
the trailing commas where they are missing in the related data
structures.

Note that for drivers/staging/tidspbridge we just define things
locally.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds HWMOD data for all the peripherals of
AM335X device and also hooks up to the existing OMAP framework.

hwmod data has been already been cleaned up for the recent
changes in clocktree, where all leaf nodes have been removed,
since with modulemode based control, both clock and hwmod
interface does same thing. This reduces the code size to large
extent and also avoids duplication of same control.
So instead of specifying module's leaf node as a main_clk,
now we are relying on parent clock of module's functional clock.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: removed period in hwmod device names; changed mmc2 main_clk
 to mmc_clk at Vaibhav's request; added trailing commas to structure
 records at Tony's request to deal with some rmk parsing issues; added
 OMAP_INTC_START to facilitate sparse-IRQ conversion]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.

OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.

Patch includes:
 - The machine specific headers and sources updates.
 - Platform header updates.
 - Minimum initialisation support for serial.
 - IO table init
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

AM33XX clock implementation is different than any existing OMAP
family of devices. Although DPLL module is similar to OMAP4
device, but the usage is very much different than OMAP4.
AM33XX has different peripheral set and each module gets
integrated to the clock framework differently than OMAP
family of devices.

This patch adds full Clock tree data for AM33XX family
of devices and also integrates it into existing OMAP framework.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
CC: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: updated to apply; changed 'soc_is_am33xx' to
 'cpu_is_am33xx' to match usage in Tony's current am33xx branch]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

AM33XX PRCM module consists of various clockdomains, in all
total we have 18 clockdomains available, with following
controlling options,
   - SW Sleep: sw forced sleep transition
   - SW Wakeup: sw forced wakeup transition

This patch adds all available clockdomain data, respective
clockdomain operations for AM33XX family of device, and also
integrates it into existing OMAP framework.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
CC: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: removed CLKDM_NO_AUTODEPS from clockdomain flags, removed
 unnecessary .clktrctrl_offs field; updated for 3.5]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add offset & mask fields to struct powerdomain

In case of AM33xx family of devices, there is no consistency between
PWRSTCTRL & PWRSTST register offsers in PRM space, for example -

PRM_XXX           PWRSTCTRL     PWRSTST
=======================================
PRM_PER_MOD:      0x0C,         0x08
PRM_WKUP_MOD:     0x04,         0x08
PRM_MPU_MOD:      0x00,         0x04
PRM_DEVICE_MOD:   NA,           NA

And also, there is no consistency between bit-offsets inside
PWRSTCTRL & PWRSTST register, for example -

PRM_XXX           LOGICRET  MEMON  MEMRET
=======================================
GFX_PWRCTRL:      2,        17,    6
PER_PWRCTRL:      3,        25,    29
MPU_PWRCTRL:      2,        18,    22
WKUP_PWRCTRL:     3,        NA,    NA

This means, we need to maintain and pass on all this information
in powerdomain handle; so adding fields for,
   - PWRSTCTRL/ST register offset
   - Logic retention state mask
   - mem_on/ret/pwrst/retst mask

Currently, this fields is only applicable and used for AM33XX devices.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: this patch is a combination of "Add offset & mask fields to
 struct powerdomain" and the powerdomain portions of "ARM: OMAP3+: am33xx:
 Add powerdomain & PRM support"; updated for 3.5]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently dummy voltage domain data is being created
in order to succeed boot process, nothing has been done
w.r.t actual hardware (voltage control).

Also, hook up the AM33XX voltage domain to OMAP framework.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
[paul@pwsan.com: updated for 3.5]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This patch adds minimal support for AM335X machine init.

During last merge window, two separate patches supporting am33xx
machine init had been submitted,

1. Link to earlier Baseport patch submission (Legacy):
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg59325.html
2. Link to earlier DT based machine init support patch submission:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg61398.html

And both had got accepted at that time, but got missed during
merge window.

But now, since we have taken decision to make am33xx as a separate
class and not to follow omap3 family, these patches needs to changes
accordingly (only changes),

 - Combine both the patches, since early init and timer init
   used in board-generic.c file requires them.
 - Remove dependency on AM3517EVM, and only use DT approach
   for machine init.
 - Change the config option (as changed recently)
   CONFIG_SOC_OMAPAM33XX --> CONFIG_SOC_AM33XX
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

No need to have an OMAP prefix on these SoCs that are in the family
but arent' really called OMAP.

Simple rename: CONFIG_SOC_OMAPAM33XX --> CONFIG_SOC_AM33XX

No functional change.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated for the driver config change also]
Signed-off-by: NTony Lindgren <tony@atomide.com>

No need to have an OMAP prefix on these SoCs that are in the family
but arent' really called OMAP.

Simple rename: CONFIG_SOC_OMAPTI81XX --> CONFIG_SOC_TI81XX

No functional change.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Without runtime PM enabled, hwmod needs to leave all IP blocks in an
enabled state by default so any driver access to the HW will succeed.
This is accomplished by seting the postsetup_state to enabled for all
hwmods during init when runtime PM is disabled.

Currently, we have a special case for WDT in that its postsetup_state
is always set to disabled.  This is done so that the WDT is disabled
and the timer is disarmed at boot in case there is no WDT driver.
This also means that when runtime PM is disabled, if a WDT driver *is*
built in the kernel, the kernel will crash on the first access to the
WDT hardware.

We can't simply leave the WDT module enabled, because the timer is
armed by default after reset. That means that if there is no WDT
driver initialzed or loaded before the timer expires, the kernel will
reboot.

To fix this, a custom reset method is added to the watchdog class of
omap_hwmod.  This method will *always* disarm the timer after hwmod
reset.  The WDT timer then will only be rearmed when/if the driver is
loaded for the WDT.  With the timer disarmed by default, we no longer
need a special-case for the postsetup_state of WDT during init, so it
is removed.

Any platforms wishing to ensure the watchdog remains armed across the
entire boot boot can simply disable the reset-on-init feature of the
watchdog hwmod using omap_hwmod_no_setup_reset().

Tested on 3530/Overo, 4430/Panda.

NOTE: on 4430, the hwmod OCP reset does not seem to rearm the timer as
documented in the TRM (and what happens on OMAP3.)  I noticed this
because testing the HWMOD_INIT_NO_RESET feature with no driver loaded,
I expected a reboot part way through the boot, but did not see a
reboot.  Adding some debug to read the counter, I verified that right
after OCP softreset, the counter is not firing.  After writing the
magic start sequence, the timer starts counting.  This means that the
timer disarm sequence added here does not seem to be needed for 4430,
but is technically the correct way to ensure the timer is disarmed, so
it is left in for OMAP4.

Special thanks to Paul Walmsley for helping brainstorm ideas to fix
this problem.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: updated the omap2_wd_timer_reset() function in the
 wake of commit 3c55c1ba ("ARM:
 OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset
 wait for reset status""); added kerneldoc; rolled in warning fix from Kevin]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>

EMIF, GMPC and DMM driver can ioremap() the address
space as part of driver intialisation and there is
no need to have static IO mapping for them.

Hence remove the un-used static IP space and let
the respective drivers manage it as part if driver
init.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Several C files in arch/arm/mach-omap* and arch/arm/plat-omap declare
functions that are used by other files, but don't include the header
file where the prototype is declared.  This results in the following
warnings from sparse:

    arch/arm/mach-omap2/irq.c:114:5: warning: symbol 'omap_irq_pending' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:186:13: warning: symbol 'omap2_init_irq' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:191:13: warning: symbol 'omap3_init_irq' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:196:13: warning: symbol 'ti81xx_init_irq' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:233:39: warning: symbol 'omap2_intc_handle_irq' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:242:6: warning: symbol 'omap_intc_save_context' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'omap_intc_restore_context' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:291:6: warning: symbol 'omap3_intc_suspend' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:297:6: warning: symbol 'omap3_intc_prepare_idle' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:306:6: warning: symbol 'omap3_intc_resume_idle' was not declared. Should it be static?
    arch/arm/mach-omap2/irq.c:312:39: warning: symbol 'omap3_intc_handle_irq' was not declared. Should it be static?
    arch/arm/mach-omap2/omap-secure.c:59:12: warning: symbol 'omap_secure_ram_reserve_memblock' was not declared. Should it be static?
    arch/arm/mach-omap2/board-zoom-display.c:133:13: warning: symbol 'zoom_display_init' was not declared. Should it be static?
    arch/arm/plat-omap/common.c:73:13: warning: symbol 'omap_init_consistent_dma_size' was not declared. Should it be static?
    arch/arm/mach-omap1/irq.c:61:5: warning: symbol 'omap_irq_flags' was not declared. Should it be static?
    arch/arm/mach-omap1/irq.c:179:13: warning: symbol 'omap1_init_irq' was not declared. Should it be static?
    arch/arm/mach-omap1/reset.c:11:6: warning: symbol 'omap1_restart' was not declared. Should it be static?

Fix by including the appropriate header files.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Senthilvadivu Guruswamy <svadivu@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Otherwise we get the following warning:

arch/arm/mach-omap2/io.c:53:24: warning:
'omap24xx_io_desc' defined but not used [-Wunused-variable]
Reported-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

arch/arm/mach-omap2/: included some headers tiwce:
- arch/arm/mach-omap2/board-ldp.c: 'linux/gpio.h'
- arch/arm/mach-omap2/io.c: 'common.h'
- arch/arm/mach-omap2/omap_hwmod_44xx_data.c: 'plat/i2c.h'

Remove the duplicates.
Signed-off-by: NDanny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Drivers should no longer use omap_read/write functions
but instead use ioremap + read/write functions.

As some USB legacy code is still shared between omap1 and
omap2420, let's limit the omap_read/write to plat/usb.h.

Note that the long term fix is to update the drivers to
use ioremap and read/write functions. That can now be
done as a separate patch series that is limited to the
USB drivers.

Also make sure the legacy omap1-keypad.c driver builds
if selected for 2420 based systems.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

There's no need to have these defines in plat/io.h.

Note that we now need to ifdef omap_read/write calls
as they will be available for omap1 only.

While at it, clean up the includes to group them like
they typically are grouped.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

arm_memblock_steal() is not suppose to be used outside ->reserve callback.
OMAP barrier errata code was using it outside reserve callback and hence
it was broken.

Move the allocation as part of ->reserve callback to fix the it.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 7b250aff ("ARM: OMAP: Avoid
cpu_is_omapxxxx usage until map_io is done") breaks the build on a
2420-only config on v3.3-rc1:

arch/arm/mach-omap2/built-in.o: In function `omap2430_init_early':
arch/arm/mach-omap2/io.c:406: undefined reference to `omap2_set_globals_243x'
arch/arm/mach-omap2/io.c:410: undefined reference to `omap243x_clockdomains_init'
arch/arm/mach-omap2/io.c:411: undefined reference to `omap2430_hwmod_init'

Fix by only compiling omap2420_init_early() when CONFIG_SOC_OMAP2420
is selected, and only compiling omap2430_init_early() when
CONFIG_SOC_OMAP2430 is selected.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>

We need to detect the SoC revision early, but the SoC
feature detection can be done later on. In order to allow
further clean-up later on, this patch separates the SoC
revision check from the SoC feature check.

This patch doesn't change functionality or behavior of the code
execution; it barely cleans up the code and splits into SoC
specific implementation for Rev ID and feature detection.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch updates existing macros, functions used for TI816X, to enable
addition of other SoCs belonging to TI81XX family (e.g., TI814X).

The approach taken is to use TI81XX/ti81xx for code/data going to be common
across all TI81XX devices.

cpu_is_ti81xx() is introduced to handle code common across TI81XX devices.

In addition, ti8168_evm_map_io() is now replaced with ti81xx_map_io() and moved
in mach-omap2/common.c as same will be used for TI814X and is not board
specific.
Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch updates the common machine specific source files for
support for AM33XX/AM335x with cpu type, macros for identification of
AM33XX/AM335X device.
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
[tony@atomide.com: updated for map_io and common.h changes, dropped CK_AM33XX]
Signed-off-by: NTony Lindgren <tony@atomide.com>

On OMAP4 SOC, intecronnects has many write buffers in the async bridges
and they need to be drained before CPU enters into standby state.

Patch 'OMAP4: PM: Add CPUX OFF mode support' added CPU PM support
but OMAP errata i688 (Async Bridge Corruption) needs to be taken
care to avoid issues like system freeze, CPU deadlocks, random
crashes with register accesses, synchronisation loss on initiators
operating on both interconnect port simultaneously.

As per the errata, if a data is stalled inside asynchronous bridge
because of back pressure, it may be accepted multiple times, creating
pointer misalignment that will corrupt next transfers on that data
path until next reset of the system (No recovery procedure once
the issue is hit, the path remains consistently broken).
Async bridge can be found on path between MPU to EMIF and
MPU to L3 interconnect. This situation can happen only when the
idle is initiated by a Master Request Disconnection (which is
trigged by software when executing WFI on CPU).

The work-around for this errata needs all the initiators
connected through async bridge must ensure that data path
is properly drained before issuing WFI. This condition will be
met if one Strongly ordered access is performed to the
target right before executing the WFI. In MPU case, L3 T2ASYNC
FIFO and DDR T2ASYNC FIFO needs to be drained. IO barrier ensure
that there is no synchronisation loss on initiators operating
on both interconnect port simultaneously.

Thanks to Russell for a tip to conver assembly function to
C fuction there by reducing 40 odd lines of code from the patch.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
Acked-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NVishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

A generic version should replace this later.

As io.c has become nearly empty, omap_init_consistent_dma_size() is moved
into common.c so that io.c can be removed entirely.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NKevin Hilman <khilman@ti.com>

As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>,
there's no need to keep local prototypes in non-local headers.

Add mach-omap1/common.h and mach-omap2/common.h and move the
local prototypes there from plat/common.h and mach/omap4-common.h.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

After the MULTI_IRQ_HANDLER conversion, a couple of global
variables can be removed.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

When customizing omap2plus_defconfig to build for only
one board (omap3evm), I came across these warnings and
errors (filenames truncated):

arch/arm/mach-omap2/board-generic.c:76:20: warning: 'omap4_init' defined but not used
arch/arm/mach-omap2/built-in.o: In function `omap2420_init_early':
arch/arm/mach-omap2/io.c:364: undefined reference to `omap2_set_globals_242x'
arch/arm/mach-omap2/io.c:366: undefined reference to `omap2xxx_voltagedomains_init'
arch/arm/mach-omap2/io.c:367: undefined reference to `omap242x_powerdomains_init'
arch/arm/mach-omap2/io.c:368: undefined reference to `omap242x_clockdomains_init'
arch/arm/mach-omap2/io.c:369: undefined reference to `omap2420_hwmod_init'
arch/arm/mach-omap2/built-in.o: In function `omap2430_init_early':
arch/arm/mach-omap2/io.c:376: undefined reference to `omap2_set_globals_243x'
arch/arm/mach-omap2/io.c:378: undefined reference to `omap2xxx_voltagedomains_init'
arch/arm/mach-omap2/io.c:379: undefined reference to `omap243x_powerdomains_init'
arch/arm/mach-omap2/io.c:380: undefined reference to `omap243x_clockdomains_init'
arch/arm/mach-omap2/io.c:381: undefined reference to `omap2430_hwmod_init'
arch/arm/mach-omap2/built-in.o: In function `omap4430_init_early':
arch/arm/mach-omap2/io.c:436: undefined reference to `omap2_set_globals_443x'
arch/arm/mach-omap2/io.c:438: undefined reference to `omap44xx_voltagedomains_init'
arch/arm/mach-omap2/io.c:439: undefined reference to `omap44xx_powerdomains_init'
arch/arm/mach-omap2/io.c:440: undefined reference to `omap44xx_clockdomains_init'
arch/arm/mach-omap2/io.c:441: undefined reference to `omap44xx_hwmod_init'

This patch fixes them.
Signed-off-by: NSanjeev Premi <premi@ti.com>
Acked-by: NThomas Weber <weber@corscience.de>
[tony@atomide.com: updated to fix warnings for board-generic.c]
Signed-off-by: NTony Lindgren <tony@atomide.com>

We don't have cpu_is_omapxxxx SoC detection initialized until
SoC detection is initialized from init_early.

Note that with the common map_io we should no longer need
cpu_is_omapxxxx for ioremap.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Otherwise we can't do generic map_io as we currently rely on
static mappings that work only because of arch_ioremap.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>