The real time counter also called master counter, is a free-running
counter. It produces the count used by the CPU local timer peripherals
in the MPU cluster. The timer counts at a rate of 6.144 MHz.

The ratio registers needs to be configured based on system clock
only onetime. After initialisation, hardware takes care of adjusting
the clock in different low power modes to keep counter rate constant.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Fix inconsistency between mach-types and CONFIG_ name that prevents
touchbook board from booting.
Signed-off-by: NRadek Pilar <mrkva@mrkva.eu>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The new omap4 cpuidle implementation currently requires
ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.

This patch makes it possible to build a non-SMP kernel
for that platform. This is not normally desired for
end-users but can be useful for testing.

Without this patch, building rand-0y2jSKT results in:

drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]

It's not clear if this patch is the best solution for
the problem at hand. I have made sure that we can now
build the kernel in all configurations, but that does
not mean it will actually work on an OMAP44xx.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

The random config builds with PM and !ARM_CPU_SUSPEND breaks with below
error on omap2plus_defconfig.

arch/arm/mach-omap2/sleep44xx.S:323: undefined reference to `cpu_resume'
arch/arm/mach-omap2/omap-mpuss-lowpower.c:278: undefined reference to `cpu_suspend'

This is because recently merged OMAP5 platform shares the common files
with OMAP4 but doesn't select ARM_CPU_SUSPEND. Without the ARM_CPU_SUSPEND
the sleep code is meaningless.

Fix the same by adding ARM_CPU_SUSPEND for OMAP5. The suggestion came from
Russell King in an off-list discussion.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Kevin Hilman <khilman@ti.com>
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP4 CPUDILE driver is converted mainly based on notes from the
coupled cpuidle patch series.

The changes include :
- Register both CPUs and C-states to cpuidle driver.
- Set struct cpuidle_device.coupled_cpus
- Set struct cpuidle_device.safe_state to non coupled state.
- Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
  state that affects multiple cpus.
- Separate ->enter hooks for coupled & simple idle.
- CPU0 wait loop for CPU1 power transition.
- CPU1 wakeup mechanism for the idle exit.
- Enabling ARCH_NEEDS_CPU_IDLE_COUPLED for OMAP4.

Thanks to Kevin Hilman and Colin Cross on the suggestions/fixes
on the intermediate version of this patch.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Adding the build support required for OMAP5 soc
in to omap2+ config.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions as in __omap2_set_globals() function
(except for sdrc).
This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
so that we can reuse same function across omap2/3/4...
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Initially, we decided to make am33xx family of device to fall
under omap3 class (cpu_is_omap34xx() = true), since it carries
Cortex-A8 core. But while adding complete baseport support
(like, clock, power and hwmod) support, it is observed that,
we are creating more and more problems by treating am33xx device
as omap3 family, as nothing matches between them
(except cortex-A8 mpu).

So,  after long discussion we have came to the conclusion that,
we should not consider am33xx device as omap3 family, instead
create separate class (SOC_AM33XX) under OMAP2PLUS.
This means, for am33xx device, cpu_is_omap34xx() will return false,
and only cpu_is_am33xx() will be true.

Please refer to the link below, for mailing-list discussion on this -

http://www.spinics.net/lists/linux-omap/msg69439.htmlSigned-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: fixed typo, updated for soc_is changes]
Signed-off-by: NTony Lindgren <tony@atomide.com>

commit 164e0cbf (ARM: OMAP3/4: consolidate cpuidle Makefile) added
an OMAP-specific dependency from CPU_IDLE to CONFIG_PM.  This causes
some randconfig warnings when CONFIG_PM has unmet dependencies:

warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)

Fix this by making the dependency on CONFIG_PM_RUNTIME (which in turn
will enable CONFIG_PM.)
Reported-by: NTony Lindgren <tony@atomide.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The current Makefile compiles the cpuidle34xx.c and cpuidle44xx.c files
even if the cpuidle option is not set in the kernel.

This patch fixes this by creating a section in the Makefile where these
files are compiled only if the CONFIG_CPU_IDLE option is set.

This modification breaks an implicit dependency between CPU_IDLE and PM as
they belong to the same block in the Makefile. This is fixed in the Kconfig
by selecting explicitely PM is CPU_IDLE is set.

