Add IVA1 hwmod data for OMAP2420 and IVA2 hwmod data for 2430.  The data
is based on Benoît Cousson's hwmod data for the OMAP3 IVA blocks.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>

Add hwmod data for IVA2 module on OMAP3.

Naming of "iva" instead of "iva2" to be aligned with OMAP4 naming done
by Benoit Cousson.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Replace all the struct that contain l3 with l3_main in order
to be consistent with the OMAP4 naming convention.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add a new hwmod class for IVA devices.  To be used when hwmods
are created for IVA2 on OMAP3.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Create simple omap_devices for the main processors and busses.

This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.

Also, move these common PM init functions into a common_pm_init call
that is called as a device_initcall().  The PM init is done at this level
to ensure that the driver core is initialized before initialized.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: sparse warnings cleaned up; newly-created functions moved
 from mach-omap2/io.c to mach-omap2/pm.c; newly-created functions renamed
 to start with "omap2" rather than "omap"]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Enable omap_device layer support for OMAP4, so that drivers can
use them to enable/idle/shutdown devices.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

On kernels that don't use the omap_device_enable() calls to enable
devices, leave all on-chip devices enabled in hwmod _setup().
Otherwise, accesses to those devices are likely to fail, crashing the
system.  It's expected that kernels built without CONFIG_PM_RUNTIME
will be the primary use-case for this.  This functionality is
controlled by adding an extra parameter to omap_hwmod_late_init().

This patch is based on the patch "OMAP: hwmod: don't auto-disable
hwmod when !CONFIG_PM_RUNTIME" by Kevin Hilman
<khilman@deeprootsystems.com>.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some hwmods may need to be idled/enabled in atomic context, so
non-locking versions of these functions are required.

Most users should not need these and usage of theses should be
controlled to understand why access is being done in atomic context.
For this reason, the non-locking functions are only exposed at the
hwmod level and not at the omap-device level.

The use-case that led to the need for the non-locking versions is
hwmods that are enabled/idled from within the core idle/suspend path.
Since interrupts are already disabled here, the mutex-based locking in
hwmod can sleep and will cause potential deadlocks.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

In the lastest OMAP4 hwmod data file, the _hwmod was removed
in order to save some memory space and because it does not
bring a lot.
Align OMAP2420, 2430 and 3430 data files with the same convention.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag,
otherwise _enable() will fail due to failing _wait_target_ready().
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3.
The mask used to check this was using the bit position instead of the
bit mask.

This patch fixes the problem by using the bit mask instead of the bit
field.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

We need to wait on the IDLEST bit after the clocks are enabled
before attempting to access any register.

Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
i-clock is enabled first, the clkops_omap2_dflt_wait is
short-circuited as the companion f-clock is not enabled.
This can cause a data abort if the IDLEST has not transitioned,
and we try to access a USBTLL register.

Since the USBTLL i-clock and f-clock could be enabled in any order,
this is a bug. Fix it by changing the clkops for the f-clock.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The Nokia RX51 board code (arch/arm/mach-omap2/board-rx51-peripherals.c)
defines a key map for the matrix keypad keyboard. The hardware seems to
use all of the 8 rows and 8 columns of the keypad, although not all
possible locations are used.

The TWL4030 supports keypads with at most 8 rows and 8 columns. Most keys
are defined with a row and column number between 0 and 7, except

        KEY(0xff, 2, KEY_F9),
        KEY(0xff, 4, KEY_F10),
        KEY(0xff, 5, KEY_F11),

which represent keycodes that should be emitted when entire row is
connected to the ground.  since the driver handles this case as if we
had an extra column in the key matrix. Unfortunately we do not allocate
enough space and end up owerwriting some random memory.
Reported-and-tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@kernel.org
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

As reported by Sergei, a couple of braces were missing after
the WARN removal patch.

