summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2
AgeCommit message (Collapse)Author
2012-01-05OMAPDSS: HDMI: Move duplicate code from boardfileMythri P K
Move duplicate HDMI mux_init code from omap4 and panda board file to display file. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-01-03Merge branch 'imx/board' into next/boardsArnd Bergmann
* imx/board: (4 commits) Enable 32 bit flash support for iMX21ADS board ARM: mx31pdk: Add MC13783 RTC support iomux-mx25: configuration to support CSPI3 on CSI pins MX1:apf9328: Add i2c support Updated to v3.2-rc6, conflicts: arch/arm/kernel/setup.c
2012-01-03Merge branch 'v3.2-rc7' into next/pmArnd Bergmann
Conflicts: arch/arm/kernel/setup.c arch/arm/mach-shmobile/board-kota2.c
2011-12-27Merge branch 'omap/ehci' into next/driversArnd Bergmann
* omap/ehci: MFD: OMAP: USB: Runtime PM support ARM: OMAP: USBHOST: Replace usbhs core driver APIs by Runtime pm APIs ARM: OMAP: USB: device name change for the clk names of usbhs ARM: OMAP: USB: register hwmods of usbhs
2011-12-27Merge branch 'omap/hwmod' into next/driversArnd Bergmann
This is needed as a dependency for omap/ehci. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2011-12-27Merge branch 'omap/hwmod' into next/develArnd Bergmann
* omap/hwmod: ARM: OMAP3+: hwmod data: Add the default clockactivity for I2C ARM: OMAP3: hwmod data: disable multiblock reads on MMC1/2 on OMAP34xx/35xx <= ES2.1 ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP4 ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3 ARM: OMAP: hwmod data: Add support for AM35xx UART4/ttyO3 ARM: OMAP: hwmod data: fix the panic on Nokia RM-680 during boot ARM: OMAP: hwmod data: fix iva and mailbox hwmods for OMAP 3 ARM: OMAP: rx51: fix USB ARM: OMAP: mcbsp: Fix possible memory corruption
2011-12-20Merge branch 'fixes-hwmod-regression' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
2011-12-19Merge branch 'arm/common-kconfig-refactor+for-rmk' of ↵Russell King
git://git.linaro.org/people/dmart/linux-2.6-arm into devel-stable
2011-12-19omap4: Unconditionally require l2x0 L2 cache controller supportDave Martin
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com>
2011-12-19ARM: SMP: Refactor Kconfig to be more maintainableDave Martin
Making SMP depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new HAVE_SMP config option is introduced to allow machines to indicate that they can run in a SMP configuration. Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> (for nomadik, ux500) Acked-by: Tony Lindgren <tony@atomide.com> (for omap) Acked-by: Kukjin Kim <kgene.kim@samsung.com> (for exynos) Acked-by: Sascha Hauer <s.hauer@pengutronix.de> (for imx) Acked-by: Olof Johansson <olof@lixom.net> (for tegra)
2011-12-19ARM: l2x0/pl310: Refactor Kconfig to be more maintainableDave Martin
Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms have a L2x0 or PL310 cache controller to the individual machines. To enable this, a new MIGHT_HAVE_CACHE_L2X0 config option is introduced to allow machines to indicate that they may have such a cache controller independently of each other. Boards/SoCs which cannot reliably operate without the L2 cache controller support will need to select CACHE_L2X0 directly from their own Kconfigs instead. This applies to some TrustZone-enabled boards where Linux runs in the Normal World, for example. Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com> (for cns3xxx) Acked-by: Tony Lindgren <tony@atomide.com> (for omap) Acked-by: Shawn Guo <shawn.guo@linaro.org> (for imx) Acked-by: Kukjin Kim <kgene.kim@samsung.com> (for exynos) Acked-by: Sascha Hauer <s.hauer@pengutronix.de> (for imx) Acked-by: Olof Johansson <olof@lixom.net> (for tegra)
2011-12-18ARM: 7205/2: sched_clock: allow sched_clock to be selected at runtimeMarc Zyngier
sched_clock() is yet another blocker on the road to the single image. This patch implements an idea by Russell King: http://www.spinics.net/lists/linux-omap/msg49561.html Instead of asking the platform to implement both sched_clock() itself and the rollover callback, simply register a read() function, and let the ARM code care about sched_clock() itself, the conversion to ns and the rollover. sched_clock() uses this read() function as an indirection to the platform code. If the platform doesn't provide a read(), the code falls back to the jiffy counter (just like the default sched_clock). This allow some simplifications and possibly some footprint gain when multiple platforms are compiled in. Among the drawbacks, the removal of the *_fixed_sched_clock optimization which could negatively impact some platforms (sa1100, tegra, versatile and omap). Tested on 11MPCore, OMAP4 and Tegra. Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Eric Miao <eric.y.miao@gmail.com> Cc: Colin Cross <ccross@android.com> Cc: Erik Gilling <konkers@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Alessandro Rubini <rubini@unipv.it> Cc: STEricsson <STEricsson_nomadik_linux@list.st.com> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Ben Dooks <ben-linux@fluff.org> Tested-by: Jamie Iles <jamie@jamieiles.com> Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Krzysztof Halasa <khc@pm.waw.pl> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-12-17OMAP4: mcbsp: Enable FIFO usagePeter Ujfalusi
All McBSP instances on OMAP4 has 128 word long FIFO Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2011-12-16Merge branch 'usbhost_runtime_pm_14_devel_3.3' of ↵Tony Lindgren
git://git.pwsan.com/linux-2.6 into ehci
2011-12-16Merge branch 'hwmod_data_devel_3.3' of git://git.pwsan.com/linux-2.6 into hwmodTony Lindgren
2011-12-16ARM: OMAP4: clock: Add CPU local timer clock nodeSantosh Shilimkar
Local timer clock is sourced from the CPU clock and hence changes along with CPU clock. These per CPU local timers are used as clock-events, so they need to be reconfigured on CPU frequency change as part of CPUfreq governor. Newly introduced clockevents_reconfigure() needs to know the twd clock-rate. Provide a clock-node to make clk_get_rate() work for TWD. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: renamed clock node to 'mpu_periphclk' to indicate that this is the Cortex-A9 MPCore subsystem clock PERIPHCLK (DDI 0407G); moved clock and clkdev entries to match the autogenerated script output] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-16ARM: OMAP4: hwmod: Don't wait for the idle status if modulemode is not supportedBenoit Cousson
If the module does not have any modulemode, the _disable_module function will do nothing. There is then no point waiting for a idle status change. It will remove the following warnings. [ 0.331848] omap_hwmod: dmm: _wait_target_disable failed [ 0.339935] omap_hwmod: emif_fw: _wait_target_disable failed [ 0.348358] omap_hwmod: l3_main_1: _wait_target_disable failed [ 0.356964] omap_hwmod: l3_main_2: _wait_target_disable failed [ 0.365600] omap_hwmod: l4_abe: _wait_target_disable failed [ 0.373931] omap_hwmod: l4_cfg: _wait_target_disable failed [ 0.382263] omap_hwmod: l4_per: _wait_target_disable failed [ 0.391113] omap_hwmod: l4_wkup: _wait_target_disable failed [ 0.399536] omap_hwmod: dma_system: _wait_target_disable failed [ 0.408325] omap_hwmod: dss_core: _wait_target_disable failed [ 0.416839] omap_hwmod: dss_dispc: _wait_target_disable failed [ 0.425445] omap_hwmod: dss_dsi1: _wait_target_disable failed [ 0.433990] omap_hwmod: dss_dsi2: _wait_target_disable failed [ 0.442504] omap_hwmod: dss_hdmi: _wait_target_disable failed [ 0.451019] omap_hwmod: dss_rfbi: _wait_target_disable failed [ 0.459564] omap_hwmod: dss_venc: _wait_target_disable failed [ 0.489471] omap_hwmod: mailbox: _wait_target_disable failed [ 0.505920] omap_hwmod: spinlock: _wait_target_disable failed Note: For such module, the state is managed automatically by HW according to clock domain transition. It is then not possible to wait for idle even later in the _idle function since the status will change at clock domain boundary. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: renamed fns to indicate that they are OMAP4-only; moved _wait_target_disable() into _disable_module(), removing duplicate code] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-16ARM: OMAP: AM3517/3505: fix crash on boot due to incorrect voltagedomain dataPaul Walmsley
AM3517/3505 chips don't have voltage controller and voltage processor IP blocks. Trying to use OMAP34xx/36xx voltage domain data on these chips causes a crash during boot: omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc Unable to handle kernel NULL pointer dereference at virtual address 00000025 pgd = c0004000 [00000025] *pgd=00000000 Internal error: Oops: 5 [#1] SMP Modules linked in: CPU: 0 Tainted: G W (3.2.0-rc5-00006-g402ecf4 #304) PC is at omap_vp_init+0x5c/0x14c LR is at omap_vp_init+0x54/0x14c Fix this by using very minimal voltage domain definitions for AM3517/3505. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Igor Grinberg <grinberg@compulab.co.il> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-16Merge branch 'hwmod_data_fixes_3.2rc' of git://git.pwsan.com/linux-2.6 into ↵Tony Lindgren
fixes-hwmod
2011-12-16ARM: omap: pass minimal SoC/board data for UART from dtRajendra Nayak
Pass minimal data needed for console boot, from dt, for OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the static initialization from generic board file. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-16Merge branch 'for_3.3/uart/runtime-pm' of ↵Tony Lindgren
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into uart Conflicts: arch/arm/mach-omap2/pm34xx.c
2011-12-16Merge branch 'tk_prm_chain_handler_devel_3.3' of ↵Tony Lindgren
git://git.pwsan.com/linux-2.6 into prcm Conflicts: arch/arm/mach-omap2/Makefile
2011-12-16ARM: OMAP2+: hwmod: Add a new flag to handle hwmods left enabled at initRajendra Nayak
An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in enabled state by the hwmod framework post the initial setup. Once a real user of the device (a driver) tries to enable it at a later point, the hwmod framework throws a WARN() about the device being already in enabled state. Fix this by introducing a new internal flag '_HWMOD_SKIP_ENABLE' to identify such devices/hwmods. When the device/hwmod is requested to be enabled (the first time) by its driver/user, nothing except the mux-enable is needed. The mux data is board specific and is unavailable during initial enable() of the device, done by the framework as part of setup(). A good example of a such a device is an UART used as debug console. The UART module needs to be kept enabled through the boot, until the UART driver takes control of it, for debug prints to appear on the console. Acked-by: Kevin Hilman <khilman@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: use a flag rather than a state; updated commit message; edited some documentation] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-16ARM: OMAP4: PRM: use PRCM interrupt handlerTero Kristo
Use the new PRCM interrupt handler code on OMAP4 systems. The OMAP code will need to be converted to use sparse IRQs for this to work. Until that time, the following message will appear on boot: PRCM: failed to allocate irq descs: -12 Signed-off-by: Tero Kristo <t-kristo@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: split this from a previous patch to this patch; call omap4xxx_prcm_init() during init; write trivial commit log] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP3: pm: use prcm chain handlerTero Kristo
PM interrupt handling is now done through the PRCM chain handler. The interrupt handling logic is also split in two parts, to serve IO and WKUP events separately. This allows us to handle IO chain events in a clean way. Core event code is also changed in accordance to this, as PRCM interrupt handling is done by independent handlers, and the core handler should not clear the IO events anymore. Signed-off-by: Tero Kristo <t-kristo@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: use pr_err(); combined with portions of earlier patches and the "do not enable PRCM MPU interrupts manually" patch] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP: hwmod: add support for selecting mpu_irq for each wakeup padTero Kristo
By default all registered pads will trigger mpu_irqs[0]. Now there is an API for selecting used mpu_irq on pad basis, which can be used to trigger different irq handlers for different pads in the same hwmod. Each pad that requires its interrupt to be re-routed this way must have a separate call to omap_hwmod_pad_route_irq(hwmod, pad, irq). Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: moved fn to omap_hwmod.c; separated fn from mux scan_wakeups changes; added kerneldoc] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP2+: mux: add support for PAD wakeup interruptsTero Kristo
OMAP mux now parses active wakeup events from pad registers and calls corresponding hwmod ISRs once a wakeup is detected. This is accomplished by registering an interrupt handler for PRCM IO event, which is raised every time the HW detects wakeups. [paul@pwsan.com: This patch is a merge of Govindraj R's "ARM: OMAP2+: hwmod: Add API to check IO PAD wakeup status" patch, Tero Kristo's "ARM: OMAP2+: mux: add support for PAD wakeup interrupts" patch, and part of Tero's "ARM: OMAP: mux: add support for selecting mpu_irq for each wakeup pad" patch.] Signed-off-by: Tero Kristo <t-kristo@ti.com> Cc: Govindraj.R <govindraj.raja@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> [paul@pwsan.com: reduced indentation level; renamed omap_hwmod function; improved function documentation; modified to iterate only through dynamic pads; modified to skip pads where idle mode doesn't enable wakeups; split patches] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP: PRCM: add suspend prepare / finish supportTero Kristo
PRCM chain handler needs to disable forwarding of interrupts during suspend, because runtime PM is disabled and most of the drivers are potentially not able to handle interrupts coming at this time. This patch masks all the PRCM interrupt events if a PRCM interrupt occurs during suspend, but does not ack them. Once suspend finish is called, all the masked events will be re-enabled, which causes immediate PRCM interrupt and handles the postponed event. The suspend prepare and complete callbacks will be called from pm34xx.c / pm44xx.c files in the following patches. The functions defined in this patch should eventually be moved to suspend->prepare and suspend->finish driver hooks, once the PRCM chain handler will be made as its own driver. Signed-off-by: Tero Kristo <t-kristo@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: add kerneldoc, add omap_prcm_irq_setup.saved_mask, add fn ptrs for save_and_clear_irqen() and restore_irqen()] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP: PRCM: add support for chain interrupt handlerTero Kristo
Introduce a chained interrupt handler mechanism for the PRCM interrupt, so that individual PRCM event can cleanly be handled by handlers in separate drivers. We do this by introducing PRCM event names, which are then matched to the particular PRCM interrupt bit depending on the specific OMAP SoC being used. PRCM interrupts have two priority levels, high or normal. High priority is needed for IO event handling, so that we can be sure that IO events are processed before other events. This reduces latency for IO event customers and also prevents incorrect ack sequence on OMAP3. Signed-off-by: Tero Kristo <t-kristo@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Avinash.H.M <avinashhm@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Govindraj.R <govindraj.raja@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: drop some dead code; use SoC-specific pending IRQ detection; move code to prm_common.c; add lots of documentation; remove saved_mask; add OCP barrier on ISR exit; improved error handling; split out per-SoC initialization to a separate patch] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP3/4: PRM: add functions to read pending IRQs, PRM barrierPaul Walmsley
Add PRM functions to test for pending PRM IRQs. This will be used in a subsequent patch to implement the PRM interrupt handler on the MPU. Add PRM functions to ensure that all outstanding writes from the MPU to the PRM IP block have completed before continuing execution. This will be used in a subsequent patch to ensure that all PRM interrupt status bits are cleared in the hardware before exiting the ISR. Normally we would not expose such a low-level function to other code. But the current implementation of the PRM interrupt code, which uses the generic IRQ chip code, doesn't give us a choice. The pending PRM IRQ functions are based on code originally written by Tero Kristo <t-kristo@ti.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com>
2011-12-16ARM: OMAP2+: hwmod: Add API to enable IO ring wakeupGovindraj R
Add API to enable IO pad wakeup capability based on mux pad and wake_up enable flag available from hwmod_mux initialization. Use the wakeup_enable flag and enable wakeup capability for the given pads. Wakeup capability will be enabled/disabled during hwmod idle transition based on whether wakeup_flag is set or cleared. If the hwmod is currently idled, and any mux values were changed by _set_idle_ioring_wakeup(), the SCM PADCTRL registers will be updated. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: rearranged code to limit indentation; cleaned up function documentation; removed unused non-static functions; modified to search all hwmod pads, not just dynamic remuxing ones; modified to update SCM regs if hwmod is currently idle and any pads have changed] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP2+: mux: add wakeup-capable hwmod mux entries to dynamic listPaul Walmsley
omap_hwmod_mux() currently only iterates through the dynamic pad list. This list currently only consists of pads with the OMAP_DEVICE_MUX_REMUX flag set. Subsequent patches in this series will cause hwmod mux entries with the OMAP_DEVICE_MUX_WAKEUP flag set to be changed dynamically, to control hwmod I/O ring wakeup. For this to work correctly, hwmod mux entries with the OMAP_DEVICE_MUX_WAKEUP flag set must also be added to the dynamic pad list. So this patch modifies omap_hwmod_mux_init() to do so. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Tero Kristo <t-kristo@ti.com> Cc: Govindraj R <govindraj.raja@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
2011-12-16ARM: OMAP: USB: device name change for the clk names of usbhsKeshava Munegowda
device name usbhs clocks are changed from usbhs-omap.0 to usbhs_omap; this is because in the hwmod registration the device name is set as usbhs_omap; The redudant clock nodes are removed. Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com> Reviewed-by: Partha Basak <parthab@india.ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP: USB: register hwmods of usbhsKeshava Munegowda
The hwmod structure of usb_host_hs and usb_tll are retrieved and registered with omap device Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com> Reviewed-by: Partha Basak <parthab@india.ti.com> [paul@pwsan.com: this patch is merged with the understanding that the authors will send patches for the next merge window to remove the multiple hwmods-per-omap_device] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP3+: hwmod data: Add the default clockactivity for I2CShubhrajyoti D
For I2C clockactivity field is added for OMAP3 and OMAP4 that defines how the interface (OCP) and functional (system) clocks behave when the I2C module is idle. The configuration of the clock activity bit field (per TRM) is as follows: 0x0: Both clocks can be cut off 0x1: Only OCP clock must be kept active; system clock can be cut off 0x3: Both clocks must be kept active 0x2: Only system clock must be kept active; OCP clock can be cut off The patch makes 0x2(CLOCKACT_TEST_ICLK) the default for OMAP3 and OMAP4. Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP3: hwmod data: disable multiblock reads on MMC1/2 on OMAP34xx/35xx ↵Paul Walmsley
<= ES2.1 The HSMMC1/HSMMC2 host controllers on OMAP34xx and OMAP3503/3515/3525/3530 chips at ES levels prior to 3.0 can't do multiple block reads[1]. Mark the hwmod data appropriately. Reported by Dave Hylands <dhylands@gmail.com> and Steve Sakoman <sakoman@gmail.com>. Thanks to Steve Sakoman for further help testing this patch. 1. See for example Advisory 2.1.1.128 "MMC: Multiple Block Read Operation Issue" in _OMAP3530/3525/3515/3503 Silicon Errata_ Revision F (October 2010) (SPRZ278F), available from http://focus.ti.com/lit/er/sprz278f/sprz278f.pdf Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Dave Hylands <dhylands@gmail.com> Cc: Steve Sakoman <sakoman@gmail.com>
2011-12-16ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP4Benoit Cousson
Following 2 hwmod structures are added 1. usb_host_hs The hwmod of usbhs with uhh, ehci and ohci base addresses functional clock and ehci, ohci irqs 2. usb_tll_hs hwmod of usbhs with the TLL base address and irq. Signed-off-by: Benoit Cousson <b-cousson@ti.com> [keshava_mgowda@ti.com: rebased to kernel version 3.0, added workarounds for hardware issues] Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com> Reviewed-by: Partha Basak <parthab@india.ti.com> [paul@pwsan.com: fixed multi-line comments, fixed whitespace, fixed S-o-b notes, removed spurious TLL->L3 interface] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3Keshava Munegowda
Following 2 hwmod structures are added 1. usb_host_hs The hwmod of usbhs with uhh, ehci and ohci base addresses functional clock and ehci, ohci irqs 2. usb_tll_hs hwmod of usbhs with the TLL base address and irq. Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com> Reviewed-by: Partha Basak <parthab@india.ti.com> [paul@pwsan.com: fixed whitespace; removed nonexistent TLL->L3 interface; added master & slave for L4 CORE->TLL interface; skip registration on 3430ES1; fixed multiline comment style; updated to apply on Tony's cleanup branch; rebased] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-15ARM: OMAP: hwmod data: Add support for AM35xx UART4/ttyO3Kyle Manna
Add hwmod support to enable access to UART4 of the AM35xx series of chips. The UART4 device referenced from the TRM will show up as ttyO3. This was tested on an AM3505. Signed-off-by: Kyle Manna <kyle.manna@fuel7.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-15ARM: OMAP: hwmod data: fix the panic on Nokia RM-680 during bootAaro Koskinen
Booting the Linux kernel on Nokia RM-680 board has been broken since 2.6.39 due to the following: [ 0.217193] omap_hwmod: timer12: enabling [ 0.221435] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa304010 [ 0.229431] Internal error: : 1028 [#1] SMP [ 0.233825] Modules linked in: [ 0.237060] CPU: 0 Not tainted (3.2.0-rc4-dirty #46) [ 0.242645] PC is at _update_sysc_cache+0x2c/0x7c [ 0.247589] LR is at _enable+0x1b0/0x2d8 [ 0.251708] pc : [<c0026108>] lr : [<c0026df4>] psr: 40000013 [ 0.251708] sp : ef831f40 ip : ef82f380 fp : c06ac0c0 [ 0.263702] r10: 00000000 r9 : c05dfb2c r8 : ef830000 [ 0.269165] r7 : c0027494 r6 : 00000000 r5 : 00000000 r4 : c06608b0 [ 0.276000] r3 : fa304000 r2 : 00000010 r1 : c0661e28 r0 : c06608b0 [ 0.282806] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 0.290405] Control: 10c5387d Table: 80004019 DAC: 00000017 [ 0.296417] Process swapper (pid: 1, stack limit = 0xef8302f8) [ 0.302520] Stack: (0xef831f40 to 0xef832000) [ 0.307098] 1f40: c06608b0 c0026df4 c06ad094 c0035120 00000001 c06608b0 00000000 c0027530 [ 0.315612] 1f60: c0027604 ef830000 c05dfb2c c06608b0 c0642ac0 c0025bf0 c0621234 c062120c [ 0.324127] 1f80: c0621738 00000013 ef830000 c05dfb6c c0621234 c0008688 c062c880 c009eadc [ 0.332641] 1fa0: 0000005f 00000000 c0621738 35390013 00000000 00000000 00000000 0000019a [ 0.341156] 1fc0: c0681cf4 c0621234 c062120c c0621738 00000013 00000000 00000000 00000000 [ 0.349670] 1fe0: 00000000 c05d5298 00000000 c05d5200 c0014fa8 c0014fa8 ffff0000 ffff0000 [ 0.358184] [<c0026108>] (_update_sysc_cache+0x2c/0x7c) from [<c0026df4>] (_enable+0x1b0/0x2d8) [ 0.367248] [<c0026df4>] (_enable+0x1b0/0x2d8) from [<c0027530>] (_setup+0x9c/0x170) [ 0.375335] [<c0027530>] (_setup+0x9c/0x170) from [<c0025bf0>] (omap_hwmod_for_each+0x38/0x58) [ 0.384307] [<c0025bf0>] (omap_hwmod_for_each+0x38/0x58) from [<c05dfb6c>] (omap_hwmod_setup_all+0x40/0xa0) [ 0.394409] [<c05dfb6c>] (omap_hwmod_setup_all+0x40/0xa0) from [<c0008688>] (do_one_initcall+0x34/0x180) [ 0.404296] [<c0008688>] (do_one_initcall+0x34/0x180) from [<c05d5298>] (kernel_init+0x98/0x144) [ 0.413452] [<c05d5298>] (kernel_init+0x98/0x144) from [<c0014fa8>] (kernel_thread_exit+0x0/0x8) [ 0.422576] Code: e3130c01 1590304c 0590304c 119320b2 (07932002) [ 0.429046] ---[ end trace 1b75b31a2719ed1c ]--- [ 0.433959] Kernel panic - not syncing: Attempted to kill init! Timer 12 is not necessarily available on non-GP devices (see e.g. http://marc.info/?l=linux-omap&m=129433066521102&w=2), so it should be registered only on GP OMAPs. With this change it's again possible to boot RM-680 into the shell. Tested with 3.2-rc4. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> [paul@pwsan.com: changed subject line] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-15ARM: OMAP: hwmod data: fix iva and mailbox hwmods for OMAP 3Felipe Contreras
Seems the commit 7e89098 was overly aggressive in adding iva and mailbox hwmods so now they are registered twice. ------------[ cut here ]------------ WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959 omap_hwmod_register+0x104/0x12c() omap_hwmod: iva: _register returned -22 Modules linked in: [<c0012aa4>] (unwind_backtrace+0x0/0xec) from [<c002f970>] (warn_slowpath_common+0x4c/0x64) [<c002f970>] (warn_slowpath_common+0x4c/0x64) from [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) from [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) from [<c02fbb44>] (omap3_init_early+0x1c/0x28) [<c02fbb44>] (omap3_init_early+0x1c/0x28) from [<c02f9580>] (setup_arch+0x6b8/0x7a4) [<c02f9580>] (setup_arch+0x6b8/0x7a4) from [<c02f754c>] (start_kernel+0x6c/0x264) [<c02f754c>] (start_kernel+0x6c/0x264) from [<80008040>] (0x80008040) ---[ end trace 1b75b31a2719ed1c ]--- ------------[ cut here ]------------ WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959 omap_hwmod_register+0x104/0x12c() omap_hwmod: mailbox: _register returned -22 Modules linked in: [<c0012aa4>] (unwind_backtrace+0x0/0xec) from [<c002f970>] (warn_slowpath_common+0x4c/0x64) [<c002f970>] (warn_slowpath_common+0x4c/0x64) from [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) from [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) from [<c02fbb44>] (omap3_init_early+0x1c/0x28) [<c02fbb44>] (omap3_init_early+0x1c/0x28) from [<c02f9580>] (setup_arch+0x6b8/0x7a4) [<c02f9580>] (setup_arch+0x6b8/0x7a4) from [<c02f754c>] (start_kernel+0x6c/0x264) [<c02f754c>] (start_kernel+0x6c/0x264) from [<80008040>] (0x80008040) ---[ end trace 1b75b31a2719ed1d ]--- Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-14ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qosGovindraj.R
Omap_uart_can_sleep function blocks system wide low power state until uart is active remove this func and add qos requests to prevent MPU from transitioning. Keep qos request to default value which will allow MPU to transition and while uart baud rate is available calculate the latency value from the baudrate and use the same to hold constraint while uart clocks are enabled, and if uart is auto-idled the constraint is updated with default constraint value allowing MPU to transition. Qos requests are blocking notifier calls so put these requests to work queue, also the driver uses irq_safe version of runtime API's and callbacks can be called in interrupt disabled context. So to avoid warn on slow path warning while using qos update API's from runtime callbacks use the qos_work_queue. During bootup the runtime_resume call backs might not be called and runtime callback gets called only after uart is idled by setting the autosuspend timeout. So qos_request from runtime resume callback might not activated during boot if uart baudrate is calculated during bootup for console uart, so schedule the qos_work queue once we calc_latency while configuring the uart port. Flush and complete any pending qos jobs in work queue while suspending. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-14ARM: OMAP2+: UART: Do not gate uart clocks if used for debug_printsGovindraj.R
If OMAP UART is used as console uart and debug is enabled, avoid gating of uart clocks to print all debug prints. If uart clocks are gated then the debug prints from omap_device framework or hwmod framework can cause uart to enter recursive pm_runtime calls, which can cause a deadlock over power lock usage. For example: Say, uart clocks are cut and we get a print from omap_device_disable stating disabling uart clocks. This print calls omap_uart driver console_write which will call runtime API get_sync which means we enter from runtime API put context to runtime API get context. --> runtime put (take power lock) --> print disabling uart clocks --> call uart console write --> call get_sync (try to take power lock) Also any clock enable API call from uart driver should not call any uart operation until clocks are enabled back. Like get_sync having debug print calling uart console write even before clocks are enabled. So to avoid these scenarios, identify from bootargs if OMAP_UART(ttyO) is used in debug mode. If so, do not set device_may_wakeup. This will prevent pm_runtime_enable in uart driver and will avoid uart clock gating. Debug is enabled either by adding debug word in bootarg or by setting loglevel=10 Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-14ARM: OMAP2+: UART: Avoid uart idling on suspend for no_console_suspend usecaseGovindraj.R
If no_console_suspend is used we have prevent uart idling during suspend to provide debug prints. Power domain hooks can idle uarts if left enabled during system wide suspend so re-use the omap_device_disable_idle_on_suspend API's to ensure console_uart is not idled during suspend. omap_device_disable_idle_on_suspend API was used on all uarts since the uart driver was not runtime adapted, now with runtime adaptation we can re-use this API only for no_console_suspend use cases. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-14ARM: OMAP2+: UART: Avoid console uart idling during bootupGovindraj.R
Omap-uart can be used as console uart to print early boot messages using earlyprintk so for console uart prevent hwmod reset or idling during bootup. Identify omap-uart used as console and avoid idling rather than preventing all omap-uarts from idling during bootup. Update the comments for the same. Remove the uart idling and enabling back using hwmod_idle/omap_device_enable for all uarts that where left enabled from boot to set the hwmod framework state machine right. This need not be taken care any more serial.c rather can be handled within the hwmod framework. Reference: http://www.spinics.net/lists/linux-omap/msg60300.html Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-14ARM: OMAP2+: UART: remove temporary variable used to count uart instanceGovindraj.R
Reuse the num_uarts variable itself to count number of uarts. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-14ARM: OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UARTJon Hunter
When using DMA there are two timeouts defined. The first timeout, rx_timeout, is really a polling rate in which software polls the DMA status to see if the DMA has finished. This is necessary for the RX side because we do not know how much data we will receive. The secound timeout, RX_TIMEOUT, is a timeout after which the DMA will be stopped if no more data is received. To make this clearer, rename rx_timeout as rx_poll_rate and rename the function serial_omap_rx_timeout() to serial_omap_rxdma_poll(). The OMAP-Serial driver defines an RX_TIMEOUT of 3 seconds that is used to indicate when the DMA for UART can be stopped if no more data is received. The value is a global definition that is applied to all instances of the UART. Each UART may be used for a different purpose and so the timeout required may differ. Make this value configurable for each UART so that this value can be optimised for power savings. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-14ARM: OMAP2+: UART: Allow UART parameters to be configured from board file.Deepak K
The following UART parameters are defined within the UART driver: 1). Whether the UART uses DMA (dma_enabled), by default set to 0 2). The size of dma buffer (set to 4096 bytes) 3). The time after which the dma should stop if no more data is received. 4). The auto suspend delay that will be passed for pm_runtime_autosuspend where uart will be disabled after timeout Different UARTs may be used for different purpose such as the console, for interfacing bluetooth chip, for interfacing to a modem chip, etc. Therefore, it is necessary to be able to customize the above settings for a given board on a per UART basis. This change allows these parameters to be configured from the board file and allows the parameters to be configured for each UART independently. If a board does not define its own custom parameters for the UARTs, then use the default parameters in the structure "omap_serial_default_info". The default parameters are defined to be the same as the current settings in the UART driver to avoid breaking the UART for any cuurnelty supported boards. By default, make all boards use the default UART parameters. Signed-off-by: Deepak K <deepak.k@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-14ARM: OMAP2+: UART: Remove old and unused clocks handling funcsGovindraj.R
With runtime adaptation done remove clock_enable/disbale API's Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-14ARM: OMAP2+: UART: Add wakeup mechanism for omap-uartsGovindraj.R
From the runtime callbacks enable hwmod wakeups for uart which will internally enable io-pad wakeups for uarts if they have rx-pad pins set as wakeup capabale. Use the io-ring wakeup mechanism after uart clock gating and leave the PM_WKST set for uart to default reset values cleanup the code in serial.c which was handling PM_WKST reg. Irq_chaing(PRM_DRIVER) is used to wakeup uart after uart clocks are gated using pad wakeup mechanism. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: Kevin Hilman <khilman@ti.com>