GitHub/MotorolaMobilityLLC/kernel-slsi.git
14 years agoOMAP: mach-omap2: Fix static declaration warnings
Manjunath Kondaiah G [Fri, 8 Oct 2010 16:56:37 +0000 (09:56 -0700)]
OMAP: mach-omap2: Fix static declaration warnings

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>
14 years agoOMAP: mach-omap2: Fix incorrect assignment warnings
Manjunath Kondaiah G [Fri, 8 Oct 2010 16:56:11 +0000 (09:56 -0700)]
OMAP: mach-omap2: Fix incorrect assignment warnings

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>
14 years agoomap: Keep nwires for omap1 and 2420 MMC controller
Tony Lindgren [Mon, 4 Oct 2010 23:58:01 +0000 (16:58 -0700)]
omap: Keep nwires for omap1 and 2420 MMC controller

A patch from Sukumar Ghorai <s-ghorai@ti.com> changed the
nwires to use caps instead. However, nwires is still
needed for the earlier controller.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Sukumar Ghorai <s-ghorai@ti.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
14 years agoOMAP2+: defconfig: disable CPUfreq
Kevin Hilman [Tue, 28 Sep 2010 19:07:28 +0000 (19:07 +0000)]
OMAP2+: defconfig: disable CPUfreq

Disable CPUfreq since

1) is not yet supported in mainline, and
2) the current driver fails to suspend properly

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoOMAP2+: defconfig: modularize bluetooth, audio and WLAN
Kevin Hilman [Tue, 28 Sep 2010 19:07:29 +0000 (19:07 +0000)]
OMAP2+: defconfig: modularize bluetooth, audio and WLAN

In working towards a smaller default kernel, only devices used for
early boot should be built in.  Toward that end, build the following
as modules by default:

- bluetooth
- audio: ALSA, ASoC
- WLAN

Uncompressed kernel size comparison:

Before:
   text    data     bss     dec     hex filename
6557576  465088 5616024 12638688  c0d9e0 vmlinux

After:
   text    data     bss     dec     hex filename
5616572  436448 5610800 11663820  b1f9cc vmlinux

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoARM: OMAP3LOGIC: Added SMSC Ethernet board support
Tim Nordell [Mon, 27 Sep 2010 16:05:50 +0000 (16:05 +0000)]
ARM: OMAP3LOGIC: Added SMSC Ethernet board support

Enable SMSC911x Ethernet driver for LogicPD's OMAP
3530 LV SOM and OMAP 35x Torpedo board.

Signed-off-by: Tim Nordell <tim.nordell@logicpd.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoARM: OMAP3LOGIC: Add generic smsc911x support when connected to GPMC
Tim Nordell [Mon, 27 Sep 2010 16:05:49 +0000 (16:05 +0000)]
ARM: OMAP3LOGIC: Add generic smsc911x support when connected to GPMC

Introduce of a generic way to setup smsc911x based Ethernet
controller connected to GPMC similar to gpmc-smc91x but without
timing setup.

Signed-off-by: Tim Nordell <tim.nordell@logicpd.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoARM: OMAP3LOGIC: Adding SDMMC support
Tim Nordell [Mon, 27 Sep 2010 16:05:48 +0000 (16:05 +0000)]
ARM: OMAP3LOGIC: Adding SDMMC support

Add low-level initialization for hsmmc controller for
LogicPD's OMAP 3530 LV SOM and OMAP 35x Torpedo board.

Signed-off-by: Tim Nordell <tim.nordell@logicpd.com>
[tony@atomide.com: updated for the recent mmc platform init changes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoARM: OMAP3LOGIC: Adding LogicPD OMAP3 board support
Tim Nordell [Mon, 27 Sep 2010 16:05:47 +0000 (16:05 +0000)]
ARM: OMAP3LOGIC: Adding LogicPD OMAP3 board support

Adding support for LogicPD's OMAP 3530 LV SOM and
OMAP 35x Torpedo board.

Signed-off-by: Tim Nordell <tim.nordell@logicpd.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoarm: remove cast from void*
matt mooney [Tue, 28 Sep 2010 02:04:32 +0000 (19:04 -0700)]
arm: remove cast from void*

Unnecessary cast from void* in assignment.

Signed-off-by: matt mooney <mfm@muteddisk.com>
Acked-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap3: cm-t3517: add support for TI HECC
Igor Grinberg [Tue, 21 Sep 2010 16:03:13 +0000 (16:03 +0000)]
omap3: cm-t3517: add support for TI HECC

add support for TI HECC.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap3: cm-t3517: add support for NAND flash
Igor Grinberg [Tue, 21 Sep 2010 16:03:12 +0000 (16:03 +0000)]
omap3: cm-t3517: add support for NAND flash

add support for NAND flash.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap3: cm-t3517: add support for usb host
Igor Grinberg [Tue, 21 Sep 2010 16:03:11 +0000 (16:03 +0000)]
omap3: cm-t3517: add support for usb host

add support for hsusb host ports 1, 2 and on-module usb hub.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap3: cm-t3517: add support for v3020 rtc
Igor Grinberg [Tue, 21 Sep 2010 16:03:10 +0000 (16:03 +0000)]
omap3: cm-t3517: add support for v3020 rtc

add support for v3020 rtc.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap3: Introduce CompuLab CM-T3517 module
Igor Grinberg [Tue, 21 Sep 2010 16:03:09 +0000 (16:03 +0000)]
omap3: Introduce CompuLab CM-T3517 module

Add basic suppot, enable uart and led.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoMerge branch 'omap4_and_sdrc_2.6.27' of git://git.pwsan.com/linux-2.6 into omap-for...
Tony Lindgren [Mon, 27 Sep 2010 20:17:13 +0000 (13:17 -0700)]
Merge branch 'omap4_and_sdrc_2.6.27' of git://git.pwsan.com/linux-2.6 into omap-for-linus

14 years agoomap3: Prevent SDRC deadlock when L3 is changing frequency
Jon Hunter [Mon, 27 Sep 2010 20:02:59 +0000 (14:02 -0600)]
omap3: Prevent SDRC deadlock when L3 is changing frequency

When changing the L3 clock frequency, the CPU is executing from internal RAM
and the SDRC clock is disabled. During this time accesses made to external
DDR are stalled. If the ARM subsystem attempts to access the DDR while the
SDRC clock is disabled this will stall the CPU until the access to the SDRC
timeouts. A timeout on the SDRC should never occur. Once a timeout occurs all
the following accesses will be aborted and the DDR is no longer accessible.

Although the code being executed in the internal RAM does not directly access
the DDR, it was found that the branch prediction logic in the CPU may cause
the CPU to prefetch code from a DDR location while the SDRC clock is disabled.
This was causing an SDRC timeout which resulted in a system hang.

This patch fixes this problem by ensuring the branch prediction logic is
disabled while changing the L3 clock frequency. The branch prediction logic
is disabled by clearing the Z-bit in the ARM CTRL register.

Disabling the branch prediction logic does not have any noticable impact
on the execution time of this code section. The hardware observability
signals were used to monitor the sdrc idle time with and without this
patch when operating at different CPU frequencies (150MHz, 500MHz and
600MHz) and the total sdrc idle time when changing frequenct was in
the range of 9-11us. This was measured on an omap3430 SDP running the
omapzoom p-android-omap-2.6.29 branch.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
14 years agoomap4: control: Fix the control module register accesses
Santosh Shilimkar [Mon, 27 Sep 2010 20:02:58 +0000 (14:02 -0600)]
omap4: control: Fix the control module register accesses

This patch has multiple fixes together. To ensure that git bisect work across
commits, all changes are clubbed together

1. Move the common control base address to control core
2. Remove the manually coeded defines and use the ones from headers.
3. Fix the the status register define in id.c for OMAP4
4. Fix all the register define in hsmmc.c
5. Use the control pad accessor API for omap4 hsmmc register accesses

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>
14 years agoomap4: control: Add the register definition headers
Santosh Shilimkar [Mon, 27 Sep 2010 20:02:58 +0000 (14:02 -0600)]
omap4: control: Add the register definition headers

On OMAP4, control module is divided into 4 separate IPs
- OMAP44XX_CTRL_MODULE_CORE
- OMAP44XX_CTRL_MODULE_PAD_CORE
- OMAP44XX_CTRL_MODULE_WKUP
- OMAP44XX_CTRL_MODULE_PAD_WKUP

This patch adds all the omap4 control module register data and
includes them in the common control.h

The register data is autogenerated from the codebase thanks
to Benoit Cousson efforts

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>
14 years agoomap4: control: Add accessor api's for pad control module
Santosh Shilimkar [Mon, 27 Sep 2010 20:02:57 +0000 (14:02 -0600)]
omap4: control: Add accessor api's for pad control module

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>
14 years agoomap4: control: Add ctrl_pad_base to omap_globals
Santosh Shilimkar [Mon, 27 Sep 2010 20:02:57 +0000 (14:02 -0600)]
omap4: control: Add ctrl_pad_base to omap_globals

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>
14 years agoOMAP4: clocks: Fix ES2 clock issues
Benoit Cousson [Mon, 27 Sep 2010 20:02:56 +0000 (14:02 -0600)]
OMAP4: clocks: Fix ES2 clock issues

Fix a few OMAP4430 clock tree problems after the recent manual merge of the
various ES2 clock patches:

- usim optional clock and its parent had the same name, rename the parent
usim_fclk -> usim_ck

- OPTFCLKEN_CLK32K is not handled anymore by the USBPHYOCP2SCP module in ES2
Create a new clock that belongs to CM_ALWON_USBPHY_CLKCTRL register

This patch depends on some of the PRCM macro updates from Rajendra.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: tweaked patch description]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
14 years agoOMAP4: powerdomain: Update DSS logic state for ES2
Rajendra Nayak [Mon, 27 Sep 2010 20:02:56 +0000 (14:02 -0600)]
OMAP4: powerdomain: Update DSS logic state for ES2

