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>
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>
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>
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>
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>
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>
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>
