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>

Define the following architecture specific funtions for omap2/3
.clkdm_add_wkdep
.clkdm_del_wkdep
.clkdm_read_wkdep
.clkdm_clear_all_wkdeps
.clkdm_add_sleepdep
.clkdm_del_sleepdep
.clkdm_read_sleepdep
.clkdm_clear_all_sleepdeps

Convert the platform-independent framework to call these functions.
With this also move the clkdm lookups for all wkdep_srcs and
sleepdep_srcs at clkdm_init.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: fixed loop termination conditions in omap*_clkdm_clear_all_*();
 thanks to Kevin Hilman for finding and helping fix those bugs; also
 avoid re-resolving clockdomains during init; abstracted out clkdm_dep walk]
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

add support the irq mode in GPMC.
gpmc_init() function move after omap_init_irq() as it has dependecy on irq.
Signed-off-by: NSukumar Ghorai <s-ghorai@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch updates the common machine specific source files with support for
TI816X.
Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The new init_early hook happens at the end of setup_arch,
which is too early for kzalloc. However, there's no need
to call omap_serial_early_init that early, so fix this
by setting it up as a core_initcall.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Tested-by: NKevin Hilman <khilman@ti.com>

Otherwise things will fail with early_init changes.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest
are nowadays just subcategories of these.

Search and replace the following:

ARCH_OMAP2420		SOC_OMAP2420
ARCH_OMAP2430		SOC_OMAP2430
ARCH_OMAP3430		SOC_OMAP3430

No functional changes.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NThomas Weber <weber@corscience.de>
Acked-by: NSourav Poddar <sourav.poddar@ti.com>