summaryrefslogtreecommitdiff
path: root/arch/arm/cpu/armv7/omap-common/emif-common.c
Commit message (Collapse)AuthorAgeLines
* omap: emif: configure emif only when requiredLokesh Vutla2012-12-10-5/+36
| | | | | | | | 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>
* ARM: OMAP4+: Move external phy initialisations to arch specific place.SRICHARAN R2012-07-07-26/+6
| | | | | | | | | | 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>
* omap: emif: fix bug in manufacturer code testSteve Sakoman2012-07-07-1/+1
| | | | | | | 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>
* omap: emif: deal with rams that return duplicate mr data on all byte lanesSteve Sakoman2012-07-07-1/+6
| | | | | | | | | | 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>
* OMAP4+: Force DDR in self-refresh after warm resetLokesh Vutla2012-07-07-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAP4+: Handle sdram init after warm resetLokesh Vutla2012-07-07-4/+6
| | | | | | | | | | 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>
* OMAP5: DPLL core lock for OMAP5432Lokesh Vutla2012-07-07-4/+9
| | | | | | | No need to Unlock DPLL initially. DDR3 can work at normal OPP from initialozation Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* OMAP5: EMIF: Add support for DDR3 deviceLokesh Vutla2012-07-07-3/+102
| | | | | | | | | 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>
* ARM: OMAP5: Align memory used for testing to the power of 2SRICHARAN R2012-07-07-0/+3
| | | | | | | | | | | | 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>
* OMAP5: emif/ddr: Change emif settings as required for ES1.0 silicon.SRICHARAN R2012-05-15-2/+39
| | | | | | | | | 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>
* omap4: emif: fix error in driverAneesh V2011-12-06-2/+2
| | | | | | | | | | 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>
* omap5: emif: Add emif/ddr configurations required for omap5 evmSricharan2011-11-15-202/+88
| | | | | | | | | | | | | 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>
* omap5: clocks: Add clocks support for omap5 platform.Sricharan2011-11-15-1/+1
| | | | | | | | | | | | 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>
* omap5: Add minimal support for omap5430.Sricharan2011-11-15-2/+2
| | | | | | | | | | | | | | | | 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>
* omap4: make omap4 code common for future reuseSricharan2011-11-15-0/+1254
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>