summaryrefslogtreecommitdiff
path: root/arch/arm/include/asm/arch-omap5
AgeCommit message (Collapse)Author
2018-04-27Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTRTom Rini
We have a large number of places where while we historically referenced gd in the code we no longer do, as well as cases where the code added that line "just in case" during development and never dropped it. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-02-19ARM: OMAP5: set mmc clock frequency to 192MHzKishon Vijay Abraham I
Now that omap_hsmmc has support for hs200 mode, change the clock frequency to 192MHz. Also change the REFERENCE CLOCK frequency to 192MHz based on which the internal mmc clock divider is calculated. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
2018-02-19mmc: omap_hsmmc: Add support to get pinctrl values and max frequency for ↵Kishon Vijay Abraham I
different hw revisions AM572x SR1.1 requires different IODelay values to be used than that used in AM572x SR2.0. These values are populated in device tree. Add capability in omap_hsmmc driver to extract IOdelay values for different silicon revision. The maximum frequency is also reduced when using a ES1.1. To keep the ability to boot both revsions with the same dtb, those values can be provided by the platform code. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
2018-02-19ARM: OMAP5/DRA7: Enable iodelay recalibration to be done from ubootKishon Vijay Abraham I
Add a new API to perform iodelay recalibration without isolate io to be used in uboot. The data manual of J6/J6 Eco recommends to set different IODELAY values depending on the mode in which the MMC/SD is enumerated in order to ensure IO timings are met. The MMC driver can use the new API to set the IO delay values depending on the MMC mode. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
2018-01-19arm: dra762: Add support for device package identificationLokesh Vutla
DRA762 comes in two packages: - ABZ: Pin compatible package with DRA742 with DDR@1333MHz - ACD: High performance(OPP_PLUS) package with new IPs Both the above packages uses the same IDCODE hence needs to differentiate using package information in DIE_ID_2. Add support for the same. Also update clock, ddr, emif information. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-01-19board: ti: dra7xx: Select MCAN instead of DCAN on DRA76 EVMVignesh R
MCAN can be accessed via DCAN1 or DCAN2. Determining which DCAN instance to use if any at all is done through CTRL_CORE_CONTROL_SPARE_RW.SEL_ALT_MCAN. Since general pinmuxing is handled in U-boot. Handle this additional pinmuxing requirement in U-boot to ensure that MCAN is used by default via the DCAN1 pins. Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com> [fcooper@ti.com: Update commit message and use DCAN1 not DCAN2 for MCAN] Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
2018-01-18omap: Update the base address of the MMC controllersJean-Jacques Hiblot
Align the base address defined in header files with the base address used in the DTS. This will facilitate the introduction of the DMA support. Of all HSMMC users, only omap3 doesn't have the 0x100 reserved region at the top. This region will be used to determine if the controller supports DMA transfers Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-09-14ARM: DRA7: Cleanup old pinctrl macrosSuman Anna
Commit 6ae4c3efbd62 ("ARM: DRA7: Add pinctrl register definitions") has added new macros for pinmux configuration in line with the kernel definitions. Cleanup the old pinctrl macros from the common header file so that they are not used by any new boards. Signed-off-by: Suman Anna <s-anna@ti.com>
2017-09-12ARM: DRA72x: Add support for detection of DRA71x SR 2.1Vishal Mahaveer
DRA71x processors are reduced pin and software compatible derivative of DRA72 processors. Add support for detection of SR2.1 version of DRA71x family of processors. Signed-off-by: Vishal Mahaveer <vishalm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-09-11board: ti: dra76-evm: Add the pmic dataKeerthy
dra76-evm uses lp8736 and tps65917 pmic for powering on various peripherals. Add data for these pmics and register for dra76-evm. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-09-11arm: dra76: Add support for ES1.0 detectionPraneeth Bajjuri
dra76 family is a high-performance, infotainment application device, based on OMAP architecture on a 28-nm technology. This contains most of the subsystems, peripherals that are available on dra74, dra72 family. This SoC mainly features Subsystems: - 2 x Cortex-A15 with max speed of 1.8GHz - 2 X DSP - 2 X Cortex-M4 IPU - ISS - CAL - DSS - VPE - VIP Connectivity peripherals: - 1 USB3.0 and 3 USB2.0 subsystems - 1 x SATA - 2 x PCI Express Gen2 - 3-port Gigabit ethernet switch - 2 x CAN - MCAN Adding CPU detection support for the dra76 ES1.0 soc and update prcm, control module, dplls data. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Praneeth Bajjuri <praneeth@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-09-01Convert CONFIG_SYS_I2C_BUS_MAX to KconfigAdam Ford
This converts the following to Kconfig: CONFIG_SYS_I2C_BUS_MAX Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de> [trini: Fix AM43XX drop AM44XX] Signed-off-by: Tom Rini <trini@konsulko.com>
2017-09-01Configs: Migrate I2C_BUS_MAX to CONFIG_SYS_I2C_BUS_MAXAdam Ford
For consistency with other platforms and in preparation of Kconfig migration, let's change Several TI platforms that use I2C_BUS_MAX to CONFIG_SYS_I2C_BUS_MAX Signed-off-by: Adam Ford <aford173@gmail.com>
2017-08-13ARM: OMAP5: Enable support for AVS0 for OMAP5 production devicesNishanth Menon
OMAP5432 did go into production with AVS class0 registers which were mutually exclusive from AVS Class 1.5 registers. Most OMAP5-uEVM boards use the pre-production Class1.5 which has production efuse registers set to 0. However on production devices, these are set to valid data. scale_vcore logic is already smart enough to detect this and use the "Nominal voltage" on devices that do not have efuse registers populated. On a test production device populated as follows: MPU OPP_NOM: => md.l 0x04A0021C4 1 4a0021c4: 03a003e9 .... (0x3e9 = 1.01v) vs nom voltage of 1.06v MPU OPP_HIGH: => md.l 0x04A0021C8 1 4a0021c8: 03400485 ..@. MM OPP_NOM: => md.l 0x04A0021A4 1 4a0021a4: 038003d4 .... (0x3d4 = 980mV) vs nom voltage of 1.025v MM OPP_OD: => md.l 0x04A0021A8 1 4a0021a8: 03600403 ..`. CORE OPP_NOM: => md.l 0x04A0021D8 1 4a0021d8: 000003cf .... (0x3cf = 975mV) vs nom voltage of 1.040v Since the efuse values are'nt currently used, we do not regress on existing pre-production samples (they continue to use nominal voltage). But on boards that do have production samples populated, we can leverage the optimal voltages necessary for proper operation. Tested on: a) 720-2644-001 OMAP5UEVM with production sample. b) 750-2628-222(A) UEVM5432G-02 with pre-production sample. Data based on OMAP5432 Technical reference Manual SWPU282AF (May 2012-Revised Aug 2016) NOTE: All collaterals on OMAP5432 silicon itself seems to have been removed from ti.com, though EVM details are still available: http://www.ti.com/tool/OMAP5432-EVM Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-08-13ARM: OMAP5: Remove OPP_LOW Definitions for ES2.0Nishanth Menon
ES2.0 descopes OPP_LOW definition. So remove it from macros defined. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-06-09arm: omap: Unify get_device_type() functionSemen Protsenko
Refactor OMAP3/4/5 code so that we have only one get_device_type() function for all platforms. Details: - Add ctrl variable for AM33xx and OMAP3 platforms (like it's done for OMAP4/5), so we can obtain status register in common way - For now ctrl structure for AM33xx/OMAP3 contains only status register address - Run hw_data_init() in order to assign ctrl to proper structure - Remove DEVICE_MASK and DEVICE_GP definitions as they are not used (DEVICE_TYPE_MASK and GP_DEVICE are used instead) - Guard structs in omap_common.h with #ifdefs, because otherwise including omap_common.h on non-omap4/5 board files breaks compilation Buildman script was run for all OMAP boards. Result output: arm: (for 38/616 boards) all +352.5 bss -1.4 data +3.5 rodata +300.0 spl/u-boot-spl:all +284.7 spl/u-boot-spl:data +2.2 spl/u-boot-spl:rodata +252.0 spl/u-boot-spl:text +30.5 text +50.4 (no errors to report) Tested on AM57x EVM and BeagleBoard xM. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> [trini: Rework the guards as to not break TI81xx] Signed-off-by: Tom Rini <trini@konsulko.com>
2017-05-15omap5: Migrate CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC to KconfigTom Rini
While in theory this value could be used in places outside of "omap5" (such as OMAP4), we only make use of it today in OMAP5, so place the Kconfig entry there. Given that Kconfig lets us provide a default, we drop CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC entirely. The contents of doc/README.omap-reset-time make a good help entry, so adjust them slightly and delete the file. Move the comment about range to where we use the value now, and have Kconfig enforce the upper bound. Signed-off-by: Tom Rini <trini@konsulko.com>
2017-04-08ti: wdt: omap5: Define WDT_BASE for omap5+ SoCLukasz Majewski
Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-04-08ti: wdt: common: Make the wdt IP defines common for the TI platformLukasz Majewski
Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-20ARM: OMAP5+: GPIO: Add GPIO_TO_PIN() macroRoger Quadros
GPIO_TO_PIN(bank, bank_gpio) returns the GPIO index from the GPIO bank number and bank's GPIO offset number. Signed-off-by: Roger Quadros <rogerq@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-02-17ARM: DRA7xx: Fix memory allocation overflowAndrew F. Davis
When using early malloc the allocated memory can overflow into the SRAM scratch space, move NON_SECURE_SRAM_IMG_END down a bit to allow more dynamic allocation at the expense of a slightly smaller maximum image size. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-12-04board: ti: am572x: Add pinmux for X15/GPEVM SR2.0 using latest PMTNishanth Menon
Update the board pinmux for AM572x-IDK board using latest PMT[1] and the board files named am572x_gp_evm_A3a_sr2p0 that were autogenerated on 19th October, 2016 by "Ahmad Rashed<a-rashed@ti.com>". [1] https://dev.ti.com/pinmux/app.html#/default/ Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-12-04board: ti: dra71x-evm: Add PMIC supportKeerthy
Add the pmic_data for LP873x PMIC which is used to power up dra71x-evm. Note: As per the DM[1] DRA71x supports only OP_NOM. So, updating the efuse registers only to use OPP_NOM irrespective of any CONFIG_DRA7_<VOLT>_OPP_{NOM,od,high} is defined. [1] http://www.ti.com/product/DRA718/technicaldocuments Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-12-04ARM: DRA7: Redefine voltage and efuse macros per OPP using KconfigSuman Anna
Redefine the macros used to define the voltage values and the efuse register offsets based on OPP for all the voltage domains. This is done using Kconfig macros that can be set in a defconfig or selected during a config step. This allows a voltage domain to be configured/set to a corresponding voltage value depending on the OPP selection choice. The Kconfig choices have been added for MPU, DSPEVE, IVA and GPU voltage domains, with the MPU domain restricted to OPP_NOM. The OPP_OD and OPP_HIGH options will be added when the support for configuring the MPU clock frequency is added. The clock configuration for other voltage domains is out of scope in u-boot code. The CORE voltage domain does not have separate voltage values and efuse register offset at different OPPs, while the MPU voltage domain only has different efuse register offsets for different OPPs, but uses the same voltage value. Any different choices of OPPs for voltage domains on common ganged-rails is automatically taken care to select the corresponding highest OPP voltage value. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-12-03ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XXNishanth Menon
CONFIG_AM57XX is just an unnecessary macro that is redundant given So, remove the same instead of spreading through out the u-boot source code and getting in the way to maintain common code for DRA7x family. Acked-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-09-27dra7x: boot: add dfu bootmode supportB, Ravi
This patch enables the DFU boot mode support for dra7x platform. Signed-off-by: Ravi Babu <ravibabu@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-09-06TI: Rework SRAM definitions and maximumsTom Rini
On all TI platforms the ROM defines a "downloaded image" area at or near the start of SRAM which is followed by a reserved area. As it is at best bad form and at worst possibly harmful in corner cases to write in this reserved area, we stop doing that by adding in the define NON_SECURE_SRAM_IMG_END to say where the end of the downloaded image area is and make SRAM_SCRATCH_SPACE_ADDR be one kilobyte before this. At current we define the end of scratch space at 0x228 bytes past the start of scratch space this this gives us a lot of room to grow. As these scratch uses are non-optional today, all targets are modified to respect this boundary. Tested on OMAP4 Pandaboard, OMAP3 Beagle xM Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Nagendra T S <nagendra@mistralsolutions.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Igor Grinberg <grinberg@compulab.co.il> Cc: Nikita Kiryanov <nikita@compulab.co.il> Cc: Paul Kocialkowski <contact@paulk.fr> Cc: Enric Balletbo i Serra <eballetbo@gmail.com> Cc: Adam Ford <aford173@gmail.com> Cc: Steve Sakoman <sakoman@gmail.com> Cc: Stefan Roese <sr@denx.de> Cc: Thomas Weber <weber@corscience.de> Cc: Hannes Schmelzer <oe5hpm@oevsv.at> Cc: Thomas Chou <thomas@wytron.com.tw> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Simon Glass <sjg@chromium.org> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Heiko Schocher <hs@denx.de> Cc: Samuel Egli <samuel.egli@siemens.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> Cc: Ben Whitten <ben.whitten@gmail.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Mugunthan V N <mugunthanvnm@ti.com> Cc: "B, Ravi" <ravibabu@ti.com> Cc: "Matwey V. Kornilov" <matwey.kornilov@gmail.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Ash Charles <ashcharles@gmail.com> Cc: "Kipisz, Steven" <s-kipisz2@ti.com> Cc: Daniel Allred <d-allred@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Tested-by: Lokesh Vutla <lokeshvutla@ti.com> Acked-by: Lokesh Vutla <lokeshvutla@ti.com> Tested-by: Ladislav Michl <ladis@linux-mips.org>
2016-07-26omap5/dra7: i2c: correct register offset for sync registerMugunthan V N
The register offset of i2c_sysc offset is not correct as per omap5[1]/dra7[2] TRM, correct the offsets as per the documentation. [1] - http://www.ti.com/lit/pdf/swpu249 [2] - http://www.ti.com/lit/pdf/spruhz6 Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-06-02arm: omap: Introduce vcores_init functionKeerthy
The pmic registers for variants of am57xx boards are different hence we need to assign them carefully based on the board type. Add a function to assign omap_vcores after the board detection. Signed-off-by: Keerthy <j-keerthy@ti.com>
2016-06-02ARM: DRA7: Add macros for voltage values for all OPPsAnna, Suman
Define specific macros for the voltage values for all voltage domains for all applicable OPPs - OPP_NOM, OPP_OD and OPP_HIGH. No separate macros are defined for VD_MPU and VD_CORE at OPP_OD and OPP_HIGH as these use the same values as OPP_NOM. The current macros will be used as common macros that can be redefined appropriately based on a selected OPP configuration at build time. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-06-02ARM: DRA7: Consolidate voltage macros across different SoCsAnna, Suman
The voltage values for each voltage domain at an OPP is identical across all the SoCs in the DRA7 family. The current code defines one set of macros for DRA75x/DRA74x SoCs and another set for DRA72x macros. Consolidate both these sets into a single set. This is done so as to minimize the number of macros used when voltage values will be added for other OPPs as well. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-06-02ARM: DRA7: Define common macros for efuse register offsetsAnna, Suman
Define a set of common macros for the efuse register offsets (different for each OPP) that are used to get the AVS Class 0 voltage values and ABB configuration values. Assign these common macros to the register offsets for OPP_NOM by default for all voltage domains. These common macros can then be redefined properly to point to the OPP specific efuse register offset based on the desired OPP to program a specific voltage domain. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-06-02ARM: DRA7: Update/Correct MPU and CORE OPP_NOM voltage valuesAnna, Suman
The current OPP_NOM voltage values defined for the MPU and CORE voltage domains are based on the initial DRA75x_74x_SR1.1_DM data manual. As per this DM, the PMIC boot voltage can be set to either 1.10V or 1.15V for VD_MPU, and either 1.06V or 1.15V for VD_CORE. While the current values are correct, the latter set of values are the values that are common across all DRA75x, DRA72x SoCs and for all current Silicon revisions. So, update both the MPU and CORE OPP_NOM voltages to 1.15V. The macros are also slightly reorganized so that both the MPU and CORE voltage domain values are defined together. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2016-05-24ARM: omap5: add platform specific ethernet phy modes configurationsMugunthan V N
Add platforms specific phy mode configuration bits to be used to configure phy mode in control module. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2016-04-25ARM: DRA7: Add ABB setup for all domainsNishanth Menon
ABB should be initialized for all required domains voltage domain for DRA7: IVA, GPU, EVE in addition to the existing MPU domain. If we do not do this, kernel configuring just the frequency using the default boot loader configured voltage can fail on many corner lot units and has been hard to debug. This specifically is a concern with DRA7 generation of SoCs since other than VDD_MPU, all other domains are only permitted to setup the voltages to required OPP only at boot. Reported-by: Richard Woodruff <r-woodruff2@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
2016-04-25ARM: OMAP5: Enable ABB configuration for MM voltage domainNishanth Menon
Since we setup the voltage and frequency for the MM domain, we *must* setup the ABB configuration needed for the domain as well. If we do not do this, kernel configuring just the frequency using the default boot loader configured voltage can fail on many corner lot units. Reported-by: Richard Woodruff <r-woodruff2@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
2016-03-27ARM: OMAP5/DRA7: Expose do_set_iodelayNishanth Menon
do_set_iodelay can now be used from board files based on needs of the platforms variation they have. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-03-27ARM: OMAP5/DRA7: Split iodelay functionality into sub stepsNishanth Menon
Since many platforms may need different pad configuration required depending on variation of the platform with minor deltas, it is easier to maintain a sub step based approach to allow for pin mux and iodelay configuration which may depend on the platform variations and need to be done in IO isolation. While we retain the older __recalibrate_iodelay function which provides a ready sequencing, __recalibrate_iodelay_start and __recalibrate_iodelay_end may be alternatively used now and the callers will be responsible for the correct sequencing of operations. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-03-27ARM: DRA72x: Add support for detection of SR2.0Ravi Babu
Add support for detection of SR2.0 version of DRA72x family of processors. Signed-off-by: Ravi Babu <ravibabu@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-03-15omap-common: Rename set_muxconf_regs_essential to set_muxconf_regsPaul Kocialkowski
There is no distinction between essential and non-essential mux configuration, so it doesn't make sense to have an "essential" prefix. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
2016-03-14ARM: OMAP4/5: Add generic board detection hookKipisz, Steven
Many TI EVMs have capability to store relevant board information such as DDR description in EEPROM. Further many pad configuration variations can occur as part of revision changes in the platform. In-order to support these at runtime, we for a board detection hook which is available for override from board files that may desire to do so. NOTE: All TI EVMs are capable of detecting board information based on early clocks that are configured. However, in case of additional needs this can be achieved within the override logic from within the board file. Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-03-14ARM: OMAP4/5: Centralize gpi2c_initKipisz, Steven
Centralize gpi2c_init into omap_common from the sys_proto header so that the information can be reused across SoCs. Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-03-14ARM: OMAP4/5: Centralize early clock initializationKipisz, Steven
Early clock initialization is currently done in two stages for OMAP4/5 SoCs. The first stage is the initialization of console clocks and then we initialize basic clocks for functionality necessary for SoC initialization and basic board functionality. By splitting up prcm_init and centralizing this clock initialization, we setup the code for follow on patches that can do board specific initialization such as board detection which will depend on these basic clocks. As part of this change, since the early clock initialization is centralized, we no longer need to expose the console clock initialization. NOTE: we change the sequence slightly by initializing console clocks timer after the io settings are complete, but this is not expected to have any functioanlity impact since we setup the basic IO drive strength initialization as part of do_io_settings. Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-09-11bitops: introduce BIT() definitionHeiko Schocher
introduce BIT() definition, used in at91_udc gadget driver. Signed-off-by: Heiko Schocher <hs@denx.de> [remove all other occurrences of BIT(x) definition] Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com> Acked-by: Stefan Roese <sr@denx.de> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-08-28board: ti: OMAP5: added USB initializtion codeKishon Vijay Abraham I
Implemented board_usb_init(), board_usb_cleanup() and usb_gadget_handle_interrupts() in omap5 board file that can be invoked by various gadget drivers. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-08-28board: ti: beagle_x15: added USB initializtion codeKishon Vijay Abraham I
Implemented board_usb_init(), board_usb_cleanup() and usb_gadget_handle_interrupts() in beagle_x15 board file that can be invoked by various gadget drivers. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-08-28ARM: DRA7: Enable clocks for USB OTGSS2 and USB PHY2Kishon Vijay Abraham I
Enabled clocks for the second dwc3 controller and second USB PHY present in DRA7. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-08-28ARM: DRA74-evm: Use SMA_1 spare register to workaround DP83865 phy on SR2.0Nishanth Menon
DP83865 ethernet phy used on DRA74x-evm is quirky and the datasheet provided IODELAY values for standard RGMII phys do not work. Silicon Revision(SR) 2.0 provides an alternative bit configuration that allows us to do a "gross adjustment" to launch the data off a different internal clock edge. Manual IO Delay overrides are still necessary to fine tune the clock-to-data delays. This is a necessary workaround for the quirky ethernet Phy we have on the platform. NOTE: SMA registers are spare "kitchen sink" registers that does contain bits for other workaround as necessary as well. Hence the control for the same is introduced in a generic SoC specific, board generic location. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-08-28ARM: DRA7: Add detection of ES2.0Nishanth Menon
Add support for detection of ES2.0 version of DRA7 family of processors. ES2.0 is an incremental revision with various fixes including the following: - reset logic fixes - few assymetric aging logic fixes - MMC clock rate fixes - Ethernet speed fixes - edma fixes for mcasp [ravibabu@ti.com: posted internal for an older bootloader] Signed-off-by: Ravi Babu <ravibabu@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-08-17ARM: dra7xx_evm: Enable EDMA3 in SPL to support DMA on qspiVignesh R
Enable TI_EDMA3 and SPL_DMA support, so as to reduce boot time. With DMA enabled there is almost 3x improvement in read performance. This helps in reducing boot time in qspiboot mode Also add EDMA3 base address for DRA7XX and AM57XX. Signed-off-by: Vignesh R <vigneshr@ti.com> Reviewed-by: Jagan Teki <jteki@openedev.com>