summaryrefslogtreecommitdiffstats
path: root/arch/arm/include/asm/arch-omap4/sys_proto.h
Commit message (Collapse)AuthorAgeFilesLines
* ARM: OMAP2+: Rename asm/arch/clocks.h asm/arch/clock.hLokesh Vutla2013-06-101-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>
* am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.cTom Rini2013-06-051-0/+1
| | | | | | | | | | | We need to call the save_omap_boot_params function on am33xx/ti81xx and other newer TI SoCs, so move the function to boot-common. Only OMAP4+ has the omap_hw_init_context function so add ifdefs to not call it on am33xx/ti81xx. Call save_omap_boot_params from s_init on am33xx/ti81xx boards. Reviewed-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Tom Rini <trini@ti.com>
* ARM: OMAP: Cleanup boot parameters usageSRICHARAN R2013-05-101-8/+3
| | | | | | | | | | | The boot parameters are read from individual variables assigned for each of them. This been corrected and now they are stored as a part of the global data 'gd' structure. So read them from 'gd' instead. Signed-off-by: Sricharan R <r.sricharan@ti.com> [trini: Add igep0033 hunk] Signed-off-by: Tom Rini <trini@ti.com>
* ARM: OMAP5: Fix warm reset with USB cable connectedLokesh Vutla2013-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Warm reset on OMAP5 freezes when USB cable is connected. Fix requires PRM_RSTTIME.RSTTIME1 to be programmed with the time for which reset should be held low for the voltages and the oscillator to reach stable state. There are 3 parameters to be considered for calculating the time, which are mostly board and PMIC dependent. -1- Time taken by the Oscillator to shut + restart -2- PMIC OTP times -3- Voltage rail ramp times, which inturn depends on the PMIC slew rate and value of the voltage ramp needed. In order to keep the code in u-boot simple, have a way for boards to specify a pre computed time directly using the 'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC' option. If boards fail to specify the time, use a default as specified by 'CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC' instead. Using the default value translates into some ~22ms and should work in all cases. However in order to avoid this large delay hiding other bugs, its recommended that all boards look at their respective data sheets and specify a pre computed and optimal value using 'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC' In order to help future board additions to compute this config option value, add a README at doc/README.omap-reset-time which explains how to compute the value. Also update the toplevel README with the additional option and pointers to doc/README.omap-reset-time. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> [rnayak@ti.com: Updated changelog and added the README] Signed-off-by: Rajendra Nayak <rnayak@ti.com>
* ARM: OMAP4+: Change the PRCM structure prototype common for all SocsSRICHARAN R2013-03-111-1/+1
| | | | | | | | | | | | 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>
* omap-common: SPL: Add CONFIG_SPL_DISPLAY_PRINT / spl_display_print()Tom Rini2012-09-271-1/+0
| | | | | | | | Only omap4/5 currently have a meaningful set of display text and overo had been adding a function to display nothing. Change how this works to be opt-in and only turned on for omap4/5 now. Signed-off-by: Tom Rini <trini@ti.com>
* OMAP4+: Force DDR in self-refresh after warm resetLokesh Vutla2012-07-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: OMAP3+: Detect reset typeLokesh Vutla2012-07-071-0/+1
| | | | | | | | | | | | Certain modules are not affected by means of a warm reset and need not be configured again. Adding an API to detect the reset reason warm/cold. This will be used to skip the module configurations that are retained across a warm reset. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: R Sricharan <r.sricharan@ti.com>
* OMAP4/5: Make the silicon revision variable common.SRICHARAN R2012-05-151-6/+0
| | | | | | | | The different silicon revision variable names was defined for OMAP4 and OMAP5 socs. Making the variable common so that some code can be made generic. Signed-off-by: R Sricharan <r.sricharan@ti.com>
* OMAP3+: Introduce generic logic for OMAP voltage controllerNishanth Menon2012-05-151-0/+2
| | | | | | | | | | | | | | | | | | | | OMAP Voltage controller is used to generically talk to PMICs on OMAP3,4,5 over I2C_SR. Instead of replicating code in multiple SoC code, introduce a common voltage controller logic which can be re-used from elsewhere. With this change, we replace setup_sri2c with omap_vc_init which has the same functionality, and replace the voltage scale replication in do_scale_vcore and do_scale_tps62361 with omap_vc_bypass_send_value. omap_vc_bypass_send_value can also now be used with any configuration of PMIC. NOTE: Voltage controller controlling I2C_SR is a write-only data path, so no register read operation can be implemented. Reported-by: Isabelle Gros <i-gros@ti.com> Reported-by: Jerome Angeloni <j-angeloni@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
* omap_rev_string: output to stdoutAndreas Müller2012-01-161-1/+1
| | | | | | | | * avoid potential buffer overflows * allow SPL-build not to output "Texas Instruments Revision detection unimplemented" Signed-off-by: Andreas Müller <schnitzeltony@gmx.de> Signed-off-by: Tom Rini <trini@ti.com>
* omap4/5: Add support for booting with CH.Sricharan2011-11-151-8/+17
| | | | | | | | | | | | | | | | Configuration header(CH) is 512 byte header attached to an OMAP boot image that will help ROM code to initialize clocks, SDRAM etc and copy U-Boot directly into SDRAM. CH can help us in by-passing SPL and directly boot U-boot, hence it's an alternative for SPL. However, we intend to support both CH and SPL for OMAP4/5. Initialization done through CH is limited and is not equivalent to that done by SPL. So U-Boot has to distinguish between the two cases and handle them accordingly. This patch takes care of doing this. 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-151-2/+0
| | | | | | | | | | | | 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-151-3/+8
| | | | | | | | | | | | | | | | 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>
* OMAP3 SPL: Provide weak omap_rev_stringTom Rini2011-10-271-1/+0
| | | | | | | | | We add an weak version of omap_rev_string in omap-common/spl.c and while at it drop the omap3 version. Move the prototype over to <asm/omap_common.h> with the other SPL functions. Signed-off-by: Tom Rini <trini@ti.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* omap: add basic SPL supportAneesh V2011-08-031-0/+1
| | | | | | | | | | | | | - Provide alternate implementations of board_init_f() board_init_r() for OMAP spl. - Provide linker script - Initialize global data - Add serial console support - Update CONFIG_SYS_TEXT_BASE to allow for SPL's bss and move it to board config header from config.mk Signed-off-by: Aneesh V <aneesh@ti.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* omap4: calculate EMIF register valuesAneesh V2011-08-031-0/+1
| | | | | | | | | | | | | | Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values. For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values. Signed-off-by: Aneesh V <aneesh@ti.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* omap4: add sdram init supportAneesh V2011-08-031-0/+2
| | | | | | | Add support for the SDRAM controller (EMIF). Signed-off-by: Aneesh V <aneesh@ti.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* omap4: add clock supportAneesh V2011-08-031-0/+8
| | | | | | | | | | | | | | Add support for: 1. DPLL locking 2. Initialization of clock domains and clock modules 3. Setting up the right voltage on voltage rails This work draws upon previous work done for x-loader by: Santosh Shilimkar <santosh.shilimkar@ti.com> Rajendra Nayak <rnayak@ti.com> Signed-off-by: Aneesh V <aneesh@ti.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* omap4: add OMAP4430 revision checkAneesh V2011-08-031-0/+7
| | | | | Signed-off-by: Aneesh V <aneesh@ti.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* omap4: cleanup pin mux dataAneesh V2011-08-031-1/+3
| | | | | | | | | | | | | - separate mux settings into essential and non essential parts - essential part is board independent as of now(so move it to SoC directory). Will help in having single SPL for all boards. - Non-essential part(the pins not essential for u-boot to function) need to be phased out eventually. - Correct mux data by aligning to the latest settings in x-loader Signed-off-by: Aneesh V <aneesh@ti.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* omap4: utility function to identify the context of hw initAneesh V2011-08-031-1/+48
| | | | | | | | | | | | | | | | The basic hardware init of OMAP4(s_init()) can happen in 4 different contexts: 1. SPL running from SRAM 2. U-Boot running from FLASH 3. Non-XIP U-Boot loaded to SDRAM by SPL 4. Non-XIP U-Boot loaded to SDRAM by ROM code using the Configuration Header feature What level of hw initialization gets done depends on this context. Add a utility function to find this context. Signed-off-by: Aneesh V <aneesh@ti.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* armv7: adapt omap4 to the new cache maintenance frameworkAneesh V2011-07-041-1/+1
| | | | | | adapt omap4 to the new layered cache maintenance framework Signed-off-by: Aneesh V <aneesh@ti.com>
* ARMV7: OMAP: Move syslib.c to omap-common since it can be shared by OMAP3 ↵Steve Sakoman2010-09-081-0/+3
| | | | | | | | | | and OMAP4 The functions in syslib.c can be shared, so this patch moves it from cpu/omap3 to cpu/omap-common Signed-off-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* ARMV7: Add pad mux support for OMAP4Steve Sakoman2010-08-051-0/+1
| | | | | | | | | | Add functional multiplexing support for OMAP4 pads. Configure all the pads for the OMAP4430 SDP and OMAP4 Panda boards Signed-off-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Aneesh V <aneesh@ti.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* ARMV7: Add basic gpmc initialization for OMAP4Steve Sakoman2010-07-151-0/+1
| | | | | | | | This patch adds a gpmc_init function for OMAP4 and adds calls to gpmc_init for existing OMAP4 boards: panda and sdp4430 Signed-off-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
* ARMV7: Add basic support for TI OMAP4Steve Sakoman2010-07-051-0/+37
This patch adds minimum support for OMAP4. Code which can be shared between OMAP3 and OMAP4 is placed in arch/arm/cpu/armv7/omap-common Signed-off-by: Aneesh V <aneesh@ti.com> Signed-off-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
OpenPOWER on IntegriCloud