DSS on ES2 supports only OSWR, hence remove the support
for CSWR from the powerdomain framework.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP4: PM: Define additional registers for ES2
Rajendra Nayak [Mon, 27 Sep 2010 20:02:56 +0000 (14:02 -0600)]
OMAP4: PM: Define additional registers for ES2

4430 ES2 has a few new registers added and a few modified
from ES1. This patch adds all the register changes in PRM
and CM for OMAP4430 ES2.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP4: CM & PRM: Update PRCM register bitshifts and masks for ES2
Rajendra Nayak [Mon, 27 Sep 2010 20:02:55 +0000 (14:02 -0600)]
OMAP4: CM & PRM: Update PRCM register bitshifts and masks for ES2

This patch updates the PRM and CM register bitshifts and masks
for OMAP4430 ES2.0.

Replace as well the BITFIELD macro with the shift operator in order
to be consistent with the previous OMAP2 & 3 format.

Sort the register list in comments in order to have a consistent
register order and avoid futur change during code generation.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP4: clock: Add optional clock nodes
Benoit Cousson [Mon, 27 Sep 2010 20:02:55 +0000 (14:02 -0600)]
OMAP4: clock: Add optional clock nodes

OMAP4 IP optional clocks require explicit enable in module CTRLCLK
register. In order to allow that we have to create artificial clock
nodes that represent this clock inputs in the IP.

Notes:
- Temporary use OMAP3 names for GPIO optional clocks until the GPIO hwmod
convertion is done. It will enforce the usage of OMAP4 names as the reference.
- Temporary use OMAP3 names for TIMER main clock (gptX_fck) until TIMER hwmod
convertion is done. During that convertion, the new name will have to be used.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
14 years agoOMAP4: clock: Fix clock names and align with hwmod names
Benoit Cousson [Mon, 27 Sep 2010 20:02:54 +0000 (14:02 -0600)]
OMAP4: clock: Fix clock names and align with hwmod names

The OMAP4 hwmod data introduced the new naming convention for TI
IPs (See patch OMAP4: hwmod: Add partial hwmod support for OMAP4430 ES1.0)

The leaf clock names are using the same IP name and thus must be
modified to match the clock populated in the hwmod data.

- Fix some leaf clocks nodes that were using a _iclk instead of the _fclk
prefix.
- Fix some wrong interface clock name for master IPs connected to
interconnect.

Please not that due to the fact that nodes are sorted by name, the name
change will introduce a quite ugly diff a little bit hard to follow.

Timers clock con_id is still using the old gptX_fck name until the
gptimer driver is updated to omap_device framework.
Timers entries in hwmods DB are still disabled until the migration
if timer to platform_driver + omap_hwmod.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: manually resolved conflicts with Rajendra's clock patch]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
14 years agoOMAP4: clocks: Update clock tree for ES2
Rajendra Nayak [Mon, 27 Sep 2010 20:02:54 +0000 (14:02 -0600)]
OMAP4: clocks: Update clock tree for ES2

This patch updates the clock tree with all the
changes in OMAP4430 ES2.

clock nodes added
-1- tie_low_clock_ck
-2- abe_dpll_bypass_clk_mux_ck

clock nodes deleted
-1- dpll_sys_ref_clk
-2- per_sgx_fclk
-3- usbphyocp2scp_ick

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
[paul@pwsan.com: added comment re ES1 clocks to top of file]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoupdate OMAP Kconfig help texts for all supported SoC models
Lennert Buytenhek [Wed, 22 Sep 2010 18:40:57 +0000 (20:40 +0200)]
update OMAP Kconfig help texts for all supported SoC models

update OMAP Kconfig help texts for all supported SoC models

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoMerge branch 'devel-omap-smp-on-up' into omap-for-linus
Tony Lindgren [Mon, 27 Sep 2010 17:22:16 +0000 (10:22 -0700)]
Merge branch 'devel-omap-smp-on-up' into omap-for-linus

