| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
V2 fixes line wrap issue of the patch itself.
UART3 was enabled twice instead of UART4.
One more cosmetic change in a comment on EMIF clock.
Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
Reviewed-by: R Sricharan <r.sricharan@ti.com>
|
|
A new DPLL DDR is added in DRA7XX socs. Now clocks to
EMIF CD is from DPLL DDR. So DPLL DDR should be locked
before initializing RAM.
Also adding other dpll data which are different from OMAP5 ES2.0.
SYS_CLK running at 20MHz is introduced in DRA7xx socs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
Change OPP settings as per the latest 0.5 version of
addendum for OMAP5430 ES2.0. omap4/hw_data.c is touched
here to add dummy dividers.
While here correcting OPP_NOM mpu, core frequency for
OMAP4430 ES2.x
Note that OMAP5430 ES1.0 support is still kept alive and
would be removed in a cleanup later.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Cc: Tom Rini <trini@ti.com>
Cc: Nishanth Menon <nm@ti.com>
|
|
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
Currently there is quite a lot of code which
is duplicated in the clocks code for OMAP 4 and 5
Socs. Avoiding this here by moving the clocks
data to a SOC specific place and the sharing the
common code.
This helps in addition of a new Soc with minimal
changes.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
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>
|
|
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
unnessecary cpu checks for new boards
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
|
|
No need to Unlock DPLL initially.
DDR3 can work at normal OPP from initialozation
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
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>
|
|
The OMAP5 silicon has new DDR PHY design, which includes a external PHY
as well. So configuring the ext PHY parameters here. Also the EMIF timimg
registers and a couple of DDR mode registers needs to be updated based on
the testing from the actual silicon.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
|
|
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>
|
|
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>
|
|
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>
|
|
Fix:
clocks-common.c: In function 'setup_non_essential_dplls':
clocks-common.c:323:6: warning: variable 'sys_clk_khz' set but not used
[-Wunused-but-set-variable]
clocks-common.c: In function 'setup_non_essential_dplls':
clocks-common.c:323:6: warning: variable 'sys_clk_khz' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Tom Rini <trini@ti.com>
|
|
usb dpll configuration is done only part of non-essential
dppl configuration however if CONFIG_USB_EHCI_OMAP is defined
we may have to configure usb dpll's for proper functioning
of usb modules. So move the usb dppl configuration to a new func.
and utilise the same during essential dpll configuration.
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Tested-by: Stefano Babic <sbabic@denx.de>
|
|
Fix:
clocks-common.c: In function 'setup_dplls':
clocks-common.c:256:6: warning: variable 'sysclk_ind' set but not used
[-Wunused-but-set-variable]
clocks-common.c: In function 'setup_non_essential_dplls':
clocks-common.c:292:6: warning: variable 'sysclk_ind' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: sricharan <r.sricharan@ti.com>
Cc: Tom Rini <trini@ti.com>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Acked-by: Tom Rini <trini@ti.com>
|
|
TPS power IC is controlled using a GPIO (gpio_wk7).
This GPIO should be maintained at logic 1 always. As
such an internal pull-up on this pin will do the job,
driving the GPIO outuput is not needed. This will avoid
the need of using GPIO library in SPL and also may
save some power.
Signed-off-by: Aneesh V <aneesh@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>
|
|
Much of omap4 soc support code can be reused for omap5.
Move them to the omap-common directory to facilitate
this.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
|
