The only remaining user of the custom bit manipulation function sr32()
is arch/arm/cpu/armv7/omap3/clock.c, so  make it a static function in
that file to prepare complete removal.
Signed-off-by: NWolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>

omap_gpmc.h is a generic header used by OMAP NAND driver for all TI platfoms.
Hence this file should be present in generic folder instead of architecture
specific include folder.
Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
Signed-off-by: NPekon Gupta <pekon@ti.com>

Each SoC platform (AM33xx, OMAP3, OMAP4, OMAP5) has its own copy of GPMC related
defines and declarations scattered in SoC platform specific header files
like include/asm/arch-xx/cpu.h
However, GPMC hardware remains same across all platforms thus this patch merges
GPMC data scattered across different arch-xx specific header files into single
header file include/asm/arch/omap_gpmc.h

Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
Signed-off-by: NPekon Gupta <pekon@ti.com>

The commit
f3f98bb0 : "ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls"
removed the config option aimed towards moving that stuff into kernel, which
renders some code unreachable. Remove that code.
Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>

Signed-off-by: NWolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: NTom Rini <trini@ti.com>

TPS659038 is the power IC used in DRA7XX boards.
Adding support for this and also adding pmic data
for DRA7XX boards.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Voltage scaling can be done in two ways:
-> Using SR I2C
-> Using GP I2C
In order to support both, have a function pointer in pmic_data
so that we can call as per our requirement.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

To be consistent with other ARM platforms,
renaming asm/arch-omap*/clocks.h to asm/arch-omap*/clock.h
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

We need to call the save_omap_boot_params function on am33xx/ti81xx and
other newer TI SoCs, so move the function to boot-common.  Only OMAP4+
has the omap_hw_init_context function so add ifdefs to not call it on
am33xx/ti81xx.  Call save_omap_boot_params from s_init on am33xx/ti81xx
boards.
Reviewed-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NTom Rini <trini@ti.com>

The boot parameters are read from individual variables
assigned for each of them. This been corrected and now
they are stored as a part of the global data 'gd'
structure. So read them from 'gd' instead.
Signed-off-by: NSricharan R <r.sricharan@ti.com>
[trini: Add igep0033 hunk]
Signed-off-by: NTom Rini <trini@ti.com>

Warm reset on OMAP5 freezes when USB cable is connected.
Fix requires PRM_RSTTIME.RSTTIME1 to be programmed
with the time for which reset should be held low for the
voltages and the oscillator to reach stable state.

There are 3 parameters to be considered for calculating
the time, which are mostly board and PMIC dependent.
-1- Time taken by the Oscillator to shut + restart
-2- PMIC OTP times
-3- Voltage rail ramp times, which inturn depends on the
PMIC slew rate and value of the voltage ramp needed.

In order to keep the code in u-boot simple, have a way
for boards to specify a pre computed time directly using
the 'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC'
option. If boards fail to specify the time, use a default
as specified by 'CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC' instead.
Using the default value translates into some ~22ms and should work in
all cases.
However in order to avoid this large delay hiding other bugs,
its recommended that all boards look at their respective data
sheets and specify a pre computed and optimal value using
'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC'

In order to help future board additions to compute this
config option value, add a README at doc/README.omap-reset-time
which explains how to compute the value. Also update the toplevel
README with the additional option and pointers to
doc/README.omap-reset-time.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
[rnayak@ti.com: Updated changelog and added the README]
Signed-off-by: NRajendra Nayak <rnayak@ti.com>

Adding new board files for DRA7XX socs.
The pad registers layout is changed completely from OMAP5
So introducing the new structure here and also adding the
minimal data.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NNishant Kamat <nskamat@ti.com>
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Reviewed-by: NTom Rini <trini@ti.com>
[trini: Adapt omap_mmc_init call for last 2 params]
Signed-off-by: NTom Rini <trini@ti.com>