14 years agoMerge branch 'devel-boards' into omap-for-linus
Tony Lindgren [Mon, 27 Sep 2010 17:19:44 +0000 (10:19 -0700)]
Merge branch 'devel-boards' into omap-for-linus

14 years agoMerge branch 'misc_2.6.37' of git://git.pwsan.com/linux-2.6 into omap-for-linus
Tony Lindgren [Mon, 27 Sep 2010 17:18:00 +0000 (10:18 -0700)]
Merge branch 'misc_2.6.37' of git://git.pwsan.com/linux-2.6 into omap-for-linus

14 years agoMerge branch 'devel-omap-misc' into omap-for-linus
Tony Lindgren [Mon, 27 Sep 2010 17:15:47 +0000 (10:15 -0700)]
Merge branch 'devel-omap-misc' into omap-for-linus

14 years agoomap: mmc: extended to pass host capabilities from board file
Sukumar Ghorai [Wed, 15 Sep 2010 14:49:23 +0000 (14:49 +0000)]
omap: mmc: extended to pass host capabilities from board file

wires variable is renamed, extended and this single variable to be used to
pass the platform capabilities, e.g DDR mode. Also removed the hardcoded
value was using as bus-width.

Signed-off-by: Sukumar Ghorai <s-ghorai@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap2: McBSP: Remove mux code for OMAP2420 McBSP2 and do cleanups
Jarkko Nikula [Tue, 31 Aug 2010 10:12:56 +0000 (10:12 +0000)]
omap2: McBSP: Remove mux code for OMAP2420 McBSP2 and do cleanups

This 'legacy' OMAP2420 McBSP2 muxing code is currently broken after recent
conversion to new mux code. The omap_mcbsp_request calling this code is
usually called after booting whereas the omap_mux_init_signal is __init
marked so null pointer dereference would occur.

Fix this by removing the muxing code and let the bootloader or board file to
do it if necessary. Remove also omap2_mcbsp_ops as there is no use for it.

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: McBSP: Do not enable SRG in slave mode
Peter Ujfalusi [Tue, 31 Aug 2010 08:11:44 +0000 (08:11 +0000)]
omap: McBSP: Do not enable SRG in slave mode

McBSP SRG (Sample Rate Generator) and FSG (Frame Sync
Generator) is only needed to be enabled, when McBSP
is master.
In McBSP slave mode, the SRG, and FSG can be kept disabled,
which might save some power at the end in this configuration.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: i2c: Avoid compilation error in case the header is included multiple times
Subramaniam C.A [Tue, 24 Aug 2010 17:02:28 +0000 (12:02 -0500)]
omap: i2c: Avoid compilation error in case the header is included multiple times

Added defines to avoid compilation error.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: crypto: updates to enable omap aes
Dmitry Kasatkin [Fri, 20 Aug 2010 13:44:46 +0000 (13:44 +0000)]
omap: crypto: updates to enable omap aes

Updates to enable omap aes

Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com>
[tony@atomide.com: updated to use CONFIG_ARCH_OMAP2/3 instead of old 24XX/34XX]
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: usb: fix build warning
Anand Gadiyar [Thu, 16 Sep 2010 23:22:13 +0000 (16:22 -0700)]
omap: usb: fix build warning

Fix this and similar build warnings when building with
omap_4430sdp_defconfig.

 CC      arch/arm/mach-omap2/board-4430sdp.o
In file included from arch/arm/mach-omap2/board-4430sdp.c:36:
arch/arm/plat-omap/include/plat/usb.h:109: warning: return type defaults to 'int'

Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap4: board-omap4panda: adding leds status1 and status2
Ricardo Salveti de Araujo [Fri, 24 Sep 2010 01:22:49 +0000 (18:22 -0700)]
omap4: board-omap4panda: adding leds status1 and status2

At Pandaboard we have 2 status leds, so adding them with similar usage as
we have for Beagleboard (heartbeat and mmc0). The patch basically adds the
platform data required by leds-gpio driver.

Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: 4430sdp board support for proximity sensor
Shubhrajyoti Datta [Fri, 24 Sep 2010 01:22:49 +0000 (18:22 -0700)]
omap: 4430sdp board support for proximity sensor

omap 4430sdp board support for the  proximity sensor via GPIO keys.
The proximity sensor is connected to GPIO and is registered as a
GPIO key.
- Making the default state of the sensor off at bootup
- The init is called before platform_add_devices

Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoMerge branch 'omap_for_2.6.37' of git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4...
Tony Lindgren [Fri, 24 Sep 2010 23:01:57 +0000 (16:01 -0700)]
Merge branch 'omap_for_2.6.37' of git://dev.omapzoom.org/santosh/kernel-omap4-base into omap-for-linus

14 years agoOMAP: hwmod: Set autoidle after smartidle during _sysc_enable
Hema HK [Fri, 24 Sep 2010 16:23:19 +0000 (10:23 -0600)]
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable

OMAP USBOTG module has a requirement to set the autoidle bit only after
setting smartidle bit. Modified the _sys_enable api to set the smartidle
first and then the autoidle bit. Setting this will not have any impact on the
other modules.

Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Partha Basak <p-basak2@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
14 years agoOMAP4: PM: Declare idle modules as functional too
Rajendra Nayak [Fri, 24 Sep 2010 16:23:18 +0000 (10:23 -0600)]
OMAP4: PM: Declare idle modules as functional too

The omap4_cm_wait_module_ready function would only check for
the modules to be completely functional before declaring them
ready to be accessed.
There might also be instances where in the module is actually
in idle (under h/w control) but should still be declared
accessible, as the h/w control would make it functional when
needed.

Hence make omap4_cm_wait_module_ready return true in case
the module is fully functional *or* in idle state.
Fail only if the module is fully disabled or stuck intransition.

The explaination from the TRM for the idlest bits on OMAP4 is as
below for quick reference

Module idle state:
0x0 func:     Module is fully functional, including OCP
0x1 trans:    Module is performing transition: wakeup, or sleep, or sleep
              abortion
0x2 idle:     Module is in Idle mode (only OCP part). It is functional if
              using separate functional clock
0x3 disabled: Module is disabled and cannot be accessed

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Partha Basak <p-basak2@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
14 years agoOMAP: omap_device: Fix to support multiple hwmods for a single device
Kishon Vijay Abraham I [Fri, 24 Sep 2010 16:23:18 +0000 (10:23 -0600)]
OMAP: omap_device: Fix to support multiple hwmods for a single device

Currently there is a bug in the existing omap_device core code when
extracting the hwmod structures passed to omap_device_build_ss(). This bug
gets exposed only when passing multiple hwmod structures to
omap_device_build_ss() resulting in incorrect extraction from second hwmod
structure.

This fix uses the pointer to pointer to omap_hwmod structure (array of
pointers to omap_hwmod structure) passed to omap_device_build_ss() to
correctly extract the appropriate omap_hwmod structure.