[07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed

https://patchwork.kernel.org/patch/100756/Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: fixed patch description per Anand's E-mail]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: Anand Gadiyar <gadiyar@ti.com>

This patch uses "ENABLE_ON_INIT" flag on the emif clock nodes
to avoid the emif clk getting cut as part of reset un-used clock
routine which prevents boot.

Since "omap4xxx_clk_init()" calls "clk_enable_init_clocks()"
which increases the usecount on all ENABLE_ON_INIT clocks, it
prevents "omap2_clk_disable_unused()" from disabling the clock.

The real fix is to have driver for EMIF and do clock get/enable
as part of it. The EMIF driver is planned to be done HWMOD way
so till that available to keep omap3_defconfig booting on OMAP4430,
this patch is necessary.
(Will updated the auto-gen script for 44xx accordingly)

The fix was suggested by Paul Walmsley
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Checking to se if the IO daisy chain is enabled should be checking the
PM_WKEN register, not the PM_WKST register.  Reading PM_WKST tells us
if an event occurred, not whether or not it is enabled.

Apparently, we've been lucky until now in that a pending event has not
been there during enable.  However, on 3630/Zoom3, I noticed because
of the WARN that this timeout was always happening.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 48feb337 arm: omap: switch over to gpio_set_debounce caused
"undefined reference to omap_set_gpio_debounce" build error.

The fix is to use the generic gpiolib function.

Cc: Felipe Balbi <felipe.balbi@nokia.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fixes following error,

CC      arch/arm/mach-omap2/usb-ehci.o
arch/arm/mach-omap2/usb-ehci.c:263: error: implicit declaration of function
'DMA_BIT_MASK'
arch/arm/mach-omap2/usb-ehci.c:263: error: initializer element is not constant
make[1]: *** [arch/arm/mach-omap2/usb-ehci.o] Error 1
Signed-off-by: NAmit Kucheria <amit.kucheria@canonical.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Stop using the omap-specific implementations for gpio debouncing now that
gpiolib provides its own support.
Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add platform init code for the OMAP3 OHCI driver.

Also, configure padconf settings for OMAP3 depending
on which port mode is used.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

EXTVBUS programming is required by OMAP3EVM REV >=E to supply 500mA
power so adding a flag which can be used by musb driver to program
EXTVBUS.
Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The OMAP2 MPU virtual clock node code attempted to call clk_get_rate()
while the clockfw_lock spinlock was held.  Fix by reading the sys_ck
rate directly.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add some missing credits for people who have contributed significant features
or fixes.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <tero.kristo@nokia.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Thara Gopinath <thara@ti.com>

Some powerdomains in OMAP4 support a direct transition from one sleep
state to another deeper sleep state without having to wakeup the
powerdomain. This patch adds an api in the powerdomain framework to
set the LOWPOWERSTATECHANGE bit in PWRSTCTRL register.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add clock framework support for changing the rate of sys_clkout2.
Signed-off-by: NLaine Walker-Avina <lwalkera@ieee.org>
[paul@pwsan.com: added commit message, added .round_rate pointer]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The pwrsts flag for ALWAYS ON domains like always_on_core_pwrdm
and wkup_pwrdm is wrongly populated with the define for a
powerdomain power state, instead of the allowable state
bitfields.
This causes a few api's to fail sensing invalid pwrst
requested.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The cm44xx.h files only had absolute register address
defines for all CM registers.
This patch adds additional register offset defines for all the
registers, so they can be used with apis like cm_read_mod_*
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The prm44xx.h files only had absolute register address
defines for all PRM registers.
This patch adds additional register offset defines for all the
registers, so they can be used with apis like prm_read_mod_*
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

CM1, CM2, PRM, SCRM and MPU_PRCM are already defined in omap44xx.h
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>

The MPU subsystem was named based on internal code name (CHIRON).
This patch will remove all the occurences of the chiron name
are replace it with PRCM_MPU in order to differentiate
the MPU local PRCM to the global one.

Remove PDA_ from PRCM_MPU registers names to stick to the global
PRM naming convention.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>

The automatic HW restore from OFF mode is not functional at all in
OMAP4430 ES1.0.
Because of that, it will be extensively changed in the next Si revision,
and the compatibilty will not be maintained with ES1.0.

Remove the current XXX_RESTORE registers definition to avoid future
conflicts with the next Si revision.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>

Most of the clock nodes belong to a clock domain, but it is perfectly valid
to have clock without clock domain.
Root clocks for example does not belong to any clock domain.
Keep the warning but reduce the verbosity.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

In the lastest OMAP4 hwmod data file, the _hwmod was removed
in order to save some memory space and because it does not
bring a lot.

The same cleanup will be have to done for other hwmods in
OMAP2 & 3 data files.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>

During the _init_clocks phase, the iteration is stopped but the
status is still change from _HWMOD_STATE_REGISTERED to
_HWMOD_STATE_CLKS_INITED.
Since the _setup phase will be done nevertheless, it might be
better to keep initializing the others clocks nodes and just
keep the warning.
It is much easier to debug when a important number of clocks
name are wrong during the early debug phase of a new platform.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The WARN is a little bit too verbose and is not providing
usefull information in that case.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The previous clock API was returning a standard linux error code in
case of failure. This is not the case anymore with the new
omap_clk_get_by_name API. A NULL value means that the clock node
does not exist.
Replace all the IS_ERR check by a !clk check.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The iteration is currently done on the omap_hwmod_ocp_if pointer
and not on the table pointer that reference them.
It worked most of the time because the structure are contiguous in
memory.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some initiator modules in OMAP2 & 3 does not have IDLEST bit,
in that case we cannot detect the module readiness by
polling that bit and must exist the function immediately
assuming that the module is ready.

The previous flag was affected to the OCP interface. While it is
technically true that the idlest is related to the L4 slave
interface of the module, the PRCM status belong to the module.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The return of the omap4_cm_wait_module_ready function is checked
in order to avoid accessing the sysconfig register if the module is
not in the correct state.
In that case the _setup will exit without trying to reset
using sysconfig.
For the moment a warning is printed. A proper management of fclk
and module reset will have to be done in order to init correctly
the problematic IPs listed below.

  <4>omap_hwmod: ivahd: cannot be enabled (3)
  <4>omap_hwmod: iss: cannot be enabled (3)
  <4>omap_hwmod: tesla: cannot be enabled (3)
  <4>omap_hwmod: sdma: cannot be enabled (3)
  <4>omap_hwmod: sl2: cannot be enabled (3)
  <4>omap_hwmod: sad2d: cannot be enabled (3)
  <4>omap_hwmod: ducati: cannot be enabled (3)
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The maximum timeout to wait for the PRCM to request that a module
exit idle or reach functionnal state is common to OMAP2/3/4 SoCs,
so, move it to the chip family-common cm.h include file.

Reduce the timeout from 20 ms to 2 ms.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>