After power-up SRCOMP cells are by-passed by default in OMAP5.
Software has to enable these SRCOMP sells.
For ES2: All 5 SRCOMP cells needs to be enabled.
For ES1: Only 4 SRCOMP cells in core power domain are enabled.
	 The 1 in wkup domain is not enabled because smart i/os
	 of wkup domain work with default compensation code.
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@ti.com>
Cc: Tom Rini <trini@ti.com>

There is some code duplication in the ddr io settings code.
This is avoided by moving the data to a Soc specific place and
letting the code generic.

This avoids unnessecary code addition for future socs.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@ti.com>

The current PRCM structure prototype directly matches the hardware
register layout. So there is a need to change this for every new silicon
revision which has register space changes.

Avoiding this by making the prototye generic and populating the register
addresses seperately for all Socs.
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Only omap4/5 currently have a meaningful set of display text and overo
had been adding a function to display nothing.  Change how this works to
be opt-in and only turned on for omap4/5 now.
Signed-off-by: NTom Rini <trini@ti.com>

Errata ID:i727

Description: The refresh rate is programmed in the EMIF_SDRAM_REF_CTRL[15:0]
REG_REFRESH_RATE parameter taking into account frequency of the device.
When a warm reset is applied on the system, the OMAP processor restarts
with another OPP and so frequency is not the same. Due to this frequency
change, the refresh rate will be too low and could result in an unexpected
behavior on the memory side.

Workaround:
The workaround is to force self-refresh when coming back from the warm reset
with the following sequence:
• Set EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE to 0x2
• Set EMIF_PWR_MGMT_CTRL[7:4] REG_SR_TIM to 0x0
• Do a dummy read (loads automatically new value of sr_tim)
This will reduce the risk of memory content corruption, but memory content
can't be guaranteed after a warm reset.

This errata is impacted on
OMAP4430: 1.0, 2.0, 2.1, 2.2, 2.3
OMAP4460: 1.0, 1.1
OMAP4470: 1.0
OMAP5430: 1.0
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>

Certain modules are not affected by means of
a warm reset and need not be configured again.
Adding an API to detect the reset reason warm/cold.

This will be used to skip the module configurations
that are retained across a warm reset.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NR Sricharan <r.sricharan@ti.com>

The different silicon revision variable names was defined for OMAP4 and
OMAP5 socs. Making the variable common so that some code can be
made generic.
Signed-off-by: NR Sricharan <r.sricharan@ti.com>

OMAP Voltage controller is used to generically talk to
PMICs on OMAP3,4,5 over I2C_SR. Instead of replicating code
in multiple SoC code, introduce a common voltage controller
logic which can be re-used from elsewhere.

With this change, we replace setup_sri2c with omap_vc_init which
has the same functionality, and replace the voltage scale
replication in do_scale_vcore and do_scale_tps62361 with
omap_vc_bypass_send_value. omap_vc_bypass_send_value can also
now be used with any configuration of PMIC.

NOTE: Voltage controller controlling I2C_SR is a write-only data
path, so no register read operation can be implemented.
Reported-by: NIsabelle Gros <i-gros@ti.com>
Reported-by: NJerome Angeloni <j-angeloni@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>

* avoid potential buffer overflows
* allow SPL-build not to output "Texas Instruments Revision detection unimplemented"
Signed-off-by: NAndreas Müller <schnitzeltony@gmx.de>
Signed-off-by: NTom Rini <trini@ti.com>

Configuration header(CH) is 512 byte header attached to an OMAP
boot image that will help ROM code to initialize clocks, SDRAM
etc and copy U-Boot directly into SDRAM. CH can help us in
by-passing SPL and directly boot U-boot, hence it's an alternative
for SPL. However, we intend to support both CH and SPL for OMAP4/5.

Initialization done through CH is limited and is not equivalent
to that done by SPL. So U-Boot has to distinguish between the
two cases and handle them accordingly. This patch takes care
of doing this.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

Adding the correct configurations required for
dplls, clocks, for omap5 Soc.

Also changes are done to retain some part of the code common
for OMAP4/5 and move only the remaining to the Soc specific
directories.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

This patch adds the minimal support for OMAP5. The platform and machine
specific headers and sources updated for OMAP5430.

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 SCU for cache
coherency.