This patch has been created and tested on lo/master and mainline.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Charulatha V <charu@ti.com>
Cc: Shubhrajyoti D <shubhrajyoti@ti.com>
14 years agoomap4: Fix bootup crash observed with higher CPU clocks
Santosh Shilimkar [Thu, 16 Sep 2010 13:14:48 +0000 (18:44 +0530)]
omap4: Fix bootup crash observed with higher CPU clocks

This patch is temporary fix to below crash. This is observed when
CPU is clocked more than 600 MHz.

Unhandled fault: imprecise external abort (0x1406) at 0xbf9ef65c
Internal error: : 1406 [#1] PREEMPT SMP
last sysfs file:
Modules linked in:
CPU: 0    Not tainted  (2.6.36-rc3+ #18)
PC is at kernel_thread_helper+0x0/0x14
LR is at kernel_thread_helper+0x0/0x14
pc : [<c003ce14>]    lr : [<c003ce14>]    psr: 00000093
sp : dc83bff8  ip : 00000000  fp : 00000000
r10: 00000000  r9 : 00000000  r8 : 00000000
r7 : 00000013  r6 : c003ce28  r5 : c008935c  r4 : 00000000
r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000
Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7f  Table: 8000404a  DAC: 00000017
Process swapper (pid: 2, stack limit = 0xdc83a2f0)
Stack: (0xdc83bff8 to 0xdc83c000)
bfe0: 00000000 ffffffff
[<c003ce14>] (kernel_thread_helper+0x0/0x14) from [<fffffffe>] (0xfffffffe)
Code: c03a0ba3 c03a5fcb c045c880 c0394035 (eb017701)
---[ end trace 1b75b31a2719ed1c ]---

The timer hwmod adaptation will eventually fix it in a proper way.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
14 years agoomap4: Panda: Add DEBUG_LL support
David Anders [Thu, 16 Sep 2010 13:14:47 +0000 (18:44 +0530)]
omap4: Panda: Add DEBUG_LL support

Add support for use of DEBUG_LL for use with PandaBoard.

Signed-off-by: David Anders <x0132446@ti.com>
14 years agoomap4: l2x0: Fix init parameter for es2.0
Santosh Shilimkar [Thu, 16 Sep 2010 13:14:47 +0000 (18:44 +0530)]
omap4: l2x0: Fix init parameter for es2.0

On ES2.0 the L2 cache init parameter ineeds to be changed to take
care of cache size. The cache size is 1MB on ES2.0 vs 512KB on ES1.0

This patch fixes the init parameter to update the same using
dynamic cpu version check

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
14 years agoomap4: Update id.c and cpu.h for es2.0
Santosh Shilimkar [Thu, 16 Sep 2010 13:14:46 +0000 (18:44 +0530)]
omap4: Update id.c and cpu.h for es2.0

This patch updates the id.c and cpu.h files to support
omap4 ES2.0 silicon detection. Few initial omap4 es2 samples
IDCODE is same as es1. So the patch uses ARM cpuid register to
detect the ES version for such samples

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
14 years agoomap4: sram: Fix start address
Vikram Pandita [Thu, 16 Sep 2010 12:49:25 +0000 (18:19 +0530)]
omap4: sram: Fix start address

On OMAP4 there is no need to have SRAM_BOOTLOADER_SZ provision

Hence put this macro under CONFIG_ARCH_OMAP2PLUS check

Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
14 years agoomap: sram: fix is_sram_locked check
Vikram Pandita [Thu, 16 Sep 2010 12:49:24 +0000 (18:19 +0530)]
omap: sram: fix is_sram_locked check

For OMAP24xx/34xx/44xx: omap_type() returns the correct type:
 OMAP2_DEVICE_TYPE_TEST
 OMAP2_DEVICE_TYPE_EMU
 OMAP2_DEVICE_TYPE_SEC
 OMAP2_DEVICE_TYPE_GP
 OMAP2_DEVICE_TYPE_BAD

In current implementation there are two problems:
Problem 1:
For 34xx, the current if check will never return true.

Problem 2:
For 24xx the correct type check should be with omap_type() function
Verified by checking the TRM 24xx for CONTROL_STATUS register bits

Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
14 years agoomap: n8x0: Mux i2s codec port pins for McBSP block
Jarkko Nikula [Fri, 20 Aug 2010 06:36:28 +0000 (09:36 +0300)]
omap: n8x0: Mux i2s codec port pins for McBSP block

Bootloader on Nokia N800 and N810 muxes I2C codec port pins for EAC block.
As there is no driver and use for EAC, mux those pins for McBSP instead
since N810 ASoC drivers can use it.

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: n8x0: Register i2c2 and add board info with tlv320aic3xfor N810
Jarkko Nikula [Fri, 20 Aug 2010 06:36:28 +0000 (09:36 +0300)]
omap: n8x0: Register i2c2 and add board info with tlv320aic3xfor N810

Second i2c bus on Nokia N800 and N810 shares both common and hw specific
peripherals. Register now this bus and add board info with tlv320aic3x for
N810. Common peripherals may be added as an additional board info to
omap_register_i2c_bus(2, ...);

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: n8x0: Cleanup i2c1 and menelaus registration
Jarkko Nikula [Fri, 20 Aug 2010 06:36:28 +0000 (09:36 +0300)]
omap: n8x0: Cleanup i2c1 and menelaus registration

- Move n8x0_i2c_board_info_1 out from #ifdef CONFIG_MENELAUS block,
  register i2c1 in n8x0_init_machine and do a few clean-ups around these.
  Code looks better if board infos are grouped together
- Mark n8x0_i2c_board_info_1 and n8x0_menelaus_platform_data with __initdata

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap2: fix assorted compiler warnings
Sanjeev Premi [Fri, 24 Sep 2010 01:27:18 +0000 (18:27 -0700)]
omap2: fix assorted compiler warnings

This patch fixes these compiler warnings:

  CC      arch/arm/mach-omap2/mux.o
arch/arm/mach-omap2/mux.c: In function 'omap_mux_init_gpio':
arch/arm/mach-omap2/mux.c:90: warning: 'gpio_mux' may be used uninitial
ized in this function

  CC      arch/arm/plat-omap/gpio.o
arch/arm/plat-omap/gpio.c: In function 'omap2_gpio_resume_after_idle':
arch/arm/plat-omap/gpio.c:2152: warning: 'l' may be used uninitialized
in this function
arch/arm/plat-omap/gpio.c: In function 'omap2_gpio_prepare_for_idle':
arch/arm/plat-omap/gpio.c:2085: warning: 'l2' may be used uninitialized
in this function
arch/arm/plat-omap/gpio.c:2085: warning: 'l1' may be used uninitialized
in this function

  CC      arch/arm/mach-omap2/board-omap4panda.o
arch/arm/mach-omap2/board-omap4panda.c: In function 'omap4_panda_init':
arch/arm/mach-omap2/board-omap4panda.c:277: warning: unused variable 's
tatus'

Signed-off-by: Sanjeev Premi <premi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: Adding beagle i2c eeprom driver to read EDID
Mathieu J. Poirier [Fri, 24 Sep 2010 01:22:48 +0000 (18:22 -0700)]
omap: Adding beagle i2c eeprom driver to read EDID

Adding i2c eeprom driver to access monitor EDID binary information
from user space, something that is required by 'decode-edid' and
'parse-edid'.

BugLink: https://bugs.launchpad.net/bugs/608279
Signed-off-by: Mathieu Poirier <mathieu.poirier@canonical.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: Beagle: no gpio_wp pin connection on xM
Robert Nelson [Fri, 24 Sep 2010 01:22:48 +0000 (18:22 -0700)]
omap: Beagle: no gpio_wp pin connection on xM

The omap3630 based BeagleBoard xM uses a MicroSD card slot with
no write protection.

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: Beagle: only Cx boards use pin 23 for write protect
Robert Nelson [Fri, 24 Sep 2010 01:22:48 +0000 (18:22 -0700)]
omap: Beagle: only Cx boards use pin 23 for write protect

system_rev comes from u-boot and is a constant 0x20, so
Bx boards also fall in this 'if' and will get setup with the
wrong gpio_wp pin. Switch to using the Beagle revision routine
to correcly set pin 23 only for C1/2/3 and C4 Boards. Bx boards
will then use the correct default pin setting.

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoomap: Beagle: revision detection
Robert Nelson [Fri, 24 Sep 2010 01:22:47 +0000 (18:22 -0700)]
omap: Beagle: revision detection

Due to the omap3530 ES3.0 Silicon being used on both the
B5/B6 and C1/2/3 Beagle we can't use the cpu_is_omap34xx()
routines to differentiate the Beagle Boards.

However gpio pins 171,172,173 where setup for this prupose, so
lets use them.

Changes:
for older U-Boot's, use omap_mux_init_gpio()
keep Beagle Rev in board-omap3beagle.c
gpio_free on gpio request failure

Tested on Beagle Revisions: B5, C2, C4, and xMA

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agohmc5843: Digital compass board file
Shubhrajyoti Datta [Fri, 24 Sep 2010 01:22:47 +0000 (18:22 -0700)]
hmc5843: Digital compass board file

The  board file changes for the digital compass hmc5843.
The interface to the device is i2c.

Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoMerge branch 'pm-runtime' of ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman...
Tony Lindgren [Fri, 24 Sep 2010 00:29:36 +0000 (17:29 -0700)]
Merge branch 'pm-runtime' of ssh:///linux/kernel/git/khilman/linux-omap-pm into omap-for-linus

14 years agoMerge branch 'pm-next' of ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman...
Tony Lindgren [Fri, 24 Sep 2010 00:29:28 +0000 (17:29 -0700)]
Merge branch 'pm-next' of ssh:///linux/kernel/git/khilman/linux-omap-pm into omap-for-linus

14 years agoOMAP: GPIO: ensure debounce clocks are disabled during idle/suspend
Kevin Hilman [Wed, 22 Sep 2010 23:06:27 +0000 (16:06 -0700)]
OMAP: GPIO: ensure debounce clocks are disabled during idle/suspend

If a GPIO bank has more than one GPIO with debounce enabled, the
debounce clock will not be fully disabled before going to
idle/suspend.

In the idle path, we just do a single clk_disable() of the bank's
debounce clock.  If there are multiple debounce-enabled GPIOs in the
bank, that clocks usage count will be > 1, so the clk_disable() will
not actually disable the clock.

So the fix is to clk_disable() for every debounce-enabled GPIO in the
bank (and an equivalent clk_enable() of course.)

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP4: pm: Change l3_main to l3_main_1 during bus device init
Benoit Cousson [Thu, 5 Aug 2010 13:22:35 +0000 (15:22 +0200)]
OMAP4: pm: Change l3_main to l3_main_1 during bus device init

The OMAP4 L3 interconnect is split in 3 part for power saving reason.
Because of that there is no l3_main like on OMAP2 & 3 but 3 differentes
l3_main_X instances.

In the case of OMAP4, query only the l3_main_1 part. The clock and
voltage are shared across the 3 instances.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP4: hwmod: Add initial data for OMAP4430 ES1 & ES2
Benoit Cousson [Wed, 12 May 2010 15:54:36 +0000 (17:54 +0200)]
OMAP4: hwmod: Add initial data for OMAP4430 ES1 & ES2

The current version contains only the interconnects and the
mpu hwmods.
The remaining hwmods will be introduced by further patches on
top of this one.

- enable as well omap_hwmod.c build for OMAP4 Soc

Please not that this file uses the new naming convention for
naming HW IPs. This convention will be backported soon for previous
OMAP2 & 3 data files.

new name        trm name
-------------   -------------------
counter_32k     synctimer_32k
l3_main         l3
timerX          gptimerX / dmtimerX
mmcX            mmchsX / sdmmcX
dma_system      sdma
smartreflex_X   sr_X / sr?
usb_host_fs     usbfshost
usb_otg_hs      hsusbotg
usb_tll_hs      usbtllhs_config
wd_timerX       wdtimerX
ipu             cortexm3 / ducati
dsp             c6x / tesla
iva             ivahd / iva2.2
kbd             kbdocp / keyboard
mailbox         system_mailbox
mpu             cortexa9 / chiron

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP: omap_device: make all devices a child of a new parent device
Kevin Hilman [Mon, 23 Aug 2010 15:10:55 +0000 (08:10 -0700)]
OMAP: omap_device: make all devices a child of a new parent device

In order to help differentiate omap_devices from normal
platform_devices, make them all a parent of a new common parent
device.

Then, in order to determine if a platform_device is also an
omap_device, checking the parent is all that is needed.

Users of this feature are the runtime PM core for OMAP, where we need
to know if a device being passed in is an omap_device or not in order
to know whether to call the omap_device API with it.

In addition, all omap_devices will now show up under /sys/devices/omap
instead of /sys/devices/platform

Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoRevert "OMAP: omap_device: add omap_device_is_valid()"
Kevin Hilman [Mon, 23 Aug 2010 17:53:10 +0000 (10:53 -0700)]
Revert "OMAP: omap_device: add omap_device_is_valid()"

This reverts commit 0007122ad85cc36b1c18c0b59344093ca210d206.

The dereference method of checking for a valid omap_device when
wrapping a platform_device is rather unsafe and dangerous.

Instead, a better way of checking for a valid omap-device is
to use a common parent device for all omap_devices, then a check
can simply be made using the device parent.  The only user of this
API was the initial version of the runtime PM core for OMAP.  This
has now been switched to check device parent, so there are no more
users of this API.

Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP clockdomain: initialize clockdomain registers when the clockdomain layer starts
Paul Walmsley [Tue, 14 Sep 2010 21:56:53 +0000 (15:56 -0600)]
OMAP clockdomain: initialize clockdomain registers when the clockdomain layer starts

When the clockdomain layer initializes, place all clockdomains into
software-supervised mode, and clear all wakeup and sleep dependencies
immediately, rather than waiting for the PM code to do this later.
This fixes a major bug where critical sleep dependencies added by the
hwmod code are cleared during late PM init.

As a side benefit, the _init_{wk,sleep}dep_usecount() functions are no
longer needed, so remove them.

Kevin Hilman <khilman@deeprootsystems.com> did all the really hard work on
this, identifying the problem and finding the bug.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoomap: pm: Move set_pwrdm_state routine to common pm.c
Santosh Shilimkar [Tue, 14 Sep 2010 19:34:01 +0000 (01:04 +0530)]
omap: pm: Move set_pwrdm_state routine to common pm.c

The set_pwrdm_state() is needed on omap4 as well so move
this routine to common pm.c file so that it's available for omap3/4

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoomap: pm-debug: Enable wakeup_timer_milliseconds debugfs entry
Santosh Shilimkar [Tue, 14 Sep 2010 19:34:00 +0000 (01:04 +0530)]
omap: pm-debug: Enable wakeup_timer_milliseconds debugfs entry

Commit 8e2efde9 added milliseconds suspend wakeup time support but
same interface is not exported through debugfs

This patch enables the debugfs hook for wakeup_timer_milliseconds

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoomap: pm-debug: Move common debug code to pm-debug.c
Santosh Shilimkar [Tue, 14 Sep 2010 19:33:59 +0000 (01:03 +0530)]
omap: pm-debug: Move common debug code to pm-debug.c

This patch moves omap2_pm_wakeup_on_timer() and pm debug entries
form pm34xx.c to pm-debug.c and export it, so that it is available
to other OMAPs

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP4: pm.c extensions for OMAP4 support
Thara Gopinath [Wed, 1 Sep 2010 08:14:53 +0000 (13:44 +0530)]
OMAP4: pm.c extensions for OMAP4 support

OMAP4 has an iva device and a dsp devcice where as OMAP2/3
has only an iva device. In this file the iva device in the
system is registered under the name dsp_dev and the API
to retrieve the iva device is omap2_get_dsp_device.
This patch renames the dsp_dev to iva_dev, renames
omap2_get_dsp_device to omap2_get_iva_device,
registers dsp_dev for OMAP4 and adds a new API
omap4_get_dsp_device to retrieve the dep_dev.

Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP3: PM: move device-specific special cases from PM core into CPUidle
Kevin Hilman [Wed, 8 Sep 2010 23:37:42 +0000 (16:37 -0700)]
OMAP3: PM: move device-specific special cases from PM core into CPUidle

In an effort to simplify the core idle path, move any device-specific
special case handling from the core PM idle path into the CPUidle
pre-idle checking path.

This keeps the core, interrupts-disabled idle path streamlined and
independent of any device-specific handling, and also allows CPUidle
to do the checking only for certain C-states as needed.  This patch
has the device checks in place for all states with the CHECK_BM flag,
namely all states >= C2.

This patch was inspired by a similar patch written by Tero Kristo as
part of a larger series to add INACTIVE state support.

NOTE: This is a baby-step towards decoupling device idle (or system
idle) from CPU idle.  Eventually, CPUidle should only manage the CPU,
and device/system idle should be managed elsewhere.

Cc: Tero Kristo <tero.kristo@nokia.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoMerge branch 'hwmod_2.6.37' of git://git.pwsan.com/linux-2.6 into omap-for-linus
Tony Lindgren [Thu, 23 Sep 2010 18:05:25 +0000 (11:05 -0700)]
Merge branch 'hwmod_2.6.37' of git://git.pwsan.com/linux-2.6 into omap-for-linus

14 years agoHTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
Cory Maccarrone [Wed, 18 Aug 2010 04:35:46 +0000 (04:35 +0000)]
HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046

This change adds in MMC and I2C support to the HTC Herald board, as well
as adding the HTCPLD driver for the PLD used on this phone.  It also
adds in the gpio-keys entries for the front directional keys and
selector and the cursor keys on the slide-out keyboard, and gpio-leds
support for the LEDs attached to the htcpld.

Additionally, SPI bus support (using the spi100k driver) and
touchscreen support (using the ads7846 driver) were added.

Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
14 years agoOMAP: hwmod: improve documentation, clean up function names
Paul Walmsley [Tue, 21 Sep 2010 21:02:23 +0000 (15:02 -0600)]
OMAP: hwmod: improve documentation, clean up function names

This patch:

- adds more documentation to the hwmod code

- fixes some documentation typos elsewhere in the file

- changes the _sysc_*() function names to appear in (verb, noun) order,
  to match the rest of the function names.

This patch should not result in any functional change.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
14 years agoOMAP: hwmod: Handle opt clocks node using clk_add_alias
Partha Basak [Tue, 21 Sep 2010 17:23:04 +0000 (19:23 +0200)]
OMAP: hwmod: Handle opt clocks node using clk_add_alias

For every optional clock present per hwmod per omap-device, this function
adds an entry in the clocks list of the form <dev-id=dev_name, con-id=role>,
if an entry is already present in the list of the form <dev-id=NULL, con-id=role>.

The function is called from within the framework inside omap_device_build_ss(),
after omap_device_register.

This allows drivers to get a pointer to its optional clocks based on its role
by calling clk_get(<dev*>, <role>).

Link to discussions related to this patch:
http://www.spinics.net/lists/linux-omap/msg34809.html

Signed-off-by: Charulatha V <charu@ti.com>
Signed-off-by: Partha Basak <p-basak2@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: simplified loop iterator; removed the superfluous clk_get(),
 using the clk_get() in clk_add_alias() instead]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP: hwmod: Enable module wakeup if in smartidle
Rajendra Nayak [Tue, 21 Sep 2010 14:28:30 +0000 (19:58 +0530)]
OMAP: hwmod: Enable module wakeup if in smartidle

If a module's OCP slave port is programmed to be in smartidle,
its also necessary that they have module level wakeup enabled.
Update _sysc_enable in hwmod framework to do this.

The thread "[PATCH 7/8] : Hwmod api changes" archived here:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34212.html

has additional technical information on the rationale of this patch.

Sergei Shtylyov <sshtylyov@mvista.com> identified an indentation
problem with this patch - thanks, Sergei.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Partha Basak <p-basak2@ti.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
[paul@pwsan.com: revised patch description]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
14 years agoOMAP: hwmod: Fix softreset for modules with optional clocks
Benoit Cousson [Tue, 21 Sep 2010 16:57:58 +0000 (18:57 +0200)]
OMAP: hwmod: Fix softreset for modules with optional clocks

Some modules (like GPIO, DSS...) require optionals clock to be enabled
in order to complete the sofreset properly.
Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
to be enabled before reset. Disabled them once the reset is done.

TODO:
For the moment it is very hard to understand from the HW spec, which
optional clock is needed and which one is not. So the current approach
will enable all the optional clocks.
Paul proposed a much finer approach that will allow to tag only the needed
clock in the optional clock table. This might be doable as soon as we have
a clear understanding of these dependencies.

Reported-by: Partha Basak <p-basak2@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP: hwmod: Fix softreset status check for some new OMAP4 IPs
Benoit Cousson [Tue, 21 Sep 2010 16:57:59 +0000 (18:57 +0200)]
OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs

In OMAP3 a specific SYSSTATUS register was used to get the softreset status.
Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
use the SYSC softreset bit to provide the status.

Other cases might exist:
- Some IPs like McBSP does have a softreset control but no reset status.
- Some IPs that represent subsystem, like the DSS, can contains
a reset status without softreset control. The status is the aggregation
of all the sub modules reset status.

- Add a new flag (SYSC_HAS_RESET_STATUS) to identify the new programming model
and replace the previous SYSS_MISSING, that was used to flag IP with
softreset control but without the SYSSTATUS register, with a specific
SYSS_HAS_RESET_STATUS flag.

- MCSPI and MMC contains both programming models, so the legacy one
will be prevented by removing the syss offset field that become useless.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
14 years agoOMAP: hwmod: add an hardreset API for use by other core code
Paul Walmsley [Tue, 21 Sep 2010 16:34:11 +0000 (10:34 -0600)]
OMAP: hwmod: add an hardreset API for use by other core code

Expose an hardreset API from hwmod in order to assert / deassert all the
individual reset lines that belong to an hwmod.  This API is needed by
some of the more complicated processor drivers, e.g., DSP/Bridge,
Syslink, etc.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
14 years agoOMAP: hwmod: Force a softreset during _setup
Benoit Cousson [Tue, 21 Sep 2010 16:34:11 +0000 (10:34 -0600)]
OMAP: hwmod: Force a softreset during _setup

Force the softreset of every IPs during the _setup phase.
IPs that cannot support softreset or that should not
be reset must set the HWMOD_INIT_NO_RESET flag in the
hwmod struct.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP: hwmod: Add hardreset management support
Benoît Cousson [Tue, 21 Sep 2010 16:34:11 +0000 (10:34 -0600)]
OMAP: hwmod: Add hardreset management support

Most processor IPs does have a hardreset signal controlled by the PRM.
This is different of the softreset used for local IP reset from the
SYSCONFIG register.
The granularity can be much finer than orginal HWMOD, for ex, the IVA
hwmod contains 3 reset lines, the IPU 3 as well, the DSP 2...
Since this granularity is needed by the driver, we have to ensure
than one hwmod exist for each hardreset line.

- Store reset lines as hwmod resources that a driver can query by name like
  an irq or sdma line.

- Add two functions for asserting / deasserting reset lines in hwmods
  processor that require manual reset control.
- Add one functions to get the current reset state.
- If an hwmod contains only one line, an automatic assertion / de-assertion
  is done.
  -> de-assert the hardreset line only during enable from disable transition
  -> assert the hardreset line only during shutdown

Note: The hwmods with hardreset line and HWMOD_INIT_NO_RESET flag must be
kept in INITIALIZED state.
They can be properly enabled only if the hardreset line is de-asserted
before.

For information here is the list of IPs with HW reset control
on an OMAP4430 device:

RM_DSP_RSTCTRL
  1,1,'RST2','RW','1','DSP - MMU, cache and slave interface reset control'
  0,0,'RST1','RW','1','DSP - DSP reset control'

RM_IVA_RSTCTRL
  2,2,'RST3','RW','1','IVA logic and SL2 reset control'
  1,1,'RST2','RW','1','IVA Sequencer2 reset control'
  0,0,'RST1','RW','1','IVA sequencer1 reset control'

RM_IPU_RSTCTRL
  2,2,'RST3','RW','1','IPU MMU and CACHE interface reset control.'
  1,1,'RST2','RW','1','IPU Cortex M3 CPU2  reset control.'
  0,0,'RST1','RW','1','IPU Cortex M3 CPU1  reset control.'

PRM_RSTCTRL
  1,1,'RST_GLOBAL_COLD_SW','RW','0','Global COLD software reset control.'
  0,0,'RST_GLOBAL_WARM_SW','RW','0','Global WARM software reset control.'

RM_CPU0_CPU0_RSTCTRL
RM_CPU1_CPU1_RSTCTRL
  0,0,'RST','RW','0','Cortex A9 CPU0&1 warm local reset control'

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: made the hardreset functions static; moved the register
 twiddling into prm*.c functions in previous patches; changed the
 function names to conform with hwmod practice]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
