14 Dec, 2011
1 commit
-
This patch updates existing macros, functions used for TI816X, to enable
addition of other SoCs belonging to TI81XX family (e.g., TI814X).The approach taken is to use TI81XX/ti81xx for code/data going to be common
across all TI81XX devices.cpu_is_ti81xx() is introduced to handle code common across TI81XX devices.
In addition, ti8168_evm_map_io() is now replaced with ti81xx_map_io() and moved
in mach-omap2/common.c as same will be used for TI814X and is not board
specific.Signed-off-by: Hemant Pedanekar
Signed-off-by: Tony Lindgren
24 Jun, 2011
1 commit
-
Upon return from off-mode, the ROM code jumps to a restore function
saved in the scratchpad. Based on SoC revision or errata, this
restore entry point is different. Current code uses some helper
functions in sleep34xx.S (get_*_restore_pointer) to get the restore
function entry point.When returning from off-mode, this code is executed from SDRAM, so
there's no reason to use these helper functions when using the SDRAM
entry points directly would work just fine.This patch uses ENTRY/ENDPROC to create "real" entry points for these
functions, and uses those values directly when writing the scratchpad.Tested all three entry points
- restore_es3: 3430/n900
- restore_3630: 3630/Zoom3
- restore: 3530/OveroSuggested-by: Russell King
Acked-by: Jean Pihet
Acked-by: Santosh Shilimkar
Signed-off-by: Kevin Hilman
Signed-off-by: Russell King
10 May, 2011
1 commit
-
- kenrel -> kernel
- whetehr -> whether
- ttt -> tt
- sss -> ssSigned-off-by: Justin P. Mattock
Signed-off-by: Jiri Kosina
17 Feb, 2011
1 commit
-
This patch updates the common machine specific source files with support for
TI816X.Signed-off-by: Hemant Pedanekar
Reviewed-by: Kevin Hilman
Signed-off-by: Tony Lindgren
23 Dec, 2010
5 commits
-
…/linux-omap-pm into omap-for-linus
-
OMAP4 has three scalable voltage domains vdd_mpu, vdd_iva
and vdd_core. This patch adds the voltage tables and other
configurable voltage processor and voltage controller
settings to control these three scalable domains in OMAP4.Signed-off-by: Thara Gopinath
Signed-off-by: Kevin Hilman -
This patch adds voltage driver support for OMAP3. The driver
allows configuring the voltage controller and voltage
processors during init and exports APIs to enable/disable
voltage processors, scale voltage and reset voltage.
The driver maintains the global voltage table on a per
VDD basis which contains the various voltages supported by the
VDD along with per voltage dependent data like smartreflex
efuse offset, errminlimit and voltage processor errorgain.
The driver also allows the voltage parameters dependent on the
PMIC to be passed from the PMIC file through an API.
The driver allows scaling of VDD voltages either through
"vc bypass method" or through "vp forceupdate method" the
choice being configurable through the board file.This patch contains code originally in linux omap pm branch
smartreflex driver. Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman. The separation of PMIC parameters
into a separate structure which can be populated from
the PMIC file is based on the work of Lun Chang from Motorola
in an internal tree.Signed-off-by: Thara Gopinath
[khilman: fixed link error for OMAP2-only defconfig]
Signed-off-by: Kevin Hilman -
OMAP3_IVA_MASK should use OMAP3_IVA_SHIFT instead of OMAP3_SGX_SHIFT
Signed-off-by: Arno Steffen
Signed-off-by: Tony Lindgren
22 Dec, 2010
4 commits
-
Move the padconf save code from pm34xx.c to the System Control Module
code in mach-omap2/control.c. This is part of the general push to
move direct register access from middle-layer core code to low-level
core code, so the middle-layer code can be abstracted to work on
multiple platforms and cleaned up.In the medium-to-long term, this code should be called by the mux
layer code, not the PM idle code. This is because, according to the
TRM, saving the padconf only needs to be done when the padconf
changes[1].Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
Tested-by: Rajendra Nayak
Tested-by: Santosh Shilimkar1. OMAP34xx Multimedia Device Silicon Revision 3.1.x [Rev. ZH] [SWPU222H]
Section 4.11.4 "Device Off-Mode Sequences" -
Get rid of the open-coded scratchpad write in mach-omap2/prcm.c and
replace it with an actual API, omap3_ctrl_write_boot_mode(). While
there, get rid of the gratuitous omap_writel().There's not much documentation available for what should wind up in
the scratchpad here, so more documentation would be appreciated.
Also, at some point, we should formalize our treatment of the scratchpad;
right now, accesses to the scratchpad are not well-documented.Signed-off-by: Paul Walmsley
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
Tested-by: Santosh Shilimkar -
Using macros from existing include files for registers addresses.
Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.Based on original patch from Vishwa.
Signed-off-by: Jean Pihet
Cc: Vishwanath BS
Acked-by: Santosh Shilimkar
Tested-by: Nishanth Menon
Signed-off-by: Kevin Hilman -
Erratum id: i608
RTA (Retention Till Access) feature is not supported and leads to device
stability issues when enabled. This impacts modules with embedded memories
on OMAP3630Workaround is to disable RTA on boot and coming out of core off.
For disabling RTA coming out of off mode, we do this by overriding the
restore pointer for 3630 as the first point of entry before caches are
touched and is common for GP and HS devices. To disable earlier than
this could be possible by modifying the PPA for HS devices, but not for
GP devices.Cc: Kevin Hilman
Cc: Tony LindgrenAcked-by: Jean Pihet
Acked-by: Santosh Shilimkar[ambresh@ti.com: co-developer]
Signed-off-by: Ambresh K
Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
09 Oct, 2010
1 commit
-
Only OMAP2+ platforms have the System Control Module (SCM) IP block.
In the past, we've kept the SCM header file in plat-omap. This has
led to abuse - device drivers including it; includes being added that
create implicit dependencies on OMAP2+ builds; etc.In response, move the SCM headers into mach-omap2/.
As part of this, remove the direct SCM access from the OMAP UDC
driver. It was clearly broken. The UDC code needs an indepth review for
use on OMAP2+ chips.Signed-off-by: Paul Walmsley
Cc: Cory Maccarrone
Cc: Kyungmin Park