summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/control.c
Commit message (Collapse)AuthorAgeFilesLines
* ARM: OMAP2+: Fix out of range register access with syscon_config.max_registerTony Lindgren2016-02-221-19/+2
| | | | | | | | | | | | | | | | If syscon_config.max_register is initialized like it should be, we have omap_ctrl_read/write() fail with out of range register access at least for omap3. We have omap3.dtsi setting up a regmap range for scm_conf, but we now have omap_ctrl_read/write() also attempt to use the regmap. However, omap_ctrl_read/write() is also used for other register ranges in the system control module (SCM). Let's fix the issue by just removing the regmap_read/write() usage for control module as suggested by Tero Kristo <t-kristo@ti.com>. Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: Fix scm compatible for dm814xTony Lindgren2015-07-161-0/+1
| | | | | | | Fix scm compatible for dm814x. Cc: Matthijs van Duin <matthijsvanduin@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP3: Add support for configuring MMC pins as GPIO pinsTony Lindgren2015-05-201-0/+3
| | | | | | | | | | | | | Some devices are using the MMC1 pins 4..8 as GPIO pins, and in this case they need to be configured for 1.8V IO voltage if not done by the bootloader as otherwise some devices like smsc911x won't work properly. Let's also make sure this register is saved and restored for idle. Cc: Tim Nordell <tim.nordell@logicpd.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP4+: control: add support for initializing control module via DTTero Kristo2015-03-311-0/+3
| | | | | | | | OMAP4, OMAP5 and DRA7 now parse DT entries for control module address spaces, and set up syscon mappings appropriately. Low level IO init is updated to remove the legacy control module mappings for these devices also. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP4+: control: remove support for legacy pad read/writeTero Kristo2015-03-311-23/+1
| | | | | | | | omap4_ctrl_pad_readl/writel are no longer used by anybody, so remove these. Syscon / pinctrl should be used to access the padconf area instead. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: dts: am4372: add minimal l4 bus layout with control module supportTero Kristo2015-03-311-1/+1
| | | | | | | | | This patch creates an l4_wkup interconnect for AM43xx, and moves some of the generic peripherals under it. System control module nodes are moved under this new interconnect also, and the SCM clock layout is changed to use the renamed SCM nodea as the clock provider. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: dts: am33xx: add minimal l4 bus layout with control module supportTero Kristo2015-03-311-1/+1
| | | | | | | | | This patch creates an l4_wkup interconnect for AM33xx, and moves some of the generic peripherals under it. System control module nodes are moved under this new interconnect also, and the SCM clock layout is changed to use the renamed SCM node as the clock provider. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: dts: omap3: add minimal l4 bus layout with control module supportTero Kristo2015-03-311-1/+1
| | | | | | | | | | This patch creates an l4_core interconnect for OMAP3, and moves some of the generic peripherals under it. System control module nodes are moved under this new interconnect also, and the SCM clock layout is changed to use the renamed SCM node as the clock provider. Signed-off-by: Tero Kristo <t-kristo@ti.com> Reported-by: Tony Lindgren <tony@atomide.com>
* ARM: dts: omap24xx: add minimal l4 bus layout with control module supportTero Kristo2015-03-311-1/+6
| | | | | | | | | This patch creates an l4 / l4-wkup interconnects for omap2420 / omap2430 SoCs, and moves some of the generic peripherals under it. System control module nodes are moved under this new interconnect also, and the SCM clock layout is changed to use the new SCM node as the clock provider. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP2+: control: add syscon support for register accessesTero Kristo2015-03-311-17/+87
| | | | | | | | | | | Control module driver needs to support syscon for register accesses, as the DT hierarchy for control module driver is going to be changed. All the control module related features will be moved under control module node, including clocks, pinctrl, and generic configuration register access. Temporary iomap is still provided very early in the boot for access while syscon is not yet ready. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP2+: control: remove API for getting control module base addressTero Kristo2015-03-311-5/+0
| | | | | | | This shall not be used anymore, as control module driver is converted into using regmap. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP2+: clock: add low-level support for regmapTero Kristo2015-03-311-1/+1
| | | | | | | | | Some of the TI clock providers will be converted to use syscon, thus low-level regmap support is needed for the clock drivers also. This patch adds this support, which can be enabled for individual drivers in later patches. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP2+: control: determine control module base address from DTTero Kristo2015-03-271-6/+43
| | | | | | | | | | There is no need to provide the control module base address through a low-level API from the low-level IO init, as this information is available through DT. This patch adds a new API to initialize the control module though, but mostly makes the old API obsolete. The old API can be completely removed once OMAP3 is made DT only. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP2+: PRCM: split PRCM module init to their own driver filesTero Kristo2015-03-271-0/+47
| | | | | | | Splits the clock related provider module inits under their own driver files. Previously this was done for all modules under the common PRM driver. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP3: Fix coding style problems in arch/arm/mach-omap2/control.cJeremy Vial2014-08-011-2/+1
| | | | | | | Fix coding style problems in arch/arm/mach-omap2/control.c. Signed-off-by: Jeremy Vial <jvial@adeneo-embedded.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP3: Fix choice of omap3_restore_es function in OMAP34XX rev3.1.2 case.Jeremy Vial2014-08-011-1/+2
| | | | | | | | | | According to the comment “restore_es3: applies to 34xx >= ES3.0" in "arch/arm/mach-omap2/sleep34xx.S”, omap3_restore_es3 should be used if the revision of an OMAP34xx is ES3.1.2. Signed-off-by: Jeremy Vial <jvial@adeneo-embedded.com> Cc: stable@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP3: control: isolate control module init to its own functionTero Kristo2014-07-041-2/+17
| | | | | | | Control module related PM initializations are now moved within control module driver. Done in preparation to isolate the code to its own driver. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP3: control: add API for setting up the modem padsTero Kristo2014-07-041-0/+26
| | | | | | This patch moves the functionality from PM core to control driver. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP3: PRM: add API for saving PRM scratchpad contentsTero Kristo2014-07-041-9/+2
| | | | | | This isolates the PRM register access within the PRM driver. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP3: PRM: add API for checking and clearing cold reset statusTero Kristo2014-07-041-5/+1
| | | | | | This isolates the PRM register access within the PRM driver. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP2+: raw read and write endian fixVictor Kamensky2014-05-081-10/+10
| | | | | | | | | | | | | | | | All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP3: control: add API for setting IVA bootmodeTero Kristo2013-10-191-0/+11
| | | | | | | | | OMAP3 PM core requires IVA2 bootmode to be set to idle during init. Currently, a direct register write is used for this. Add a new ctrl API for this purpose instead. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP3: CM/control: move CM scratchpad save to CM driverTero Kristo2013-10-191-39/+4
| | | | | | | | | | | OMAP3 PM code for off-mode currently saves the scratchpad contents for CM registers within OMAP control module driver. However, as we are separating CM code into its own driver, this must be moved also. This patch adds a new API for saving the CM scratchpad contents and uses this from the high level scratchpad save function. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP2+: control: add OMAP5 support for dsp boot programmingSuman Anna2013-05-161-0/+1
| | | | | | | | Support for OMAP5 is added to the omap_dsp_ctrl_write_boot_addr() to enable the DSP boot. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: common: remove mach-omap2/common.c globals and map_common_io codePaul Walmsley2012-11-081-6/+4
| | | | | | | | | | Get rid of the mach-omap2/common.c globals by moving the global initialization for IP block addresses that must occur early into mach-omap2/io.c. In the process, remove the *_map_common_io*() and SoC-specific *set_globals* functions. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
* Merge tag 'omap-cleanup-a-for-3.8' of ↵Tony Lindgren2012-10-241-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-prcm The first set of OMAP PRM/CM-related cleanup patches for 3.8. Prepares for the future move of the PRM/CM code to drivers/. Also includes some prcm.[ch] cleanup patches from the WDTIMER cleanup series that don't need external acks. Basic test logs for this branch on top of v3.7-rc2 are here: http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121021123719/ But due to the number of unrelated regressions present in v3.7-rc[12], it's not particularly usable as a testing base. With reverts, fixes, and workarounds applied as documented in: http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/README.txt the following test logs were obtained: http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121020231757/ which indicate that the series tests cleanly. Conflicts: arch/arm/mach-omap2/Makefile arch/arm/mach-omap2/clockdomain2xxx_3xxx.c arch/arm/mach-omap2/pm24xx.c
| * ARM: OMAP2+: CM/hwmod: split CM functions into OMAP2, OMAP3-specific filesPaul Walmsley2012-10-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move OMAP3xxx-specific CM functions & macros into cm3xxx.[ch] and OMAP2xxx-specific macros into cm2xxx.[ch]. Move basic CM register access functions into static inline functions in cm2xxx_3xxx.h, leaving only OMAP2/3 hardreset functions in cm2xxx_3xxx.c. As part of this, split the CM and hwmod code that waits for devices to become ready into SoC-specific functions. This is in preparation for the upcoming move of this code to drivers/. Signed-off-by: Paul Walmsley <paul@pwsan.com> Reviewed-by: Russ Dill <Russ.Dill@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
| * ARM: OMAP2+: PRM: split PRM functions into OMAP2, OMAP3-specific filesPaul Walmsley2012-10-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move OMAP3xxx-specific PRM functions & macros into prm3xxx.[ch] and OMAP2xxx-specific macros into prm2xxx.h. (prm2xxx.c will be created by a subsequent patch when it's needed.) Move basic PRM register access functions into static inline functions in prm2xxx_3xxx.h, leaving only OMAP2/3 hardreset functions in prm2xxx_3xxx.c. Also clarify the initcall function naming to reinforce that this code is specifically for the PRM IP block. This is in preparation for the upcoming powerdomain series and the upcoming move of this code to drivers/. Signed-off-by: Paul Walmsley <paul@pwsan.com> Reviewed-by: Russ Dill <Russ.Dill@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* | ARM: OMAP: move plat-omap/include/plat/sdrc.h into mach-omap2/sdrc.hPaul Walmsley2012-10-171-3/+1
|/ | | | | | | | | | | Remove arch/arm/plat-omap/include/plat/sdrc.h by folding its contents into arch/arm/mach-omap2/sdrc.h. The objective is to assist Tony in cleaning out arch/arm/plat-omap/, as his upstreams request. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> [tony@atomide.com: updated to remove rotate macros] Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+Tony Lindgren2012-09-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the plat and mach includes need to disappear for single zImage work, we need to remove plat/hardware.h. Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. The old plat/hardware.h already has omap1 only defines, so it gets moved to mach/hardware.h for omap1. For omap2+, we use the local soc.h that for now just includes the related SoC headers to keep this patch more readable. Note that the local soc.h still includes plat/cpu.h that can be dealt with in later patches. Let's also include plat/serial.h from common.h for all the board-*.c files. This allows making the include files local later on without patching these files again. Note that only minimal changes are done in this patch for the drivers/watchdog/omap_wdt.c driver to keep things compiling. Further patches are needed to eventually remove cpu_is_omap usage in the drivers. Also only minimal changes are done to sound/soc/omap/* to remove the unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's no need to include omap44xx.h. While at it, also sort some of the includes in the standard way. Cc: linux-watchdog@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Acked-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: control: new APIs to configure boot address and modeOmar Ramirez Luna2012-06-181-0/+43
| | | | | | | | | | | | | | | | | | | SCM contains boot addr and boot mode registers to control other processors on different OMAP versions. It controls the boot address and mode for DSP based subsystems like: IVA 2.1 (OMAP2430), IVA 2.2 (OMAP3) and DSP (OMAP4). If contained within SCM registers, when a processor is booting it uses BOOTADDR to start running the code at that location. BOOTMOD register specifies a different set of modes for the processor to execute when booting (from direct, idle, self-loop, user and default). Since there was no offset associated with OMAP4, this patch defines it. Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP2+: Fix build error after mergeTony Lindgren2012-03-071-0/+1
| | | | | | | | | | | | | | | | | | Commit 9890ce44 (ARM: get rid of asm/irq.h in asm/prom.h) removed include of asm/irq.h in asm/prom.h. This commit together with recent omap cleanup to remove io.h causes build breakage: arrch/arm/mach-omap2/control.c: In function 'omap3_ctrl_write_boot_mode': arch/arm/mach-omap2/control.c:238: error: 'OMAP343X_CTRL_BASE' undeclared (first use in this function) ... Fix this by including hardware.h directly where needed instead of relying on asm/irq.h in asm/prom.h. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: Move most of plat/io.h into local iomap.hTony Lindgren2012-02-241-1/+2
| | | | | | | | | | | | There's no need to have these defines in plat/io.h. Note that we now need to ifdef omap_read/write calls as they will be available for omap1 only. While at it, clean up the includes to group them like they typically are grouped. Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: 7159/1: OMAP: Introduce local common.h filesTony Lindgren2011-11-171-1/+1
| | | | | | | | | | | As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>, there's no need to keep local prototypes in non-local headers. Add mach-omap1/common.h and mach-omap2/common.h and move the local prototypes there from plat/common.h and mach/omap4-common.h. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: OMAP: Move set_globals initialization to happen in init_earlyTony Lindgren2011-10-191-10/+4
| | | | | | | | | | Otherwise we can't do generic map_io as we currently rely on static mappings that work only because of arch_ioremap. Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: pm: omap34xx: remove get_*_restore_pointer functions, directly use ↵Kevin Hilman2011-06-241-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | entry points 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/Overo Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Jean Pihet <j-pihet@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLLEduardo Valentin2011-04-201-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per OMAP3 erratum (i671), ROM code adds extra latencies while restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL is equal to 1. This patch stores 0's in scratchpad content area corresponding to AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per DPLL, since it won't respect proper programing scheme. This register is then stored in prcm context. The saving and restore is now done by kernel side. Here follow the erratum description DESCRIPTION After OFF mode transition, among many restorations, the ROM Code restores the CM_AUTOIDLE_PLL register, and after that, it tries to relock the PER DPLL. In case the restoration data stored in scratchpad memory contains a field CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM Code restores and locks the PER DPLL does not respect the PER DPLL programming scheme. In that case, the DPLL might not lock. Meanwhile, when trying to lock the PER DPLL, the ROM Code does not hang. Only extra latencies are introduced at wake-up. WORKAROUND When saving the context-restore structure in scratchpad memory, in order to respect the PER DPLL programming scheme, it is advised to store 0 in the CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL field of the saved structure. After wake-up, the application should store in CM_AUTOIDLE_PLL register the right desired value. Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP2+: PM: Fix the saving of CM_AUTOIDLE_PLL register on scratchpad areaEduardo Valentin2011-04-201-1/+1
| | | | | | | | | | | | The saving of CCR.CM_AUTOIDLE_PLL is done in scratchpad area. However, in current code, the saving is done for CM_AUTOIDLE2_PLL (offset 0x34) instead of CM_AUTOIDLE_PLL (offset 0x30). This patch changes the code to save the correct register. Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3: control/PM: move padconf save code to mach-omap2/control.cPaul Walmsley2010-12-211-0/+31
| | | | | | | | | | | | | | | | | | | | | | 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 <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> 1. OMAP34xx Multimedia Device Silicon Revision 3.1.x [Rev. ZH] [SWPU222H] Section 4.11.4 "Device Off-Mode Sequences"
* OMAP2/3: PRM/CM: prefix OMAP2 PRM/CM functions with "omap2_"Paul Walmsley2010-12-211-19/+21
| | | | | | | | | | | | | | | | Now that OMAP4-specific PRCM functions have been added, distinguish the existing OMAP2/3-specific PRCM functions by prefixing them with "omap2_". This patch should not result in any functional change. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Jarkko Nikula <jhnikula@gmail.com> Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com>
* OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific filesPaul Walmsley2010-12-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for adding OMAP4-specific PRCM accessor/mutator functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was OMAP2xxx/3xxx-specific. This process also requires the #includes in each of these files to be changed to reference the new file name. As part of doing so, add some comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use "sideways includes", to indicate that these users of the PRM/CM includes should not be doing so. Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Jarkko Nikula <jhnikula@gmail.com> Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Acked-by: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* OMAP3: control/PRCM: move CONTROL_PADCONF_SYS_NIRQ save/restore to SCM codePaul Walmsley2010-12-211-0/+5
| | | | | | | | | | | | | | | | | | | | | For some reason, the PRCM context save/restore code also saves and restores a single System Control Module register, CONTROL_PADCONF_SYS_NIRQ. This is probably just an error -- the register should be handled by SCM code -- so this patch moves it there. If this register really does need to be saved and restored before the rest of the PRCM registers, the code to do so should live in the SCM code, and the PM code should call this separate function. This register pertains to devices with a stacked modem, so this patch is unlikely to affect most OMAP devices out there. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com>
* OMAP3: control/PRCM: add omap3_ctrl_write_boot_mode()Paul Walmsley2010-12-211-0/+31
| | | | | | | | | | | | | | | | 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 <paul@pwsan.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* OMAP3: rework of the ASM sleep code execution pathsJean Pihet2010-12-211-1/+8
| | | | | | | | | | | | | | | | - Reworked and simplified the execution paths for better readability and to avoid duplication of code, - Added comments on the entry and exit points and the interaction with the ROM code for OFF mode restore, - Reworked the existing comments for better readability. Tested on N900 and Beagleboard with full RET and OFF modes, using cpuidle and suspend. Signed-off-by: Jean Pihet <j-pihet@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* OMAP3630: PM: Erratum i608: disable RTANishanth Menon2010-12-211-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | 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 OMAP3630 Workaround 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 <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Acked-by: Jean Pihet <j-pihet@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [ambresh@ti.com: co-developer] Signed-off-by: Ambresh K <ambresh@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* OMAP: control: move plat-omap/control.h to mach-omap2/control.hPaul Walmsley2010-10-081-1/+2
| | | | | | | | | | | | | | | | | 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 <paul@pwsan.com> Cc: Cory Maccarrone <darkstar6262@gmail.com> Cc: Kyungmin Park <kyungmin.park@samsung.com>
* OMAP: mach-omap2: Fix static declaration warningsManjunath Kondaiah G2010-10-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes sparse warnings due to non declaration of static structures and variables. Sparse warning logs fixed: arch/arm/mach-omap2/control.c:88:6: warning: symbol 'omap3_secure_ram_storage' was not declared. Should it be static? n arch/arm/mach-omap2/timer-gp.c:50:22: warning: symbol 'gptimer_wakeup' was not declared. Should it be static? arch/arm/mach-omap2/timer-gp.c:240:18: warning: symbol 'omap_timer' was not declared. Should it be static? arch/arm/mach-omap2/prcm.c:121:24: warning: symbol 'prcm_context' was not declared. Should it be static? arch/arm/mach-omap2/mux2420.c:510:29: warning: symbol 'omap2420_pop_ball' was not declared. Should it be static? arch/arm/mach-omap2/mux2430.c:589:29: warning: symbol 'omap2430_pop_ball' was not declared. Should it be static? arch/arm/mach-omap2/mux34xx.c:934:28: warning: symbol 'omap3_cus_subset' was not declared. Should it be static? arch/arm/mach-omap2/mux34xx.c:1080:29: warning: symbol 'omap3_cus_ball' was not declared. Should it be static? arch/arm/mach-omap2/mux34xx.c:1272:28: warning: symbol 'omap3_cbb_subset' was not declared. Should it be static? arch/arm/mach-omap2/mux34xx.c:1393:29: warning: symbol 'omap3_cbb_ball' was not declared. Should it be static? arch/arm/mach-omap2/mux34xx.c:1603:28: warning: symbol 'omap36xx_cbp_subset' was not declared. Should it be static? arch/arm/mach-omap2/mux34xx.c:1821:29: warning: symbol 'omap36xx_cbp_ball' was not declared. Should it be static? arch/arm/mach-omap2/pm-debug.c:165:15: warning: symbol 'pm_dbg_dir' was not declared. Should it be static? arch/arm/mach-omap2/board-omap3evm.c:587:30: warning: symbol 'ads7846_config' was not declared. Should it be static? arch/arm/mach-omap2/board-omap3evm.c:606:23: warning: symbol 'omap3evm_spi_board_info' was not declared. Should it be static? arch/arm/mach-omap2/board-rx51-sdram.c:46:25: warning: symbol 'rx51_sdrc_params' was not declared. Should it be static? arch/arm/mach-omap2/board-rx51-sdram.c:211:25: warning: symbol 'rx51_get_sdram_timings' was not declared. Should it be static? arch/arm/mach-omap2/board-omap3touchbook.c:64:15: warning: symbol 'touchbook_revision' was not declared. Should it be static? arch/arm/mach-omap2/board-am3517evm.c:350:24: warning: symbol 'am3517_evm_dss_device' was not declared. Should it be static? arch/arm/mach-omap2/board-omap3stalker.c:567:23: warning: symbol 'omap3stalker_spi_board_info' was not declared. Should it be static? Signed-off-by: Manjunath Kondaiah G <manjugk@ti.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* OMAP: mach-omap2: Fix incorrect assignment warningsManjunath Kondaiah G2010-10-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes below sparse warnings for incorrect assignments. arch/arm/mach-omap2/control.c:195:16: warning: incorrect type in assignment (different address spaces) arch/arm/mach-omap2/control.c:195:16: expected unsigned int [usertype] *v_addr arch/arm/mach-omap2/control.c:195:16: got void [noderef] <asn:2>*<noident> arch/arm/mach-omap2/control.c:199:25: warning: incorrect type in argument 1 (different address spaces) arch/arm/mach-omap2/control.c:199:25: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap2/control.c:199:25: got unsigned int [usertype] * arch/arm/mach-omap2/control.c:320:28: warning: incorrect type in assignment (different address spaces) arch/arm/mach-omap2/control.c:320:28: expected void *[noderef] <asn:2>scratchpad_address arch/arm/mach-omap2/control.c:320:28: got void [noderef] <asn:2>*<noident> arch/arm/mach-omap2/control.c:321:9: warning: incorrect type in argument 1 (different address spaces) arch/arm/mach-omap2/control.c:321:9: expected void volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap2/control.c:321:9: got void *[noderef] <asn:2>scratchpad_address arch/arm/mach-omap2/control.c:324:9: warning: incorrect type in argument 1 (different address spaces) arch/arm/mach-omap2/control.c:324:9: expected void volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap2/control.c:324:9: got void * arch/arm/mach-omap2/control.c:327:9: warning: incorrect type in argument 1 (different address spaces) arch/arm/mach-omap2/control.c:327:9: expected void volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap2/control.c:327:9: got void * arch/arm/mach-omap2/control.c:334:9: warning: incorrect type in argument 1 (different address spaces) arch/arm/mach-omap2/control.c:334:9: expected void volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap2/control.c:334:9: got void * arch/arm/mach-omap2/control.c:321:9: warning: dereference of noderef expression arch/arm/mach-omap2/control.c:324:9: warning: dereference of noderef expression arch/arm/mach-omap2/control.c:327:9: warning: dereference of noderef expression arch/arm/mach-omap2/control.c:334:9: warning: dereference of noderef expression arch/arm/mach-omap2/pm34xx.c:323:28: warning: incorrect type in assignment (different address spaces) arch/arm/mach-omap2/pm34xx.c:323:28: expected unsigned int [usertype] *scratchpad_address arch/arm/mach-omap2/pm34xx.c:323:28: got void [noderef] <asn:2>*<noident> arch/arm/mach-omap2/pm34xx.c:326:26: warning: incorrect type in argument 1 (different address spaces) arch/arm/mach-omap2/pm34xx.c:326:26: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap2/pm34xx.c:326:26: got unsigned int [usertype] * arch/arm/mach-omap2/pm34xx.c:329:26: warning: incorrect type in argument 1 (different address spaces) arch/arm/mach-omap2/pm34xx.c:329:26: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap2/pm34xx.c:329:26: got unsigned int [usertype] * arch/arm/mach-omap2/pm34xx.c:334:29: warning: incorrect type in argument 1 (different address spaces) arch/arm/mach-omap2/pm34xx.c:334:29: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap2/pm34xx.c:334:29: got unsigned int [usertype] * Signed-off-by: Manjunath Kondaiah G <manjugk@ti.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* omap4: control: Add accessor api's for pad control moduleSantosh Shilimkar2010-09-271-0/+18
| | | | | | | | | | | | On OMAP4 control pad are not addressable from control core base. So the common omap_ctrl_read/write APIs breaks Hence export separate APIs to manage the omap4 pad control registers. This APIs will work only for OMAP4 Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* omap4: control: Add ctrl_pad_base to omap_globalsSantosh Shilimkar2010-09-271-0/+7
| | | | | | | | | | | | | | | | | | | | | | | On omap4 control module is divided in four IP blocks. - CTRL_MODULE_CORE 0x4a002000 - CTRL_MODULE_PAD_CORE 0x4a100000 - CTRL_MODULE_WKUP 0x4a30c000 - CTRL_MODULE_PAD_WKUP 0x4a31e000 Addressing all the modules with single base address is not possible considering 16 bit offsets. The mux code manages the pad core and pad wakeup related base address inside the mux framework. For other usage only control core and control pad bases are necessary. So this patch maps only needed pad control base address which is used by device drivers and infrastructure code The main control core base is still kept same in this patch to keep git-bisect working. This will be fixed in the relevant patch in this series. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
OpenPOWER on IntegriCloud