14 years agoOMAP2/3: PRM: add module hard reset support
Paul Walmsley [Tue, 21 Sep 2010 16:34:10 +0000 (10:34 -0600)]
OMAP2/3: PRM: add module hard reset support

This patch adds hard-reset support for processor modules (e.g., DSP, IVA)
on OMAP2/3 platforms.  It's based on the OMAP4 hard-reset support that Benoît
developed in the previous patch.

This patch is a collaboration between Benoît Cousson <b-cousson@ti.com>
and Paul Walmsley <paul@pwsan.com>.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
14 years agoOMAP4: PRM: add module hard reset support
Benoît Cousson [Tue, 21 Sep 2010 16:34:10 +0000 (10:34 -0600)]
OMAP4: PRM: add module hard reset support

Most processor modules (e.g., DSP, IVA, IPU) on OMAPs can be reset
under the control of the PRM.  This patch adds an API for this purpose
for OMAP4 devices:

int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift);
int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift);
int omap4_prm_deassert_hardreset(void __iomem *rstctrl_reg, u8 shift);

This API is intended to be used only by the hwmod code - a subsequent
patch will add that support to hwmod.

This patch is a collaboration between Benoît Cousson <b-cousson@ti.com>
and Paul Walmsley <paul@pwsan.com>.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP4: prcm: Add temporarily helper functions for rmw and read inside the PRM
Benoit Cousson [Tue, 21 Sep 2010 16:34:10 +0000 (10:34 -0600)]
OMAP4: prcm: Add temporarily helper functions for rmw and read inside the PRM

