summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/sram34xx.S
Commit message (Collapse)AuthorAgeFilesLines
* OMAP3: SDRC: Place SDRC AC timing and MR changes in CORE DVFS SRAM code ↵Paul Walmsley2009-12-111-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behind Kconfig The code that reprograms the SDRC memory controller during CORE DVFS, mach-omap2/sram34xx.S:omap3_sram_configure_core_dpll(), does not ensure that all L3 initiators are prevented from accessing the SDRAM before modifying the SDRC AC timing and MR registers. This can cause memory to be corrupted or cause the SDRC to enter an unpredictable state. This patch places that code behind a Kconfig option, CONFIG_OMAP3_SDRC_AC_TIMING for now, and adds a note explaining what is going on. Ideally the code can be added back in once supporting code is present to ensure that other initiators aren't touching the SDRAM. At the very least, these registers should be reprogrammable during kernel init to deal with buggy bootloaders. Users who know that all other system initiators will not be touching the SDRAM can also re-enable this Kconfig option. This is a modification of a patch originally written by Rajendra Nayak <rnayak@ti.com> (the original is at http://patchwork.kernel.org/patch/51927/). Rather than removing the code completely, this patch just comments it out. Thanks to Benoît Cousson <b-cousson@ti.com> and Christophe Sucur <c-sucur@ti.com> for explaining the technical basis for this and for explaining what can be done to make this path work in future code. Thanks to Richard Woodruff <r-woodruff2@ti.com>, Nishanth Menon <nm@ti.com>, and Olof Johansson <olof@lixom.net> for their comments. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Christophe Sucur <c-sucur@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Olof Johansson <olof@lixom.net>
* OMAP3 SDRC: Move the clk stabilization delay to the right placeRajendra Nayak2009-07-241-2/+2
| | | | | | | | | The clock stabilization delay post a M2 divider change is needed even before a SDRC interface clock re-enable and not only before jumping back to SDRAM. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 SDRC: Fix freeze when scaling CORE dpll to < 83MhzRajendra Nayak2009-07-241-1/+1
| | | | | | | | | | | | | | | | | | | This patch fixes a bug in the CORE dpll scaling sequence which was errouneously clearing some bits in the SDRC DLLA CTRL register and hence causing a freeze. The issue was observed only on platforms which scale CORE dpll to < 83Mhz and hence program the DLL in fixed delay mode. Issue reported by Limei Wang <E12499@motorola.com>, with debugging assistance from Richard Woodruff <r-woodruff2@ti.com> and Girish Ghongdemath <girishsg@ti.com>. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Cc: Limei Wang <E12499@motorola.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Girish Ghongdemath <girishsg@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> [paul@pwsan.com: updated patch description to include collaboration credits]
* OMAP2/3 SDRC: don't set SDRC_POWER.PWDENA on bootPaul Walmsley2009-07-241-2/+0
| | | | | | | | | | | | | Stop setting SDRC_POWER.PWDENA on boot. There is a nasty erratum (34xx erratum 1.150) that can cause memory corruption if PWDENA is enabled. Based originally on a patch from Samu P. Onkalo <samu.p.onkalo@nokia.com>. Tested on BeagleBoard rev C2. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Samu P. Onkalo <samu.p.onkalo@nokia.com>
* OMAP3 SDRC: add support for 2 SDRAM chip selectsJean Pihet2009-07-241-30/+107
| | | | | | | | | | | | | | | | | | | | | | 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: Jean Pihet <jpihet@mvista.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 SDRC: set FIXEDDELAY when disabling SDRC DLLPaul Walmsley2009-06-191-0/+12
| | | | | | | | | | Correspondence with the TI OMAP hardware team indicates that SDRC_DLLA_CTRL.FIXEDDELAY should be initialized to 0x0f. This number was apparently derived from process validation. This is only used when the SDRC DLL is unlocked (e.g., SDRC clock frequency less than 83MHz). Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3: Add support for DPLL3 divisor values higher than 2Tero Kristo2009-06-191-3/+5
| | | | | | Previously only 1 and 2 was supported. This is needed for DVFS VDD2 control. Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
* OMAP3 SRAM: convert SRAM code to use macros rather than magic numbersPaul Walmsley2009-06-191-15/+38
| | | | | | | Convert omap3_sram_configure_core_dpll() to use macros rather than magic numbers. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 SRAM: add more comments on the SRAM codePaul Walmsley2009-06-191-21/+24
| | | | | | Clean up comments and copyrights on the CORE DPLL3 M2 divider change code. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 clock/SDRC: program SDRC_MR register during SDRC clock changePaul Walmsley2009-06-191-1/+7
| | | | | | | | | 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: Paul Walmsley <paul@pwsan.com>
* OMAP3 clock: add a short delay when lowering CORE clk ratePaul Walmsley2009-06-191-11/+9
| | | | | | | | | | | | | When changing the SDRAM clock from 166MHz to 83MHz via the CORE DPLL M2 divider, add a short delay before returning to SDRAM to allow the SDRC time to stabilize. Without this delay, the system is prone to random panics upon re-entering SDRAM. This time delay varies based on MPU frequency. At 500MHz MPU frequency at room temperature, 64 loops seems to work okay; so add another 32 loops for environmental and process variation. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 clock: remove wait for DPLL3 M2 clock to stabilizePaul Walmsley2009-06-191-3/+0
| | | | | | | | The original CDP kernel that this code comes from waited for 0x800 loops after switching the CORE DPLL M2 divider. This does not appear to be necessary. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 clock: only unlock SDRC DLL if SDRC clk < 83MHzPaul Walmsley2009-05-121-6/+7
| | | | | | | | | | | | According to the 34xx TRM Rev. K section 11.2.4.4.11.1 "Purpose of the DLL/CDL Module," the SDRC delay-locked-loop can be locked at any SDRC clock frequency from 83MHz to 166MHz. CDP code unconditionally unlocked the DLL whenever shifting to a lower SDRC speed, but this seems unnecessary and error-prone, as the DLL is no longer able to compensate for process, voltage, and temperature variations. Instead, only unlock the DLL when the SDRC clock rate would be less than 83MHz. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 SRAM: renumber registers to make space for argument passingPaul Walmsley2009-05-121-57/+57
| | | | | | | Renumber registers in omap3_sram_configure_core_dpll() assembly code to make space for additional parameters. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 SRAM: clear the SDRC PWRENA bit during SDRC frequency changePaul Walmsley2009-05-121-3/+4
| | | | | | | | Clear the SDRC_POWER.PWRENA bit before putting the SDRAM into self-refresh mode. This prevents the SDRC from attempting to power off the SDRAM, which can cause the system to hang. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 clock: add interconnect barriers to CORE DPLL M2 changePaul Walmsley2009-05-121-3/+6
| | | | | | | Where necessary, add interconnect barriers to force posted writes to complete before continuing. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 SRAM: add ARM barriers to omap3_sram_configure_core_dpllPaul Walmsley2009-05-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add more barriers in the SRAM CORE DPLL M2 divider change code. - Add a DSB SY after the function's entry point to flush all cached and buffered writes and wait for the interconnect to claim that they have completed[1]. The idea here is to force all delayed write traffic going to the SDRAM to at least post to the L3 interconnect before continuing. If these writes are allowed to occur after the SDRC is idled, the writes will not be acknowledged and the ARM will stall. Note that in this case, it does not matter if the writes actually complete to the SDRAM - it is only necessary for the writes to leave the ARM itself. If the writes are posted by the interconnect when the SDRC goes into idle, the writes will be delayed until the SDRC returns from idle[2]. If the SDRC is in the middle of a write when it is requested to enter idle, the SDRC will not acknowledge the idle request until the writes complete to the SDRAM.[3] The old-style DMB in sdram_in_selfrefresh is now superfluous, so, remove it. - Add an ISB before the function's exit point to prevent the ARM from speculatively executing into SDRAM before the SDRAM is enabled[4]. ... 1. ARMv7 ARM (DDI 0406A) A3-47, A3-48. 2. Private communication with Richard Woodruff <r-woodruff2@ti.com>. 3. Private communication with Richard Woodruff <r-woodruff2@ti.com>. 4. ARMv7 ARM (DDI 0406A) A3-48. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
* ARM: OMAP3: Add minimal omap3430 supportSyed Mohammed, Khasim2008-10-091-0/+179
Add minimal omap3430 support based on earlier patches from Syed Mohammed Khasim. Also merge in omap34xx SRAM support from Karthik Dasu and use consistent naming for sram init functions. Also do following changes that make 34xx support usable: - Remove unused sram.c functions for 34xx - Rename IRQ_SIR_IRQ to INTCPS_SIR_IRQ and define it locally in entry-macro.S - Update mach-omap2/io.c to support 2420, 2430, and 34xx - Also merge in 34xx GPMC changes to add fields wr_access and wr_data_mux_bus from Adrian Hunter - Remove memory initialization call omap2_init_memory() until until more generic memory initialization patches are posted. It's OK to rely on bootloader initialization until then. Signed-off-by: Syed Mohammed, Khasim <khasim@ti.com> Signed-off-by: Karthik Dasu<karthik-dp@ti.com> Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
OpenPOWER on IntegriCloud