aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/plat-omap/include
AgeCommit message (Collapse)Author
2010-12-21OMAP2+: hwmod: Add wakeup support for new OMAP4 IPsBenoit Cousson
The new OMAP4 IPs introduced a new idle mode named smart-idle with wakeup. This new idlemode replaces the enawakeup for the new IPs but seems to coexist as well for some legacy IPs (UART, GPIO, MCSPI...) Add the new SIDLE_SMART_WKUP flag to mark the IPs that support this capability. The omap_hwmod_44xx_data.c will have to be updated to add this new flag. Enable this new mode when applicable in _enable_wakeup, _enable_sysc and _idle_sysc. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Tested-by: Sebastien Guiriec <s-guiriec@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-21OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregisterBenoit Cousson
Do not allow omap_hwmod_register to be used outside the core hwmod code. An omap_hwmod should be registered only at init time. Remove the omap_hwmod_unregister that is not used today since the hwmod list will be built once at init time and never be modified at runtime. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpuPaul Walmsley
Clarify the usage of the struct omap_clk.cpu flags (e.g., CK_*) to use bits only for individual SoC variants (e.g., CK_3430ES1, CK_3505, etc.). Superset flags, such as CK_3XXX or CK_AM35XX, are now defined as disjunctions of individual SoC variant flags. This simplifies the definition and use of these flags. struct omap_clk record definitions can now simply specify the bitmask of actual SoCs that the records are valid for. The clock init code can simply set a single CPU type mask bit for the SoC that is currently in use, and test against that, rather than needing to set some combination of flags. Similarly, clarify the use of struct clksel_rate.flags. The bit allocated for RATE_IN_3XXX has been reassigned, and RATE_IN_3XXX has been defined as a disjunction of the 34xx and 36xx rate flags. The advantages are the same as the above. Clarify the usage of struct omap_clk.cpu flags such as CK_34XX to only apply to the SoCs that they name, e.g., OMAP34xx chips. The previous practice caused significantly different SoCs, such as OMAP36xx, to be included in CK_34XX. In my opinion, this is much more intuitive. Similarly, clarify the use of struct clksel_rate.flags, such that RATE_IN_3430ES2PLUS now only applies to 34xx chips with ES level >= 2 - it does not apply to OMAP36xx. ... At some point, it probably makes sense to collapse the CK_* and RATE_IN_* flags together into a single bitfield, and possibly use the existing CHIP_IS_OMAP* flags for platform detection. ... This all seems to work fine on OMAP34xx and OMAP36xx Beagle. Not sure if it works on Sitara or the TI816X, unfortunately I don't have any here to test with. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP3: control/PM: move padconf save code to mach-omap2/control.cPaul Walmsley
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"
2010-12-21OMAP2+: powerdomain: move header file from plat-omap to mach-omap2Paul Walmsley
The OMAP powerdomain code and data is all OMAP2+-specific. This seems unlikely to change any time soon. Move plat-omap/include/plat/powerdomain.h to mach-omap2/powerdomain.h. The primary point of doing this is to remove the temptation for unrelated upper-layer code to access powerdomain code and data directly. As part of this process, remove the references to powerdomain data from the GPIO "driver" and the OMAP PM no-op layer, both in plat-omap. Change the DSPBridge code to point to the new location for the powerdomain headers. The DSPBridge code should not be including the powerdomain headers; these should be removed. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com>
2010-12-21OMAP2+: clockdomain: move header file from plat-omap to mach-omap2Paul Walmsley
The OMAP clockdomain code and data is all OMAP2+-specific. This seems unlikely to change any time soon. Move plat-omap/include/plat/clockdomain.h to mach-omap2/clockdomain.h. The primary point of doing this is to remove the temptation for unrelated upper-layer code to access clockdomain code and data directly. DSPBridge also uses the clockdomain headers for some reason, so, modify it also. The DSPBridge code should not be including the clockdomain headers; these should be removed. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-12-21OMAP2/3: clockdomain: remove unneeded .clkstctrl_reg, remove some direct CM ↵Paul Walmsley
register accesses Reverse some of the effects of commit 84c0c39aec31a09571fc08a752a2f4da0fe9fcf2 ("ARM: OMAP4: PM: Make OMAP3 Clock-domain framework compatible for OMAP4"). On OMAP2/3, the CM_CLKSTCTRL register is at a constant offset from the powerdomain's CM instance. Also, remove some of the direct CM register access from the clockdomain code, moving it to the OMAP2/3 CM code instead. The intention here is to simplify the clockdomain code. (The long-term goal is to move all direct CM register access across the OMAP core code to the appropriate cm*.c file.) Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-12-21OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 supportPaul Walmsley
Add PRCM partition, CM instance register address offset, and clockdomain register address offset to each OMAP4 struct clockdomain record. Add OMAP4 clockdomain code to use this new data to access registers properly. While here, clean up some nearby clockdomain code to allocate auto variables in my recollection of Linus's preferred style. The autogeneration scripts have been updated. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-12-21OMAP4: powerdomains: add PRCM partition data; use OMAP4 PRM functionsPaul Walmsley
OMAP4 powerdomain control registers are split between the PRM hardware module and the PRCM_MPU local PRCM. Add this PRCM partition information to each OMAP4 powerdomain record, and convert the OMAP4 powerdomain function implementations to use the OMAP4 PRM instance functions. Also fixes a potential null pointer dereference of pwrdm->name. The autogeneration scripts have been updated. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com>
2010-12-21OMAP4: PRCM: add OMAP4-specific accessor/mutator functionsPaul Walmsley
In some ways, the OMAP4 PRCM register layout is quite different than the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a register layout point of view, all CM instances were located in the CM subsystem, and all PRM instances were located in the PRM subsystem. OMAP4 changes this. Now, for example, some CM instances, such as WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a "local PRCM" exists for the MPU - this PRCM combines registers that would normally appear in both CM and PRM instances, but uses its own register layout which matches neither the OMAP2/3 PRCM layout nor the OMAP4 PRCM layout. To try to deal with this, introduce some new functions, omap4_cminst* and omap4_prminst*. The former is to be used when writing to a CM instance register (no matter what subsystem or hardware module it exists in), and the latter, similarly, with PRM instance registers. To determine which "PRCM partition" to write to, the functions take a PRCM instance ID argument. Subsequent patches add these partition IDs to the OMAP4 powerdomain and clockdomain definitions. As far as I can see, there's really no good way to handle these types of register access inconsistencies. This patch seemed like the least bad approach. Moving forward, the long-term goal is to remove all direct PRCM register access from the PM code. PRCM register access should go through layers such as the powerdomain and clockdomain code that can hide the details of how to interact with the specific hardware variant. While here, rename cm4xxx.c to cm44xx.c to match the naming convention of the other OMAP4 PRCM files. Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak <rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-12-21OMAP3: PRM/CM: separate CM context save/restore; remove PRM context save/restorePaul Walmsley
The OMAP3 PRM module is in the WKUP powerdomain, which is always powered when the chip is powered, so it shouldn't be necessary to save and restore those PRM registers. Remove the PRM register save/restore code, which should save several microseconds during off-mode entry/exit, since PRM register accesses are relatively slow. While doing so, move the CM register save/restore code into CM-specific code. The CM module has been distinct from the PRM module since 2430. This patch includes some minor changes to pm34xx.c. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Tero Kristo <tero.kristo@nokia.com> Cc: Kalle Jokiniemi <kalle.jokiniemi@digia.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>
2010-12-21OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific filesPaul Walmsley
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>
2010-12-21OMAP2+: clockdomains: move clockdomain static data to .c filesPaul Walmsley
Static data should be declared in .c files, not .h files. It should be possible to #include .h files at any point without creating multiple copies of the same data. We converted the clock data to .c files some time ago. This patch does the same for the clockdomain data. 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> Tested-by: Rajendra Nayak <rnayak@ti.com>
2010-12-21OMAP2+: powerdomains: move powerdomain static data to .c filesPaul Walmsley
Static data should be declared in .c files, not .h files. It should be possible to #include .h files at any point without creating multiple copies of the same data. We converted the clock data to .c files some time ago. This patch does the same for the powerdomain data. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.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>
2010-12-21OMAP: powerdomain: Infrastructure to put arch specific codeRajendra Nayak
Put infrastructure in place, so arch specific func pointers can be hooked up to the platform-independent part of the framework. This is in preparation of splitting the powerdomain framework into platform-independent part (for all omaps) and platform-specific parts. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.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>
2010-12-21OMAP: powerdomain: Move static allocations from powerdomains.h to a .c fileRajendra Nayak
powerdomains.h header today has only static definitions. Adding any function declarations into it and including it in multiple source file is expected to cause issues. Hence move all the static definitions from powerdomains.h file into powerdomains_data.c file. Also, create a new powerdomain section of the mach-omap2/Makefile, and rearrange the prcm-common part of the Makefile, now that the powerdomain code is in its own Makefile section. Signed-off-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: rearrange Makefile changes, tweaked commit message] 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> Tested-by: Rajendra Nayak <rnayak@ti.com>
2010-12-21OMAP2+: hwmod: fix a warning, add some docs, remove unused fieldsPaul Walmsley
Trivial cleanup and documentation changes on the hwmod code and data: - add some hwmod documentation to indicate flags that should be moved outside the static hwmod data in a future patch - remove some unused fields in the struct omap_hwmod_ocp_if and struct omap_hwmod structures Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-21OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlockPaul Walmsley
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock serializes most post-initialization hwmod operations such as enable, idle, and shutdown.) Spinlocks are needed, because in some cases, hwmods must be enabled from timer interrupt disabled-context, such as an ISR. The current use-case that is driving this is the OMAP GPIO block ISR: it can trigger interrupts even with its clocks disabled, but these clocks are needed for register accesses in the ISR to succeed. This patch also effectively reverts commit 848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes _omap_hwmod_enable() and _omap_hwmod_init() static, renames them back to _enable() and _idle(), and changes their callers to call the spinlocking versions. Previously, since omap_hwmod_{enable,init}() attempted to take mutexes, these functions could not be called while the timer interrupt was disabled; but now that the functions use spinlocks and save and restore the IRQ state, it is appropriate to call them directly. Kevin Hilman <khilman@deeprootsystems.com> originally proposed this patch - thanks Kevin. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-21OMAP2+: hwmod: add support for per-class custom device reset functionsPaul Walmsley
The standard omap_hwmod.c _reset() code relies on an IP block's OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This works for most IP blocks on the chip, but unfortunately not all. For example, initiator-only IP blocks often don't have any MPU-accessible OCP-header registers, and therefore the MPU can't write to any OCP_SYSCONFIG registers in that block. Other IP blocks, such as the IVA and I2C, require a specialized reset sequence. Since we need to be able to reset these IP blocks as well, allow custom IP block reset functions to be passed into the hwmod code via a per-hwmod-class reset function pointer, struct omap_hwmod_class.reset. If .reset is non-null, then the hwmod _reset() code will call the custom function instead of the standard OCP SOFTRESET-based code. As part of this change, rename most of the existing _reset() function code to _ocp_softreset(), to indicate more clearly that it does not work for all cases. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Paul Hunt <hunt@ti.com> Cc: Stanley Liu <stanley_liu@ti.com>
2010-12-21OMAP2+: hwmod: add postsetup statePaul Walmsley
Allow board files and OMAP core code to control the state that some or all of the hwmods end up in at the end of _setup() (called by omap_hwmod_late_init() ). Reimplement the old skip_setup_idle code in terms of this new postsetup state code. There are two use-cases for this patch: the !CONFIG_PM_RUNTIME case, in which all IP blocks should stay enabled after _setup() finishes; and the MPU watchdog case, in which the watchdog IP block should enter idle if watchdog coverage of kernel initialization is desired, and should be disabled otherwise. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Charulatha Varadarajan <charu@ti.com>
2010-12-21OMAP2+: hwmod: allow custom pre-shutdown functionsPaul Walmsley
Some OMAP IP blocks, such as the watchdog timers, cannot be completely shut down via the standard hwmod shutdown mechanism. This patch enables the hwmod data files to supply a pointer to a custom pre-shutdown function via the struct omap_hwmod_class.pre_shutdown function pointer. If the struct omap_hwmod_class.pre_shutdown function pointer is non-null, the function will be executed before the existing hwmod shutdown code runs. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2010-12-21OMAP2+: io: split omap2_init_common_hw()Paul Walmsley
Split omap2_init_common_hw() into two functions. The first, omap2_init_common_infrastructure(), initializes the hwmod code and data, the OMAP PM code, and the clock code and data. The second, omap2_init_common_devices(), handles any other early device initialization that, for whatever reason, has not been or cannot be moved to initcalls or early platform devices. This patch is required for the hwmod postsetup patch, which allows board files to change the state that hwmods should be placed into at the conclusion of the hwmod _setup() function. For example, for a board whose creators wish to ensure watchdog coverage across the entire kernel boot process, code to change the watchdog's postsetup state will be added in the board-*.c file between the omap2_init_common_infrastructure() and omap2_init_common_devices() function calls. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
2010-12-21OMAP3: Devkit8000: Add DEBUG_LL supportThomas Weber
Add support for DEBUG_LL for Devkit8000. Devkit8000 uses uart 3 for debug output. Signed-off-by: Thomas Weber <weber@corscience.de> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-21Merge branch 'pm-opp' of ↵Tony Lindgren
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-linus
2010-12-21Merge branch 'pm-next' of ↵Tony Lindgren
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-linus
2010-12-21Merge branch 'devel-dma' into omap-for-linusTony Lindgren
2010-12-21OMAP2+: use global values for the SRAM PA addressesJean Pihet
The SRAM PA addresses are locally defined and used at different places, i.e. SRAM management code and idle sleep code. The macros are now defined at a centralized place, for easier maintenance. 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>
2010-12-21OMAP3: remove OPP interfaces from OMAP PM layerKevin Hilman
With new OPP layer, OPP users will access OPP API directly instead of using OMAP PM layer, so remove all notions of OPPs from the OMAP PM layer. Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-21OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanosecondsAdrian Hunter
The calculations done with sync_clk are anyway in picoseconds and switching to picoseconds allows sync_clk values that are not a whole number of nanoseconds - which is sometimes the case. Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-20Merge branches 'devel-iommu-mailbox' and 'devel-l2x0' into omap-for-linusTony Lindgren
2010-12-20omap1: Fix innovator FPGA init for multi-omapTony Lindgren
No need to call this early from init_irq. Also recent changes initialize GPIO now later, so calling gpio_request from init_irq will make it fail. While at it, also remove the unnecessary EXPORT_SYMBOL. Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-20OMAP: DMA: Convert DMA library into platform driverG, Manjunath Kondaiah
Convert DMA library into DMA platform driver and make use of platform data provided by hwmod data base for OMAP2+ onwards. For OMAP1 processors, the DMA driver in mach-omap uses resource structures for getting platform data. Thanks to Tony Lindgren <tony@atomide.com> for fixing various omap1 issues and testing the same on OSK5912 board. Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-20OMAP2430: hwmod data: add system DMAG, Manjunath Kondaiah
Add OMAP2430 DMA hwmod data and also add required DMA device attributes. Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-20OMAP2420: hwmod data: add system DMAG, Manjunath Kondaiah
Add OMAP2420 DMA hwmod data and also add required DMA device attributes. Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-20OMAP: DMA: Introduce errata handling featureG, Manjunath Kondaiah
Implement errata handling to use flags instead of cpu_is_* and cpu_class_* in the code. The errata flags are initialized at init time and during runtime we are using the errata variable (via the IS_DMA_ERRATA macro) to execute the required errata workaround. Reused errata handling patch from: Peter Ujfalusi <peter.ujfalusi@nokia.com> https://patchwork.kernel.org/patch/231191/ Changes to above patch: 1. Changes are done for converting all the existing errata work arounds to use this feature. 2. Detailed description for each errata is added. 3. Fixed bug in SET_DMA_ERRATA macro 4. Bit shifting in macro definitions are replaced with BIT() macro Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-20OMAP: DMA: Replace read/write macros with functionsG, Manjunath Kondaiah
Prepare DMA library to get converted into DMA driver using platform device model and hwmod infrastucture(for omap2+, resource structures for omap1) The low level read/write macros are replaced with static inline functions and register offsets are handled through static register offset tables mapped through enumeration constants. These low level read/write functions along with static register offset tables will be moved to respective mach-omap dma files in the later patches of this series. There are no functionality changes with these changes except change in logic for handling 16bit registers of OMAP1. Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-20omap: serial: Change device name: omap-hsuart -> omap_uartBenoit Cousson
The naming convention for omap_device is omap_XXX. Rename the device and driver name in order to stick to this naming convention. Remove the hs prefix that is implicit for every OMAP uarts. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Govindraj Raja <govindraj.raja@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-20ARM: SMP: remove smp_mpidr.hRussell King
With "ARM: CPU hotplug: remove bug checks in platform_cpu_die()", we now do not use hard_smp_processor_id(), we no longer need to read the hardware processor ID. Remove the include providing this function. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-12-17Merge branch 'for_2.6.38' of git://gitorious.org/iommu_mailbox/iommu_mailbox ↵Tony Lindgren
into devel-iommu-mailbox
2010-12-17Merge branch 'devel-board' into omap-for-linusTony Lindgren
2010-12-17arm: omap: add minimal support for RM-680Aaro Koskinen
Add minimal support for Nokia RM-680 board. Tested with omap2plus_defconfig. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> [tony@atomide.com: updated to remove omap_gpio_init Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-15OMAP: iommu: create new api to set valid da rangeGuzman Lugo, Fernando
Some IOMMUs cannot use the whole 0x0 - 0xFFFFFFFF range. With this new API the valid range can be set. Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com> Acked-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
2010-12-10Merge branch 'devel-gpio' into omap-for-linusTony Lindgren
2010-12-10Merge branch 'devel-omap-irq' into omap-for-linusTony Lindgren
2010-12-10usb: otg: Adding twl6030-usb transceiver driver for OMAP4430Hema HK
Adding the twl6030-usb transceiver support for OMAP4 musb driver. OMAP4 supports 2 types of transceiver interface. 1. UTMI: The PHY is embedded within OMAP4. The transceiver functionality is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY functionality is embedded within the OMAP4430. There is no direct interactions between the MUSB controller and TWL6030 chip to communicate the session-valid, session-end and ID-GND events. It has to be done through a software by setting/resetting bits in one of the control module register of OMAP4430 which in turn toggles the appropriate signals to MUSB controller. The internal transceiver has functional clocks and powerdown bits to powerdown the PHY for power saving. Since there is no option available for having 2 transceiver drivers for one USB controller, internal PHY specific APIs are passed through plaform_data function pointers to use in the twl6030-usb transceiver driver. 2. ULPI interface is provided for off-chip transceivers. Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Felipe Balbi <balbi@ti.com>
2010-12-10musb: am35x: fix compile error due to control apisAjay Kumar Gupta
commit 4814ced5116e3b73dc4f63eec84999739fc8ed11 (OMAP: control: move plat-omap/control.h to mach-omap2/control.h) moved <plat/control.h> to another location, preventing drivers from accessing it, so we need to pass function pointers from arch code to be able to talk to internal PHY on AM35x. Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2010-12-09omap1: Use asm_irq_flags for entry-macro.STony Lindgren
Initialize asm_irq_flags in omap_init_irq and use it in get_irqnr_and_base to detect between omap7xx and omap15xx/16xx. Note that both INT_1510_IH2_IRQ and INT_1510_IH2_IRQ are defined as 0, so use INT_1510_IH2_IRQ for both of them. Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-08ARM: io: make iounmap() a simple macroRussell King
Defining iounmap() with arguments prevents it from being used as a function pointer, causing platforms to work around this. Instead, define it to be a simple macro. Do the same for __arch_io(re|un)map too. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-12-07omap1: Fix gpio mpuio bank to work for multi-omap for 7xx/15xx/16xxTony Lindgren
We need to divide the 15xx/16xx offset by 2 for 7xx. Use bank->stride for that. This allows us to get rid of the duplicate defines for the MPUIO registers. Note that this will cause omap-keypad.c driver to not work on 7xx. However, the right fix there is to move over to matrix_keypad instead as suggested by Cory Maccarrone <darkstar6262@gmail.com> and Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>. Cc: Cory Maccarrone <darkstar6262@gmail.com> Acked-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-07OMAP: GPIO: Implement GPIO as a platform deviceVaradarajan, Charulatha
Implement GPIO as a platform device. GPIO APIs are used in machine_init functions. Hence it is required to complete GPIO probe before board_init. Therefore GPIO device register and driver register are implemented as postcore_initcalls. omap_gpio_init() does nothing now and this function would be removed in the next patch as it's usage is spread across most of the board files. Inorder to convert GPIO as platform device, modifications are required in clockxxxx_data.c file for OMAP1 so that device names can be used to obtain clock instead of getting clocks by name/NULL ptr. Use runtime pm APIs (pm_runtime_put*/pm_runtime_get*) for enabling or disabling the clocks, modify sysconfig settings and remove usage of clock FW APIs. Note 1: Converting GPIO driver to use runtime PM APIs is not done as a separate patch because GPIO clock names are different for various OMAPs and are different for some of the banks in the same CPU. This would need usage of cpu_is checks and bank id checks while using clock FW APIs in the gpio driver. Hence while making GPIO a platform driver framework, PM runtime APIs are used directly. Note 2: While implementing GPIO as a platform device, pm runtime APIs are used as mentioned above and modification is not done in gpio's prepare for idle/ resume after idle functions. This would be done in the next patch series and GPIO driver would be made to use dev_pm_ops instead of sysdev_class in that series only. Due to the above, the GPIO driver implicitly relies on CM_AUTOIDLE = 1 on its iclk for power management to work, since the driver never disables its iclk. This would be taken care in the next patch series (see Note 3 below). Refer to http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39112.html for more details. Note 3: only pm_runtime_get_sync is called in gpio's probe() and pm_runtime_put* is never called. This is to make the implementation similar to the existing GPIO code. Another patch series would be sent to correct this. In OMAP3 and OMAP4 gpio's debounce clocks are optional clocks. They are enabled/ disabled whenever required using clock framework APIs TODO: 1. Cleanup the GPIO driver. Use function pointers and register offest pointers instead of using hardcoded values 2. Remove all cpu_is_ checks and OMAP specific macros 3. Remove usage of gpio_bank array so that only instance specific information is used in driver code 4. Rename 'method'/ avoid it's usage 5. Fix the non-wakeup gpios handling for OMAP2430, OMAP3 & OMAP4 6. Modify gpio's prepare for idle/ resume after idle functions to use runtime pm implentation. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Basak, Partha <p-basak2@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> [tony@atomide.com: updated for bank specific revision and updated boards] Signed-off-by: Tony Lindgren <tony@atomide.com>