The linux coding style recommend to use no-op functions in the headers
when the subsystem is disabled instead of adding big section in C files.

This patch fix this also.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The FS (Full Speed) USB controller is available on 2420 and 2430,
but not being used.

Out of the 2420 based boards only Nokia N8X0 are seeing active
development and they have external HS (High Speed) TUSB controller.
On omap 2430sdp there is MUSB HS controller, so there's no need
to use the legacy USB FS controller.

That leaves only H4 and Apollon boards that could use the FS USB
controller. As both H4 and Apollon boards are old proprietary
development boards, it's unlikely that we have any active
developers working on those boards using the USB.

So remove the FS USB support for omap2 machines. Patches are
welcome if somebody wants to instead fix it all up to the
current standards.

Cc: linux-usb@vger.kernel.org
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We should not select ARCH_OMAP_OTG as the hardware does not
have the legacy FS (Full Speed) USB interface.

Cc: linux-usb@vger.kernel.org
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

No need to have an OMAP prefix on these SoCs that are in the family
but arent' really called OMAP.

Simple rename: CONFIG_SOC_OMAPAM33XX --> CONFIG_SOC_AM33XX

No functional change.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated for the driver config change also]
Signed-off-by: NTony Lindgren <tony@atomide.com>

No need to have an OMAP prefix on these SoCs that are in the family
but arent' really called OMAP.

Simple rename: CONFIG_SOC_OMAPTI81XX --> CONFIG_SOC_TI81XX

No functional change.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

HIGMEM support in kernel is quite mature now and we have boards
like ZOOM, PANDA, SDP where 1 GB memories are installed. With
HIGHMEM disabled not all of the 1GB of RAM (only ~700MB) can be
accessed. Hence, enable HIGMEM to make use of the entire memory.

On the boards which doesn't have more than 768 MB memory, all
the memory is directly mapped in "lowmem" and highmem isn't
exercised. Hence, there should be no impact by enabling HIGHMEM
for boards that do not need it.

Tested on OMAP4460 Panda-ES.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Tested-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This reverts commit c295fb63.

This makes existing .config files bloated by selecting in all
omaps as noted by Russell King - ARM Linux <linux@arm.linux.org.uk>.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add minimal support for Nokia RM-696 board.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

If we don't have ARCH_OMAP2, 3 or 4 selected randconfig will always
fail with multiple errors as the CPU and MACHINE are not set.

Fix this by changing arch/arm/Makefile to build mach-omap2 based on
ARCH_OMAP2PLUS. And let's introduce SOC_OMAP and SOC_OMAP_NOOP that
allow randconfig to generate buildable .config files.

Note that we can also remove few uncecssary ARCH_OMAP2PLUS lines
as they are all within if ARCH_OMAP2PLUS block.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Otherwise we get:

warning: (ARCH_OMAP3 && ARCH_OMAP4) selects USB_ARCH_HAS_EHCI
which has unmet direct dependencies (USB_SUPPORT)
Signed-off-by: NTony Lindgren <tony@atomide.com>

arm_memblock_steal() is not suppose to be used outside ->reserve callback.
OMAP barrier errata code was using it outside reserve callback and hence
it was broken.

Move the allocation as part of ->reserve callback to fix the it.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

To ensure correct alignment of cacheline-aligned data, the maximum
cacheline size needs to be known at compile time.

Since Cortex-A8 and Cortex-A15 have 64-byte cachelines (and it is likely
that there will be future ARMv7 implementations with the same line size)
then it makes sense to assume that CPU_V7 implies a 64-byte L1 cacheline
size. For CPUs with smaller caches, this will result in some harmless
padding but will help with single zImage work and avoid hitting subtle
bugs with misaligned data structures.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MACH_OMAP_4430SDP &&
MACH_OMAP4_PANDA && TPS6105X) selects REGULATOR_FIXED_VOLTAGE
which has unmet direct dependencies (REGULATOR)
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