Since OMAP4 is using an absolute address, the current PRM accessors
are not useable.
OMAP4 adaptation for these API are currently ongoing, so define temp
version until the proper ones are defined.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP: hwmod: separate list locking and hwmod hardware locking
Kevin Hilman [Tue, 21 Sep 2010 16:34:09 +0000 (10:34 -0600)]
OMAP: hwmod: separate list locking and hwmod hardware locking

Currently omap_hwmod_mutex is being used to protect both the list
access/modification and concurrent access to hwmod functions.  This
patch separates these two types of locking.

First, omap_hwmod_mutex is used only to protect access and
modification of omap_hwmod_list.  Also cleaned up some comments
referring to this mutex that are no longer needed.

Then, for protecting concurrent access to hwmod functions, use a
per-hwmod mutex.  This protects concurrent access to a single hwmod,
but would allow concurrent access to different hwmods.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: added structure documentation; changed mutex variable
 name]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
14 years agoOMAP4: prcm: Fix global warm reset bit position
Rajeev Kulkarni [Tue, 21 Sep 2010 16:34:09 +0000 (10:34 -0600)]
OMAP4: prcm: Fix global warm reset bit position

OMAP4 platform has different register bits for Warm and Cold Resets.
Write one into appropriate bits.

Signed-off-by: Rajeev Kulkarni <rajeevk@ti.com>
Cc: Leed Aguilar <leed.aguilar@ti.com>
[b-cousson@ti.com: Change the define with the proper one from omap4 headers]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP: hwmod: Fix omap_hwmod_reset wrong state test
Liam Girdwood [Tue, 21 Sep 2010 16:34:09 +0000 (10:34 -0600)]
OMAP: hwmod: Fix omap_hwmod_reset wrong state test

