summaryrefslogtreecommitdiff
path: root/arch/arm/include/asm/arch-omap5
Commit message (Collapse)AuthorAgeLines
* omap4/5/am33xx: Make lowlevel_init available to all armv7 platformsTom Rini2012-09-01-2/+0
| | | | | | | | | | | | | | Make the lowlevel_init function that these platforms have which just sets up the stack and calls a C function available to all armv7 platforms. As part of this we change some of the macros that are used to be more clear. Previously (except for am335x evm) we had been setting CONFIG_SYS_INIT_SP_ADDR to a series of new defines that are equivalent to simply referencing NON_SECURE_SRAM_END. On am335x evm we should have been doing this initially and do now. Cc: Sricharan R <r.sricharan@ti.com> Tested-by: Allen Martin <amartin@nvidia.com> Signed-off-by: Tom Rini <trini@ti.com>
* OMAP4+: Force DDR in self-refresh after warm resetLokesh Vutla2012-07-07-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-07-0/+3
| | | | | | | | | | | | 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>
* OMAP5: Change voltages for omap5432Lokesh Vutla2012-07-07-0/+10
| | | | | | Change voltages for OMAP5432 Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* OMAP5: DPLL core lock for OMAP5432Lokesh Vutla2012-07-07-0/+5
| | | | | | | No need to Unlock DPLL initially. DDR3 can work at normal OPP from initialozation Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* OMAP5: Configure the io settings for omap5432 uevm boardLokesh Vutla2012-07-07-1/+14
| | | | | | This patch adds the IO settings required for OMAP5432 uevm's DDR3 pads Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* OMAP5: ADD chip detection for OMAP5432 SOCLokesh Vutla2012-07-07-1/+2
| | | | | | This patch adds chip detection for OMAP5432 Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* OMAP5: Adding correct Control id code for OMAP5430Lokesh Vutla2012-07-07-1/+1
| | | | | | | Control id code for omap5430 ES1.0 is hard coded with a wrong value. This patch corrects the value Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* ARM: OMAP5: Correct the DRAM_ADDR_SPACE_END macro.SRICHARAN R2012-07-07-1/+1
| | | | | | | OMAP5 evm board has 2GB of memory. So correct the macro to take in to account of the full dram size. Signed-off-by: R Sricharan <r.sricharan@ti.com>
* omap4+: Avoid using __attribute__ ((__packed__))Aneesh V2012-05-15-1/+1
| | | | | | | | | | | | | Avoid using __attribute__ ((__packed__)) unless it's absolutely necessary. "packed" will remove alignment requirements for the respective objects and may cause alignment issues unless alignment is also enforced using a pragma. Here, these packed attributes were causing alignment faults in Thumb build. Signed-off-by: Aneesh V <aneesh@ti.com>
* OMAP3+: reset: Create a common reset layer.SRICHARAN R2012-05-15-11/+11
| | | | | | | | | The reset.S has the function to do a warm reset on OMAP based socs. Moving this to a reset.c file so that this acts a common layer to add any reset related functionality for the future. Signed-off-by: R Sricharan <r.sricharan@ti.com>
* omap5: pbias ldo9 turn onBalaji T K2012-05-15-3/+4
| | | | | | | Add omap5 pbias configuration for mmc1/sd lines and set voltage for sd data i/o lines Signed-off-by: Balaji T K <balajitk@ti.com>
* OMAP4/5: device: Add support to get the device type.SRICHARAN R2012-05-15-0/+4
| | | | | | Add support to identify the device as GP/EMU/HS. Signed-off-by: R Sricharan <r.sricharan@ti.com>
* OMAP4/5: Make the sysctrl structure commonSRICHARAN R2012-05-15-6/+7
| | | | | | | | | Make the sysctrl structure common, so that it can be used in generic functions across socs. Also change the base address of the system control module, to include all the registers and not simply the io regs. Signed-off-by: R Sricharan <r.sricharan@ti.com>
* OMAP5: SRAM: Change the SRAM base address.SRICHARAN R2012-05-15-1/+1
| | | | | | | The full internal SRAM of size 128kb is public in the case of OMAP5 soc. So change the base address accordingly. Signed-off-by: R Sricharan <r.sricharan@ti.com>
* OMAP4/5: Make the silicon revision variable common.SRICHARAN R2012-05-15-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>
* OMAP5: palmas: Configure nominal opp vdd valuesSRICHARAN R2012-05-15-5/+11
| | | | | | | | | | | The nominal opp vdd values as recommended for ES1.0 silicon is set for mpu, core, mm domains using palmas. Also used the right sequence to enable the vcores as per a previous patch from Nishant Menon, which can be dropped now. http://lists.denx.de/pipermail/u-boot/2012-March/119151.html Signed-off-by: R Sricharan <r.sricharan@ti.com>
* OMAP5: io: Configure the io settings for omap5430 sevm board.SRICHARAN R2012-05-15-24/+104
| | | | | | | | | The control module provides options to set various signal integrity parameters like the output impedance, slew rate, load capacitance for different pad groups. Configure these as required for the omap5430 sevm board. Signed-off-by: R Sricharan <r.sricharan@ti.com>
* OMAP5: board: Add pinmux data for omap5_evm board.SRICHARAN R2012-05-15-252/+250
| | | | | | Adding the full pinmux data for OMAP5430 sevm board. Signed-off-by: R Sricharan <r.sricharan@ti.com>
* OMAP5: clocks: Change clock settings as required for ES1.0 silicon.SRICHARAN R2012-05-15-3/+16
| | | | | | | | Aligning all the clock related settings like the dpll frequencies, their respective clock outputs, etc to the ideal values recommended for OMAP5430 ES1.0 silicon. Signed-off-by: R Sricharan <r.sricharan@ti.com>
* OMAP4460: TPS Ensure SET1 is selected after voltage configurationNishanth Menon2012-05-15-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | TPS SET0/SET1 register is selected by a GPIO pin on OMAP4460 platforms. Currently we control this pin with a mux configuration as part of boot sequence. Current configuration results in the following voltage waveform: |---------------| (SET1 default 1.4V) | --------(programmed voltage) | <- (This switch happens on mux7,pullup) vdd_mpu(TPS) -----/ (OPP boot voltage) --------- (programmed voltage) vdd_core(TWL6030) -----------------------/ (OPP boot voltage) Problem 1) |<----- Tx ------>| timing violation for a duration Tx close to few milliseconds. Problem 2) voltage of MPU goes beyond spec for even the highest of MPU OPP. By using GPIO as recommended as standard procedure by TI, the sequence changes to: -------- (programmed voltage) vdd_mpu(TPS) ------------/ (Opp boot voltage) --------- (programmed voltage) vdd_core(TWL6030) -------------/ (OPP boot voltage) NOTE: This does not attempt to address OMAP5 - Aneesh please confirm Reported-by: Isabelle Gros <i-gros@ti.com> Reported-by: Jerome Angeloni <j-angeloni@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
* OMAP3+: Introduce generic logic for OMAP voltage controllerNishanth Menon2012-05-15-15/+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>
* ARM:OMAP+:MMC: Add parameters to MMC initJonathan Solnit2012-05-15-1/+1
| | | | | | | | | | Add parameters to the OMAP MMC initialization function so the board can mask host capabilities and set the maximum clock frequency. While the OMAP supports a certain set of MMC host capabilities, individual boards may be more restricted and the OMAP may need to be configured to match the board. The PRG_SDMMC1_SPEEDCTRL bit in the OMAP3 is an example. Signed-off-by: Jonathan Solnit <jsolnit@gmail.com>
* omap_hsmmc: Wait for CMDI to be clearTom Rini2012-02-15-1/+1
| | | | | | | | | | | | | | | | | Before we can send a command we need both the DATI (command inhibit on mmc_dat line) bit and CMDI (command inhibit on mmc_cmd line) are clear. The previous behavior of only checking on DATI was insufficient on some cards and incorrect behavior in any case. This makes the code check for both bits being clear and makes the error print more clear as to what happened. DATI_CMDDIS is removed as it was unused elsewhere in the code and stood for 'DATI is set, cmds are disabled still'. Fix originally spotted by Peter Bigot. Tested-by: Peter A. Bigot <bigotp@acm.org> Tested-by: Robert Nelson <robertcnelson@gmail.com> Signed-off-by: Tom Rini <trini@ti.com> Tested-by: Andreas Müller <schnitzeltony@googlemail.com>
* omap_rev_string: output to stdoutAndreas Müller2012-01-16-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>
* arch/arm/include/asm/arch-omap5/clocks.h: Fix GCC 4.2 warningsAnatolij Gustschin2011-12-06-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Fix: clocks.c: In function 'setup_post_dividers': clocks.c:175: warning: comparison is always true due to limited range of data type clocks.c:177: warning: comparison is always true due to limited range of data type clocks.c:179: warning: comparison is always true due to limited range of data type clocks.c:181: warning: comparison is always true due to limited range of data type clocks.c:183: warning: comparison is always true due to limited range of data type clocks.c:185: warning: comparison is always true due to limited range of data type clocks.c:187: warning: comparison is always true due to limited range of data type clocks.c:189: warning: comparison is always true due to limited range of data type Signed-off-by: Anatolij Gustschin <agust@denx.de> Cc: sricharan <r.sricharan@ti.com> Cc: Tom Rini <trini@ti.com>
* omap4/5: Add support for booting with CH.Sricharan2011-11-15-8/+27
| | | | | | | | | | | | | | | | 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-15-2/+722
| | | | | | | | | | | | 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-0/+1145
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>