The recent changes for hw leveling on am33xx were not intended for
DDR2 boards, only DDR3. Update emif_sdram_type to take a sdram_config
value to check against. This lets us pass in the value we would use to
configure, when we have not yet configured the board yet. In other cases
update the call to be as functional as before and check an already
programmed value in.
Tested-by: Yan Liu <yan-liu@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
DRA7 EMIF supports Full leveling for DDR3.
Adding support for the Full leveling sequence.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The value in SDRAM_REF_CTRL controls the delay time between
the initial rising edge of DDR_RESETn to rising edge of DDR_CKE
(JEDEC specs this as 500us). In order to achieve this, SDRAM_REF_CTRL
should be written with a value corresponding to 500us delay before
starting DDR initialization sequence, and configure proper
value at the end of sequence.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
If we want to have two sections, one on each EMIF, without
interleaving, current code wouldn't enable emif2. Fix that
problem.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Currently hw leveling is enabled by default on DRA7/72.
But the hardware team suggested to use sw leveling as hw leveling
is not characterized and seen some test case failures.
So enabling sw leveling on all DRA7 platforms.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
DRA72 has 1GB connected to EMIF1 only. Updating the details.
And also enable WA for BUG0039 only if corresponding EMIF is present.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Tom Rini <trini@ti.com>
ES1.1 silicon is a very minor variant of ES1.0. Add priliminary support
for ES1.1 IDCODE change.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
GP EVM has 1GB DDR3 attached(Part no: MT41K512M8RH).
Adding details for the same.
Below is the brief description of DDR3 init sequence(SW leveling):
-> Enable VTT regulator
-> Configure VTP
-> Configure DDR IO settings
-> Disable initialization and refreshes until EMIF registers are programmed.
-> Program Timing registers
-> Program leveling registers
-> Program PHY control and Temp alert and ZQ config registers.
-> Enable initialization and refreshes and configure SDRAM CONFIG register
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
When core power domain hits oswr, then DDR3 memories does not come back
while resuming. This is because when EMIF registers are lost, then the
controller takes care of copying the values from the shadow registers.
If the shadow registers are not updated with the right values, then this
results in incorrect settings while resuming. So updating the shadow registers
with the corresponding status registers here during the boot.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done since hardware leveling was not
working. Now that the right sequence to do hw leveling is identified,
use it. This is required for EMIF clockdomain to idle and come back
during lowpower usecases.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Commit "OMAP5: emif/ddr: Change emif settings as required for ES1.0 silicon"
(f40107345c)
changed sequence to set final DDR PHY config register value at the beginning.
Looks like it was made by mistake and should be reverted.
Signed-off-by: Taras Kondratiuk <taras@ti.com>
During SDRAM_AUTO_DETECTION MA is not configured.
For Soc's > OMAP4460 MA is present. So populating
MA for the same.
Tested on OMAP4430 PANDA, OMAP4460 PANDA.
Reported-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
DRA7 EVM board has the below configuration. Adding the
settings for the same here.
2Gb_1_35V_DDR3L part * 2 on EMIF1
2Gb_1_35V_DDR3L part * 4 on EMIF2
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
EMIF supports a global warm reset mode, during which the
EMIF keeps the SDRAM content. But if leveling is enabled
at the time of warm reset for DDR3, the following steps
needs to be done after warm reset:
1) Keep EMIF in self refresh mode.
2) Reset PHY to bring back the PHY to a known state.
3) Start Levelling procedure.
Doing the same.
And also enabling DLL lock and code output after warm reset.
Tested on OMAP5432 ES2.0
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Commit "8602114 omap: emif: configure emif only when required"
breaks SDRAM_AUTO_DETECTION.
The issue is dmm_init() depends on emif_sizes[](SDRAM Auto detection)
done in do_sdram_init(). The above commit moves dmm_init() above
do_sdram_init() because of which dmm_init() uses uninitialized
emif_sizes[].
So instead of using global emif_sizes[], get sdram details locally
and calculate emif sizes.
Reported-by: Michael Cashwell <mboards@prograde.net>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
DRA752 uses DDR3. Populating the corresponding structures
with DDR3 data.
Writing into MA registers if only MA is present in that soc.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Removing the duplicated code in ddr3 initialization.
Also creating structure for lpddr2 mode registers to
avoid unnessecary revision checks.
These change reduces code addition for future Socs.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom 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: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
unnessecary cpu checks for new boards
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
DMM_LISA_MAP registers program whether memory is mapped
on particular EMIF or not. Irrespective of these registers
EMIF is getting configured. Correcting the same.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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)