The reset function wrongly used the state flag as a bit mask and was trying
to re-enable after a reset.

hwmod is still enabled for the PRCM point of view after a softreset
so there is no need to re-enable.

Remove the state check from omap_hwmod_reset since the _reset
function is checking that as well and in addition can generate
a warning

Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
[b-cousson@ti.com: remove the wrong test, remove the re-enable]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
14 years agoOMAP: hwmod: Do not disable clocks if hwmod already in idle
Benoit Cousson [Tue, 21 Sep 2010 16:34:08 +0000 (10:34 -0600)]
OMAP: hwmod: Do not disable clocks if hwmod already in idle

The disable function was disabling clocks and dependencies
from both enable and idle state. Since idle function is already
disabling both, an enable -> idle -> disable sequence will
try to disable twice the clocks and thus generate a
"Trying disable clock XXX with 0 usecount" warning.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP1: PM: add simple runtime PM layer to manage clocks
Kevin Hilman [Thu, 17 Jun 2010 22:48:43 +0000 (15:48 -0700)]
OMAP1: PM: add simple runtime PM layer to manage clocks

On OMAP1, we do not have omap_device + omap_hwmod to manage the
device-specific idle, enable and shutdown.  Instead, just
enable/disable device clocks automatically at the runtime PM level.

This allows drivers to not have any OMAP1 specific clock management
and allows them to simply use the runtime PM API to manage clocks.