warning: (MACH_OMAP3_TOUCHBOOK && DRM_RADEON_KMS && DRM_I915 &&
STUB_POULSBO && FB_BACKLIGHT && USB_APPLEDISPLAY && FB_OLPC_DCON &&
ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && EEEPC_LAPTOP &&
ACPI_ASUS && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE
which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)

A lot of boards need BACKLIGHT_CLASS_DEVICE for the framebuffers to
work, but it's not *needed* for the device itself. It might be nice to
enable it by default somewhoe if graphics stuff is enabled, but that's
another story.
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Several platforms are now using the memblock_alloc+memblock_free+
memblock_remove trick to obtain memory which won't be mapped in the
kernel's page tables.  Most platforms do this (correctly) in the
->reserve callback.  However, OMAP has started to call these functions
outside of this callback, and this is extremely unsafe - memory will
not be unmapped, and could well be given out after memblock is no
longer responsible for its management.

So, provide arm_memblock_steal() to perform this function, and ensure
that it panic()s if it is used inappropriately.  Convert everyone
over, including OMAP.

As a result, OMAP with OMAP4_ERRATA_I688 enabled will panic on boot
with this change.  Mark this option as BROKEN and make it depend on
BROKEN.  OMAP needs to be fixed, or 137d105d (ARM: OMAP4: Fix
errata i688 with MPU interconnect barriers.) reverted until such
time it can be fixed correctly.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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.htmlSigned-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>

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: NDave Martin <dave.martin@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
        (for nomadik, ux500)
Acked-by: NTony Lindgren <tony@atomide.com>
        (for omap)
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
        (for exynos)
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
        (for imx)
Acked-by: NOlof Johansson <olof@lixom.net>
        (for tegra)

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: NDave Martin <dave.martin@linaro.org>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
        (for cns3xxx)
Acked-by: NTony Lindgren <tony@atomide.com>
        (for omap)
Acked-by: NShawn Guo <shawn.guo@linaro.org>
        (for imx)
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
        (for exynos)
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
        (for imx)
Acked-by: NOlof Johansson <olof@lixom.net>
        (for tegra)

devicetree will become the mandatory boot method for OMAP2+.
In order to avoid cluttering the OMAP code with #ifdef CONFIG_OF,
select USE_OF by default for every OMAP2+ systems.

Enable PROC_DEVICETREE as well.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds minimal support and build configuration for TI8148 EVM. Also
adds support for low level debugging on UART1 console on the EVM.

Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with machine
info for TI8148 EVM.
Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch updates existing macros, functions used for TI816X, to enable
addition of other SoCs belonging to TI81XX family (e.g., TI814X).

The approach taken is to use TI81XX/ti81xx for code/data going to be common
across all TI81XX devices.

cpu_is_ti81xx() is introduced to handle code common across TI81XX devices.

In addition, ti8168_evm_map_io() is now replaced with ti81xx_map_io() and moved
in mach-omap2/common.c as same will be used for TI814X and is not board
specific.
Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch updates the common platform files with AM335X device
support (AM33XX family).

The approach taken in this patch is,
AM33XX device will be considered as OMAP3 variant, and a separate
SoC class created for AM33XX family of devices with a subclass type
for AM335X device, which is newly added device in the family.

This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x()
checks will return success on AM335X device.
A kernel config option CONFIG_SOC_OMAPAM33XX is added under OMAP3
to include support for AM33XX build.

Also, cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence
struct clksel_rate.flags, struct prcm_config.flags and cpu_mask
are changed to u16 from u8.
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Hemant Pedanekar <hemantp@ti.com>
[tony@atomide.com: left out CK_AM33XX for now]
Signed-off-by: NTony Lindgren <tony@atomide.com>

On OMAP4 SOC, intecronnects has many write buffers in the async bridges
and they need to be drained before CPU enters into standby state.

Patch 'OMAP4: PM: Add CPUX OFF mode support' added CPU PM support
but OMAP errata i688 (Async Bridge Corruption) needs to be taken
care to avoid issues like system freeze, CPU deadlocks, random
crashes with register accesses, synchronisation loss on initiators
operating on both interconnect port simultaneously.

