Commit graph

14 commits

Author SHA1 Message Date
SRICHARAN R
254763822e ARM: OMAP4+: Move external phy initialisations to arch specific place.
The external phy is present in the case OMAP5 soc is currently
configured in emif-common.c. This results in having dummy structures
for those Socs which do not have a external phy. So by having a weak
function in emif-common and overriding it in OMAP5, avoids the use
of dummy structures.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
2012-07-07 14:07:35 +02:00
Steve Sakoman
ad0878a749 omap: emif: fix bug in manufacturer code test
Code currently tests for <= 0xff.  Micron manufacturer code is 0xff, so
Micron memory will not be detected!

Signed-off-by: Steve Sakoman <steve@sakoman.com>
2012-07-07 14:07:35 +02:00
Steve Sakoman
55c1284942 omap: emif: deal with rams that return duplicate mr data on all byte lanes
Some rams (Micron for example) return duplicate mr data on all byte lanes.

Users of the get_mr function currently don't deal with this duplicated
data gracefully.  This patch detects the duplicated data and returns only
the expected 8 bit mr data.

Signed-off-by: Steve Sakoman <steve@sakoman.com>
2012-07-07 14:07:35 +02:00
Lokesh Vutla
38f25b125e OMAP4+: Force DDR in self-refresh after warm reset
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: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
2012-07-07 14:07:35 +02:00
Lokesh Vutla
784229cc25 OMAP4+: Handle sdram init after warm reset
EMIF and DDR device state are preserved in warmreset.  Redoing the full
initialisation would cause unexpected behaviour.  Do only partial
initialisation to account for frequency change.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
2012-07-07 14:07:34 +02:00
Lokesh Vutla
753bae8c5d OMAP5: DPLL core lock for OMAP5432
No need to Unlock DPLL initially.
DDR3 can work at normal OPP from initialozation

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2012-07-07 14:07:24 +02:00
Lokesh Vutla
784ab7c545 OMAP5: EMIF: Add support for DDR3 device
In OMAP5432 EMIF controlller supports DDR3 device.
This patch adds support for ddr3 device intialization and configuration.
Initialization sequence is done as specified in JEDEC specs.
This also adds support for ddr3 leveling.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2012-07-07 14:07:24 +02:00
SRICHARAN R
41321fd4d6 ARM: OMAP5: Align memory used for testing to the power of 2
get_ram_size checks the given memory range for valid ram,
but expects the size of memory to be aligned to the power
of 2. In case of OMAP5 evm board the memory available is
2GB - 16MB(used for TRAP section) = 2032MB.

So always ensure that the size of memory used for testing is
aligned to the power of 2.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
2012-07-07 14:07:22 +02:00
SRICHARAN R
f40107345c OMAP5: emif/ddr: Change emif settings as required for ES1.0 silicon.
The OMAP5 silicon has new DDR PHY design, which includes a external PHY
as well. So configuring the ext PHY parameters here. Also the EMIF timimg
registers and a couple of DDR mode registers needs to be updated based on
the testing from the actual silicon.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
2012-05-15 08:31:23 +02:00
Aneesh V
4324c118a0 omap4: emif: fix error in driver
There was a typo in the EMIF driver. It went un-noticed
because it affected only when automatic detection is enabled
and even then half the memory was configured and identified
properly.

Reported-by: Rockefeller <rockefeller.lin@innocomm.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
2011-12-06 23:59:34 +01:00
Sricharan
bb772a5944 omap5: emif: Add emif/ddr configurations required for omap5 evm
Add the emif configurations required for omap5 soc.Add the
correct ddr part configurations required for omap5 evm board.
EDB8164B3PH from ELPIDA is the part used on the board.

Also changes are done to retain some part of the code
common for OMAP4/5 and keep only the remaining in the Soc
specific directories.

Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-11-15 22:25:50 +01:00
Sricharan
2e5ba48928 omap5: clocks: Add clocks support for omap5 platform.
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: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-11-15 22:25:50 +01:00
Sricharan
508a58fa8e omap5: Add minimal support for omap5430.
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: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-11-15 22:25:50 +01:00
Sricharan
ce170beeb7 omap4: make omap4 code common for future reuse
Much of omap4 soc support code can be reused for omap5.
Move them to the omap-common directory to facilitate
this.

Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2011-11-15 22:25:50 +01:00
Renamed from arch/arm/cpu/armv7/omap4/emif.c (Browse further)