OMAP1 compile fixes Manjunatha GK <manjugk@ti.com>

Cc: Manjunatha GK <manjugk@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP2+: PM: initial runtime PM core support
Kevin Hilman [Fri, 6 Nov 2009 03:06:01 +0000 (19:06 -0800)]
OMAP2+: PM: initial runtime PM core support

Implement the new runtime PM framework as a thin layer on top of the
omap_device API.  OMAP specific runtime PM methods are registered with
the as custom methods on the platform_bus.

In order to determine if a device is an omap_device, its parent device
is checked.  All omap_devices have a new 'omap_device_parent_ device
as their parent device, so checking for this parent is used to check
for valid omap_devices.  If a device is an omap_device, then the
appropriate omap_device functions are called for it.  If not, only the
generic runtime PM functions are called.

Device driver's ->runtime_idle() hook is called when the runtime PM
usecount reaches zero for that device.  Driver's ->runtime_suspend()
hooks are called just before the device is disabled (via
omap_device_idle()), and device driver ->runtime_resume() hooks are
called just after device has been enabled (via omap_device_enable().)

OMAP4 build support from Rajendra Nayak <rnayak@ti.com>.
OMAP2 build support from Charulatha V <charu@ti.com>

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Charulatha V <charu@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP: PM debugfs removing OMAP3 hardcodings.
Thara Gopinath [Thu, 12 Aug 2010 08:22:25 +0000 (13:52 +0530)]
OMAP: PM debugfs removing OMAP3 hardcodings.

This patch removes omap3 hardcodings from pm-debug.c
so that enabling PM debugfs support does break compilation
for other OMAP's. This is a preparatory patch for supporting
OMAP4 pm entries through PM debugfs.

Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP3: PM: whitespace cleanup around IO wakeup enable
Kevin Hilman [Tue, 10 Aug 2010 23:04:35 +0000 (16:04 -0700)]
OMAP3: PM: whitespace cleanup around IO wakeup enable

Cleanup indentation around IO wakeup enable, the '\' terminator is
not required in C when wrapping an expression past end-of-line.

Whitespace change only.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoOMAP: hwmod: Rename dma_ch to dma_req
Benoit Cousson [Tue, 21 Sep 2010 16:34:08 +0000 (10:34 -0600)]
OMAP: hwmod: Rename dma_ch to dma_req

The dma request line attribute was named dma channel, which leads
to confusion with the real dma channel definition.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
14 years agoLinux 2.6.36-rc5
Linus Torvalds [Mon, 20 Sep 2010 23:56:53 +0000 (16:56 -0700)]
Linux 2.6.36-rc5

14 years agoMerge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6
Linus Torvalds [Mon, 20 Sep 2010 23:45:08 +0000 (16:45 -0700)]
Merge git://git./linux/kernel/git/gregkh/staging-2.6

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6:
  Staging: vt6655: fix buffer overflow
  Revert: "Staging: batman-adv: Adding netfilter-bridge hooks"

14 years agoMerge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
Linus Torvalds [Mon, 20 Sep 2010 23:44:40 +0000 (16:44 -0700)]
Merge git://git./linux/kernel/git/gregkh/usb-2.6

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
  USB: musb: MAINTAINERS: Fix my mail address
  USB: serial/mos*: prevent reading uninitialized stack memory
  USB: otg: twl4030: fix phy initialization(v1)
  USB: EHCI: Disable langwell/penwell LPM capability
  usb: musb_debugfs: don't use the struct file private_data field with seq_files

14 years agoMerge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6
Linus Torvalds [Mon, 20 Sep 2010 23:44:24 +0000 (16:44 -0700)]
Merge git://git./linux/kernel/git/gregkh/tty-2.6

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6:
  serial: mfd: fix bug in serial_hsu_remove()
  serial: amba-pl010: fix set_ldisc

14 years agoStaging: vt6655: fix buffer overflow
Dan Carpenter [Mon, 6 Sep 2010 12:32:30 +0000 (14:32 +0200)]
Staging: vt6655: fix buffer overflow

"param->u.wpa_associate.wpa_ie_len" comes from the user.  We should
check it so that the copy_from_user() doesn't overflow the buffer.

Also further down in the function, we assume that if
"param->u.wpa_associate.wpa_ie_len" is set then "abyWPAIE[0]" is
initialized.  To make that work, I changed the test here to say that if
"wpa_ie_len" is set then "wpa_ie" has to be a valid pointer or we return
-EINVAL.

Oddly, we only use the first element of the abyWPAIE[] array.  So I
suspect there may be some other issues in this function.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>