As per the errata, if a data is stalled inside asynchronous bridge
because of back pressure, it may be accepted multiple times, creating
pointer misalignment that will corrupt next transfers on that data
path until next reset of the system (No recovery procedure once
the issue is hit, the path remains consistently broken).
Async bridge can be found on path between MPU to EMIF and
MPU to L3 interconnect. This situation can happen only when the
idle is initiated by a Master Request Disconnection (which is
trigged by software when executing WFI on CPU).

The work-around for this errata needs all the initiators
connected through async bridge must ensure that data path
is properly drained before issuing WFI. This condition will be
met if one Strongly ordered access is performed to the
target right before executing the WFI. In MPU case, L3 T2ASYNC
FIFO and DDR T2ASYNC FIFO needs to be drained. IO barrier ensure
that there is no synchronisation loss on initiators operating
on both interconnect port simultaneously.

Thanks to Russell for a tip to conver assembly function to
C fuction there by reducing 40 odd lines of code from the patch.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
Acked-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NVishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

This patch selects ARM_AMBA if OMAP3_EMU is defined because
OC_ETM depends on ARM_AMBA, so fix the link failure[1].

[1],
arch/arm/kernel/built-in.o: In function `etm_remove':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:609: undefined
reference to `amba_release_regions'
arch/arm/kernel/built-in.o: In function `etb_remove':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:409: undefined
reference to `amba_release_regions'
arch/arm/kernel/built-in.o: In function `etm_init':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:640: undefined
reference to `amba_driver_register'
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:646: undefined
reference to `amba_driver_register'
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:648: undefined
reference to `amba_driver_unregister'
arch/arm/kernel/built-in.o: In function `etm_probe':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:545: undefined
reference to `amba_request_regions'
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:595: undefined
reference to `amba_release_regions'
arch/arm/kernel/built-in.o: In function `etb_probe':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:347: undefined
reference to `amba_request_regions'
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:392: undefined
reference to `amba_release_regions'
arch/arm/mach-omap2/built-in.o: In function `emu_init':
/home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:62:
undefined reference to `amba_device_register'
/home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:63:
undefined reference to `amba_device_register'
make: *** [.tmp_vmlinux1] Error 1
making modules
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

Now that MULTI_IRQ_HANDLER is selected by all the in-tree
GIC users, make it mandatory and remove the unused macros.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Convert the omap2plus platforms to be using CONFIG_MULTI_IRQ_HANDLER.
Each machine is modified to provide either omap2_intc_handle_irq(),
omap3_intc_handle_irq() or gic_handle_irq().

This allows for a major cleanup, removing the MULTI_OMAP setup
from the interrupt path.

Tested on both Panda and IGEPv2 (single kernel image)
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

We currently have two symbols to control compilation the MFD subsystem,
MFD_SUPPORT and MFD_CORE. The MFD_SUPPORT is actually not required
at all, it only hides the submenu when not set, with the effect that
Kconfig warns about missing dependencies when another driver selects
an MFD driver while MFD_SUPPORT is disabled. Turning the MFD submenu
back from menuconfig into a plain menu simplifies the Kconfig syntax
for those kinds of users and avoids the surprise when the menu
suddenly appears because another driver was enabled that selects this
symbol.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Re-cycle the original board-generic.c file to support Device Tree
for every OMAP2+ variants.

The current approach is an intermediate step before having only
one machine descriptor that will use some generic DT aware
functions.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

Support for the cpu_suspend functions is only built-in
when CONFIG_PM_SLEEP is enabled, but omap3/4, exynos4
and pxa always call cpu_suspend when CONFIG_PM is enabled.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

CONFIG_PM is no longer a user-selectable Kconfig option.  Rather it is
automatically enabled if either CONFIG_SUSPEND or CONFIG_RUNTIME_PM is
enabled, so having a 'select PM' here is redunant when 'select
CONFIG_PM_RUNTIME' is present.
Signed-off-by: NKevin Hilman <khilman@ti.com>

cm-t3730 is basically the same board as cm-t35,
but has AM/DM3730 SoC assembled and therefore some changes are required.
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Acked-by: NMike Rapoport <mike@compulab.co.il>
[tony@atomide.com: updated for init_irq cleanup as noted by khilman@ti.com]
Signed-off-by: NTony Lindgren <tony@atomide.com>