summaryrefslogtreecommitdiff
path: root/arch/arm/cpu/armv7/omap-common/emif-common.c
Commit message (Collapse)AuthorAgeLines
* arm: omap-common: emif: allow to map memory without interleavingFelipe Balbi2014-12-04-4/+5
| | | | | | | | | 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>
* ARM: DRA7: Enable software leveling for dra7Sricharan R2014-08-25-37/+1
| | | | | | | | | | 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>
* ARM: DRA72x: Update EMIF dataLokesh Vutla2014-05-23-2/+4
| | | | | | | | 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>
* DRA7: Add support for ES1.1 silicon ID codeNishanth Menon2014-01-24-3/+2
| | | | | | | | 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>
* ARM: AM43xx: GP_EVM: Add support for DDR3Lokesh Vutla2013-12-18-14/+0
| | | | | | | | | | | | | | | | 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>
* ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039SRICHARAN R2013-12-04-0/+42
| | | | | | | | | | | 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>
* ARM: DRA: EMIF: Change DDR3 settings to use hw levelingSRICHARAN R2013-12-04-29/+71
| | | | | | | | | | 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>
* omap: emif: Set initial DDR PHY config firstTaras Kondratiuk2013-08-15-1/+1
| | | | | | | | | Commit "OMAP5: emif/ddr: Change emif settings as required for ES1.0 silicon" (f40107345cbcd6e0d1747eda45e76c4e2a6df0db) 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>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-24-17/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* ARM: OMAP4+: Fix MA detection during SDRAM_AUTO_DETECTIONLokesh Vutla2013-07-02-0/+3
| | | | | | | | | | | 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>
* ARM: DRA7xx: EMIF: Change settings required for EVM boardSricharan R2013-06-10-3/+23
| | | | | | | | | | | 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>
* ARM: OMAP2+: Rename asm/arch/clocks.h asm/arch/clock.hLokesh Vutla2013-06-10-1/+1
| | | | | | | To be consistent with other ARM platforms, renaming asm/arch-omap*/clocks.h to asm/arch-omap*/clock.h Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* arm: omap: emif: Fix DDR3 init after warm resetLokesh Vutla2013-05-10-3/+8
| | | | | | | | | | | | | | | | 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>
* arm: omap4: Fix SDRAM AUTO DETECTIONLokesh Vutla2013-04-08-13/+16
| | | | | | | | | | | | | | 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>
* arm: dra7xx: Add DDR related data for DRA752 ES1.0Lokesh Vutla2013-03-11-1/+1
| | | | | | | | | | 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>
* ARM: OMAP4+: Cleanup emif specific filesLokesh Vutla2013-03-11-37/+9
| | | | | | | | | | | | 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>
* ARM: OMAP4+: Change the PRCM structure prototype common for all SocsSRICHARAN R2013-03-11-2/+2
| | | | | | | | | | | | 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>
* ARM: OMAP4+: emif: Detect SDRAM from SDRAM config registerLokesh Vutla2013-03-11-4/+17
| | | | | | | | | | | 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>
* 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>
generated by cgit v1.1 at 2024-11-18 19:59:23 +0000