Also moved some part of code from the basic platform support that can be made
common for OMAP4/5. Rest is kept out seperately. The same approach is followed
for clocks and emif support in the subsequent patches.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

We add an weak version of omap_rev_string in omap-common/spl.c
and while at it drop the omap3 version.  Move the prototype over
to <asm/omap_common.h> with the other SPL functions.
Signed-off-by: NTom Rini <trini@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

- Provide alternate implementations of board_init_f()
  board_init_r() for OMAP spl.
- Provide linker script
- Initialize global data
- Add serial console support
- Update CONFIG_SYS_TEXT_BASE to allow for SPL's bss and move
  it to board config header from config.mk
Signed-off-by: NAneesh V <aneesh@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

Calculate EMIF register values based on AC timing parameters
from the SDRAM datasheet and the DDR frequency rather than
using the hard-coded values.

For a new board the user doen't have to go through the tedious
process of calculating the register values. Instead, just
provide the AC timings from the device data sheet as input
and the driver will automatically calculate the register values.
Signed-off-by: NAneesh V <aneesh@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

Add support for the SDRAM controller (EMIF).
Signed-off-by: NAneesh V <aneesh@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

Add support for:
1. DPLL locking
2. Initialization of clock domains and clock modules
3. Setting up the right voltage on voltage rails

This work draws upon previous work done for x-loader by:
	Santosh Shilimkar <santosh.shilimkar@ti.com>
	Rajendra Nayak <rnayak@ti.com>
Signed-off-by: NAneesh V <aneesh@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

Signed-off-by: NAneesh V <aneesh@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

- separate mux settings into essential and non essential parts
- essential part is board independent as of now(so move it
  to SoC directory). Will help in having single SPL for all
  boards.
- Non-essential part(the pins not essential for u-boot to function)
  need to be phased out eventually.
- Correct mux data by aligning to the latest settings in x-loader
Signed-off-by: NAneesh V <aneesh@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

The basic hardware init of OMAP4(s_init()) can happen in 4
different contexts:
 1. SPL running from SRAM
 2. U-Boot running from FLASH
 3. Non-XIP U-Boot loaded to SDRAM by SPL
 4. Non-XIP U-Boot loaded to SDRAM by ROM code using the
    Configuration Header feature

What level of hw initialization gets done depends on this
context. Add a utility function to find this context.
Signed-off-by: NAneesh V <aneesh@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

adapt omap4 to the new layered cache maintenance framework
Signed-off-by: NAneesh V <aneesh@ti.com>

The functions in syslib.c can be shared, so this patch moves it from
cpu/omap3 to cpu/omap-common
Signed-off-by: NSteve Sakoman <steve@sakoman.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

Add functional multiplexing support for OMAP4 pads.
Configure all the pads for the OMAP4430 SDP
and OMAP4 Panda boards
Signed-off-by: NSteve Sakoman <steve@sakoman.com>
Signed-off-by: NAneesh V <aneesh@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

This patch adds a gpmc_init function for OMAP4 and adds calls to
gpmc_init for existing OMAP4 boards: panda and sdp4430
Signed-off-by: NSteve Sakoman <steve@sakoman.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

This patch adds minimum support for OMAP4. Code which can be shared
between OMAP3 and OMAP4 is placed in arch/arm/cpu/armv7/omap-common
Signed-off-by: NAneesh V <aneesh@ti.com>
Signed-off-by: NSteve Sakoman <steve@sakoman.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

The purpose of this patch is to prepare for adding the OMAP4 architecture, which is Cortex A9

Cortex A8 and A9 both belong to the armv7 architecture, hence the name change.

The two architectures are similar enough that substantial code can be shared.
Signed-off-by: NAneesh V <aneesh@ti.com>
Signed-off-by: NSteve Sakoman <steve@sakoman.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>

Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>

Because of the reset_cpu is soc specific, should be move to soc

Cc: Dirk Behme <dirk.behme@googlemail.com>
Signed-off-by: NMinkyu Kang <mk7.kang@samsung.com>