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>

This allows us to remove omap hacks for map_io.
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>

This way we don't need to initialize SoC detection early
and can start using generic map_io.
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Create basic voltagedomains for OMAP2 and associate OMAP2 powerdomains
with the newly created voltage domains.

While here, update copyright on powerdomain data to 2011.
Signed-off-by: NKevin Hilman <khilman@ti.com>

Start cleaning up the voltage layer to have a voltage domain layer
that resembles the structure of the existing clock and power domain
layers.  To that end:

- move the 'struct voltagedomain' out of 'struct omap_vdd_info' to
  become the primary data structure.

- convert any functions taking a pointer to struct omap_vdd_info into
  functions taking a struct voltagedomain pointer.

- convert the register & initialize of voltage domains to look like
  that of powerdomains

- convert omap_voltage_domain_lookup() to voltdm_lookup(), modeled
  after the current powerdomain and clockdomain lookup functions.

- omap_voltage_late_init(): only configure VDD info when
  the vdd_info struct is non-NULL
Signed-off-by: NKevin Hilman <khilman@ti.com>

At Tony's request, remove the omap_chip bitmasks from the powerdomain
definitions.  Instead, initialize powerdomains based on one or more
lists that are applicable to a particular SoC family, variant, and
silicon revision.

Gražvydas Ignotas <notasas@gmail.com> found and reported a bug in a
related patch that also applied to this patch - thanks Gražvydas.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>

At Tony's request, remove the omap_chip bitmasks from the clockdomain
and clockdomain dependency definitions.  Instead, initialize
clockdomains based on one or more lists that are applicable to a
particular SoC family, variant, and silicon revision.

Tony Lindgren <tony@atomide.com> found a bug in a previous version of this
patch - thanks Tony.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>

Introduce them for each omap variant and just make them all call
omap2_init_common_infrastructure for now. Do this for each board-*.c
file except for board-generic and board-omap3beagle as they use
the same machine ID for multiple SoCs.

No functional changes.
Signed-off-by: NTony Lindgren <tony@atomide.com>

There's no need to call omap2_init_common_devices from init_early.

It no longer does anything else except reprogram the memory timings
for some boards, so it's better to do it later so we have a chance
to get console messages if something goes wrong.

Move it to happen after omap_serial_init gets called. And while
patching it anyways, rename it to omap_sdrc_init as suggested by
Benoit Cousson <b-cousson@ti.com>.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
CC: Tony Lindgren <tony@atomide.com>

This allows us to remove cpu_is_omap calls from init_irq functions.
There should not be any need for cpu_is_omap calls as at this point.
During the timer init we only care about SoC generation, and not about
subrevisions.

The main reason for the patch is that we want to initialize only
minimal omap specific code from the init_early call.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>