Initially, we decided to make am33xx family of device to fall
under omap3 class (cpu_is_omap34xx() = true), since it carries
Cortex-A8 core. But while adding complete baseport support
(like, clock, power and hwmod) support, it is observed that,
we are creating more and more problems by treating am33xx device
as omap3 family, as nothing matches between them
(except cortex-A8 mpu).

So,  after long discussion we have came to the conclusion that,
we should not consider am33xx device as omap3 family, instead
create separate class (SOC_AM33XX) under OMAP2PLUS.
This means, for am33xx device, cpu_is_omap34xx() will return false,
and only cpu_is_am33xx() will be true.

Please refer to the link below, for mailing-list discussion on this -

http://www.spinics.net/lists/linux-omap/msg69439.htmlSigned-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: fixed typo, updated for soc_is changes]
Signed-off-by: NTony Lindgren <tony@atomide.com>

_omap3_sram_configure_core_dpll is called when SDRC is reprogrammed,
which is done regardless of CONFIG_PM setting, so we always need it's
setup code too. Without this, we hit a BUG() on OMAP3 when kernel is
built without CONFIG_PM:

Reprogramming SDRC clock to 332000000 Hz
------------[ cut here ]------------
kernel BUG at arch/arm/plat-omap/sram.c:342!
Internal error: Oops - BUG: 0 [#1] ARM
...
[<c001c694>] (omap3_configure_core_dpll+0x68/0x6c) from [<c001b2dc>] (omap3_core_dpll_m2_set_rate+0x1)
[<c001b2dc>] (omap3_core_dpll_m2_set_rate+0x138/0x1b0) from [<c001a478>] (omap2_clk_set_rate+0x14/0x2)
[<c001a478>] (omap2_clk_set_rate+0x14/0x20) from [<c001c9dc>] (clk_set_rate+0x54/0x74)
[<c001c9dc>] (clk_set_rate+0x54/0x74) from [<c022b9c8>] (omap_sdrc_init+0x70/0x90)
[<c022b9c8>] (omap_sdrc_init+0x70/0x90) from [<c022f178>] (omap3pandora_init+0x11c/0x164)
[<c022f178>] (omap3pandora_init+0x11c/0x164) from [<c022849c>] (customize_machine+0x20/0x28)
[<c022849c>] (customize_machine+0x20/0x28) from [<c0225810>] (do_one_initcall+0xa0/0x16c)
[<c0225810>] (do_one_initcall+0xa0/0x16c) from [<c02259e0>] (kernel_init+0x104/0x1ac)
[<c02259e0>] (kernel_init+0x104/0x1ac) from [<c0009cec>] (kernel_thread_exit+0x0/0x8)
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We currently treat the OCM RAM memory as memory that hangs off an
I/O bus, so use memset_io() to clear it rather than memset().
This also takes care of this sparse warning:

arch/arm/plat-omap/sram.c:199:9: warning: cast removes address space of expression

There is still one SRAM-related sparse warning, but it appears that
fixing it correctly will take some time and thought.

N.B., at some point, the OCM RAM IP block interface code should probably
be reimplemented as an MTD device or something similar under drivers/.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Update SRAM start & size for am33xx SoC's.

Note: cpu_is_34xx() is true for am33xx also. Doing
cpu_is_am33xx() check after cpu_is_34xx() will not
achieve what we want due to the above reason.
Hence cpu_is_am33xx() is done before cpu_is_34xx()
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@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>

According to comments in omap1_select_table_rate(), reprogramming dpll1
is tricky, and should always be done from SRAM.

While being at it, move OMAP730 special case handling inside
omap_sram_reprogram_clock().

Created on top of version 2 of the series "ARM: OMAP1: Fix dpll1
reprogramming related issues", which it depends on.
Tested on Amstrad Delta.
Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Now that we're always reprogramming the core clock we must make
sure SRAM works. It seems that neither omap1621 or omap1623
has 256K of SRAM. Set the SRAM size to safe value of 16K.
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>

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 assumes fixed mappings which will not work once we move
to use ioremap_exec(). It seems that these are currently
not in use, or in use for some out of tree corner cases.

If SRAM support for framebuffer is wanted, it should be done
with ioremap in the driver.

Note that further removal of the code can now be done,
but that can be done seprately by the driver maintainers.
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
is copied to internal SRAM at boot and after wake-up from CORE OFF
mode.  However only a small part of the code really needs to run from
internal SRAM.

This fix lets most of the ASM idle code run from the DDR in order to
minimize the SRAM usage and the overhead in the code copy.

The only pieces of code that are mandatory in SRAM are:
- the i443 erratum WA,
- the i581 erratum WA,
- the security extension code.

SRAM usage:
- original code:
  . 560 bytes for omap3_sram_configure_core_dpll (used by DVFS),
  . 852 bytes for omap_sram_idle (used by suspend/resume in RETention),
  . 124 bytes for es3_sdrc_fix (used by suspend/resume in OFF mode on ES3.x),
  . 108 bytes for save_secure_ram_context (used on HS parts only).

With this fix the usage for suspend/resume in RETention goes down 288
bytes, so the gain in SRAM usage for suspend/resume is 564 bytes.

Also fixed the SRAM initialization sequence to avoid an unnecessary
copy to SRAM at boot time and for readability.

Tested on Beagleboard (ES2.x) in idle with full RET and OFF modes.

Kevin Hilman tested retention and off on 3430/n900, 3530/Overo and
3630/Zoom3
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix below build warning.

 CC	arch/arm/plat-omap/sram.o
	arch/arm/plat-omap/sram.c: In function 'omap_map_sram':
	arch/arm/plat-omap/sram.c:224: warning: format '%08lx' expects
	type 'long unsigned int', but argument 2 has type 'unsigned int'

While at this, convert SRAM printk(* "") to pr_*("").
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The omap44xx_sram_init() implements functionality to push some
code on SRAM whenever the code can't be executed from external
memory. The low power and DVFS code can be executed from
external DDR itself thanks to OMAP4  memory controller hardware
support. So on OMAP4, sram_push kind of functionality isn't needed.

Hence remove the FIXME warning added for implementing sram push
feature on OMAP4.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The new fncpy API is better suited* for copying some
code to SRAM at runtime. This patch changes the ad-hoc
code to the more generic fncpy API.

*: 1. fncpy ensures that the thumb mode bit is propagated,
   2. fncpy provides the security of type safety between the
     original function and the sram function pointer.

Tested OK on OMAP3 in low power modes (RET/OFF)
using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL.
Compile tested on OMAP1/2 using omap1_defconfig.

Boot tested on OMAP1 & OMAP2
Tested OK with suspend/resume on OMAP2420/n810

Boots fine on osk5912 and n800
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NDave Martin <dave.martin@linaro.org>
Tested-by: NKevin Hilman <khilman@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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>

In preparation for adding OMAP4-specific PRCM accessor/mutator
functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
files.  Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
OMAP2xxx/3xxx-specific.

This process also requires the #includes in each of these files to be
changed to reference the new file name.  As part of doing so, add some
comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
"sideways includes", to indicate that these users of the PRM/CM includes
should not be doing so.

Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Acked-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: NFelipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

The SRAM PA addresses are locally defined and used at
different places, i.e. SRAM management code and idle sleep code.

The macros are now defined at a centralized place, for
easier maintenance.

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Nishanth Menon<nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Kernel was failing to boot on omap1611 based OSK boards due to
mis-configured SRAM size.  Existing code was using a hard-coded value
for 250k, which was then rounded down by PAGE_SIZE.  Increasing this to
256k allows kernel to boot on omap1611 SoCs.

Problem reported by and initial fix suggested by Tim Bird.

Thanks to Tony Lindgren for helping diagnose the problem to being
specific to OMAP1611 and not affecting OMAP1610/OMAP1623.
Reported-by: NTim Bird <tim.bird@am.sony.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Make some functions static to get rid of the following sparse warnings:

arch/arm/mach-omap1/mcbsp.c:177:12: warning: symbol 'omap1_mcbsp_init' was not declared. Should it be static?
arch/arm/mach-omap1/mux.c:346:22: warning: symbol 'omap1_cfg_reg' was not declared. Should it be static?
arch/arm/plat-omap/dma.c:177:5: warning: symbol 'omap_dma_in_1510_mode' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:273:12: warning: symbol 'omap1_sram_init' was not declared. Should it be static?
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Split plat-omap/common.c into three pieces:

1. the 32KiHz sync timer and clocksource code, which now lives in
   plat-omap/counter_32k.c;

2. the OMAP2+ common code, which has been moved to mach-omap2/common.c;

3. and the remainder of the OMAP-wide common code, which includes the
   deprecated ATAGs code and a deprecated video RAM reservation function.

The primary motivation for doing this is to move the OMAP2+-specific parts
into an OMAP2+-specific file, so that build breakage related to the
System Control Module code can be resolved.

Benoît Cousson <b-cousson@ti.com> suggested a new filename and found
some bugs in the counter_32k.c comments - thanks Benoît.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

This patch fixes sparse warnings due non declarations of static functions.

arch/arm/plat-omap/sram.c:130:13: warning: symbol 'omap_detect_sram' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:216:13: warning: symbol 'omap_map_sram' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:450:12: warning: symbol 'omap_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:348:12: warning: symbol 'omap242x_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:369:12: warning: symbol 'omap243x_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:425:12: warning: symbol 'omap34xx_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:441:12: warning: symbol 'omap44xx_sram_init' was not declared. Should it be static

arch/arm/plat-omap/mcbsp.c:36:6: warning: symbol 'omap_mcbsp_write' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:50:5: warning: symbol 'omap_mcbsp_read' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:65:6: warning: symbol 'omap_mcbsp_st_write' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:70:5: warning: symbol 'omap_mcbsp_st_read' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:1648:15: warning: symbol 'omap_st_add' was not declared. Should it be static?

arch/arm/plat-omap/fb.c:414:15: warning: symbol 'omapfb_reserve_sram' was not declared. Should it be static?
arch/arm/plat-omap/cpu-omap.c:43:5: warning: symbol 'omap_verify_speed' was not declared. Should it be static?
arch/arm/plat-omap/cpu-omap.c:61:14: warning: symbol 'omap_getspeed' was not declared. Should it be static?
Signed-off-by: NManjunath Kondaiah G <manjugk@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently we map 1 MB section while setting up SRAM on OMAPs
Regardless of the actual memory. The physical OCM RAM available
on OMAP SOCs is in order of KBs. This patch maps only available
sram and cleans up some un-necessary cpu_is_xxx checks.

Mapping un-available or non-accessible(secure) memory on the newer ARM
processor is dangerous. Because ARM CPUs can now speculatively prefetch,
we should avoid mapping any no-existing or secure memory.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

On OMAP4 there is no need to have SRAM_BOOTLOADER_SZ provision

Hence put this macro under CONFIG_ARCH_OMAP2PLUS check
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

For OMAP24xx/34xx/44xx: omap_type() returns the correct type:
 OMAP2_DEVICE_TYPE_TEST
 OMAP2_DEVICE_TYPE_EMU
 OMAP2_DEVICE_TYPE_SEC
 OMAP2_DEVICE_TYPE_GP
 OMAP2_DEVICE_TYPE_BAD

In current implementation there are two problems:
Problem 1:
For 34xx, the current if check will never return true.

Problem 2:
For 24xx the correct type check should be with omap_type() function
Verified by checking the TRM 24xx for CONTROL_STATUS register bits
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

We cannot use the omap34xx_sram_init(). It needs to be implemented
for omap4. Otherwise we get an error and the system won't boot:

Unhandled fault: imprecise external abort (0x1406) at 0xea963e94
...

Fix this by adding a dummy omap44xx_sram_init().
Signed-off-by: NTony Lindgren <tony@atomide.com>

Replace ARCH_OMAP34XX with ARCH_OMAP3
Signed-off-by: NTony Lindgren <tony@atomide.com>

Convert ARCH_OMAP24XX to ARCH_OMAP2
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes the public sram base address and available
size on OMAP4430.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:

- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations

The upcoming DSS2 uses VRAM manager.

VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Generalize the copy of SRAM functions into omap_push_sram_idle()
so it can be used on init but also after off-mode transitions.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Move the remaining headers under plat-omap/include/mach
to plat-omap/include/plat. Also search and replace the
files using these headers to include using the right path.

This was done with:

#!/bin/bash
mach_dir_old="arch/arm/plat-omap/include/mach"
plat_dir_new="arch/arm/plat-omap/include/plat"
headers=$(cd $mach_dir_old && ls *.h)
omap_dirs="arch/arm/*omap*/ \
drivers/video/omap \
sound/soc/omap"
other_files="drivers/leds/leds-ams-delta.c \
drivers/mfd/menelaus.c \
drivers/mfd/twl4030-core.c \
drivers/mtd/nand/ams-delta.c"

for header in $headers; do
	old="#include <mach\/$header"
	new="#include <plat\/$header"
	for dir in $omap_dirs; do
		find $dir -type f -name \*.[chS] | \
			xargs sed -i "s/$old/$new/"
	done
	find drivers/ -type f -name \*omap*.[chS] | \
		xargs sed -i "s/$old/$new/"
	for file in $other_files; do
		sed -i "s/$old/$new/" $file
	done
done

for header in $(ls $mach_dir_old/*.h); do
	git mv $header $plat_dir_new/
done
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch moves SRAM map to free up more kernel address io space.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch splits OMAP2_IO_ADDRESS to OMAP2_L3_IO_ADDRESS and
OMAP2_L4_IO_ADDRESS to reclaim more IO space.

The omap_read*() and omap_write*() functions will work only over
L4 address space. Current omap kernel stack uses these functions
only to access registers over L4 io address space

Note that these macros should only be used when ioremap does
not work. Please use ioremap instead in all new code.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

the original flush operation is to flush the function address which is
copied from.
But we do not change the function code and it is not necessary to flush it.
Signed-off-by: Njanboe <janboe.ye@gmail.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Search and replace OMAP_IO_ADDRESS with OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS,
and convert omap_read/write into a functions instead of a macros.

Also rename OMAP_MPUIO_VBASE to OMAP1_MPUIO_VBASE.

In the long run, most code should use ioremap + __raw_read/write instead.
Signed-off-by: NTony Lindgren <tony@atomide.com>

commit e85c205a increase vmalloc size.
vmalloc space will overlap with OMAP3 sram virtual address.
Signed-off-by: NLi Hong Mei <hong-mei.li@motorola.com>
Signed-off-by: NJanboe Ye <yuan-bo.ye@motorola.com>
Reviewed-by: NPaul Walmsley <paul@pwsan.com>

Some OMAP3 boards (Beagle Cx, Overo, RX51, Pandora) have 2
SDRAM parts connected to the SDRC.

This patch adds the following:
- add a new argument of type omap_sdrc_params struct*
to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
- adapted the OMAP boards files to the new prototype of
omap2_init_common_hw
- add the SDRC 2nd CS registers offsets defines
- adapt the sram sleep code to configure the SDRC for the 2nd CS

Note: If the 2nd param to omap2_init_common_hw is NULL, then the
parameters are not programmed into the SDRC CS1 registers

Tested on 3430 SDP and Beagleboard rev C2 and B5, with
suspend/resume and frequency changes (cpufreq).
Signed-off-by: NJean Pihet <jpihet@mvista.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

SRAM size fix for HS/EMU devices
Signed-off-by: NTero Kristo <tero.kristo@nokia.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Previously only 1 and 2 was supported. This is needed for DVFS VDD2 control.
Signed-off-by: NTero Kristo <tero.kristo@nokia.com>

Program the SDRC_MR_0 register as well during SDRC clock changes.
This register allows selection of the memory CAS latency.  Some SDRAM
chips, such as the Qimonda HYB18M512160AF6, have a lower CAS latency
at lower clock rates.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>