OMAP4470 currently fails to boot, printing various messages such as ...

omap_hwmod: mpu: cannot clk_get main_clk dpll_mpu_m2_ck
omap_hwmod: mpu: cannot _init_clocks
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2062 _init+0x2a0/0x2e4()
omap_hwmod: mpu: couldn't init clocks
Modules linked in:
[<c001c7fc>] (unwind_backtrace+0x0/0xf4) from [<c0043c64>] (warn_slowpath_common+0x4c/0x64)
[<c0043c64>] (warn_slowpath_common+0x4c/0x64) from [<c0043d10>] (warn_slowpath_fmt+0x30/0x40)
[<c0043d10>] (warn_slowpath_fmt+0x30/0x40) from [<c0674208>] (_init+0x2a0/0x2e4)
[<c0674208>] (_init+0x2a0/0x2e4) from [<c067428c>] (omap_hwmod_setup_one+0x40/0x60)
[<c067428c>] (omap_hwmod_setup_one+0x40/0x60) from [<c0674280>] (omap_hwmod_setup_one+0x34/0x60)
[<c0674280>] (omap_hwmod_setup_one+0x34/0x60) from [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250)
[<c06726f4>] (omap_dm_timer_init_one+0x30/0x250) from [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108)
[<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108) from [<c0672c60>] (omap4_timer_init+0x10/0x5c)
[<c0672c60>] (omap4_timer_init+0x10/0x5c) from [<c066c418>] (time_init+0x20/0x30)
[<c066c418>] (time_init+0x20/0x30) from [<c0668814>] (start_kernel+0x1b0/0x304)
[<c0668814>] (start_kernel+0x1b0/0x304) from [<80008044>] (0x80008044)
---[ end trace 1b75b31a2719ed1c ]---

The problem is that currently none of the clocks are being registered for
OMAP4470 devices and so on boot-up no clocks can be found and the kernel panics.

This fix allows the kernel to boot without failure using a simple RAMDISK file
system on OMAP4470 blaze board.

Per feedback from Paul and Benoit the 4470 clock data is incomplete for new
modules such as the 2D graphics block that has been added to the 4470.
Therefore add a warning to indicate that the clock data is incomplete.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>

commit 8259573b (ARM: OMAP2+: nand: Make board_onenand_init() visible
to board code) broke the build for configs with OneNAND disabled.  By
removing the static in the header file, it created a duplicate definition
in the .c and the .h files, resuling in a build error:

/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error: redefinition of 'board_onenand_init'
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous definition of 'board_onenand_init' was here
make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [arch/arm/mach-omap2] Error 2
make: *** [sub-make] Error 2

Fix this by removing the duplicate dummy entry from the C file.

Cc: Enric Balletbò i Serra <eballetbo@gmail.com>
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As per the OMAP4 documentation, audio over HDMI must be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmod uses
no-idle/force-idle settings instead of smart-idle mode.

This is required as the DSS interface clock is used as functional clock
for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
be choppy, have bad quality or not be audible at all.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
[b-cousson@ti.com: Update the subject and align the .flags
location with the script template]
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit bbd707ac ("ARM: omap2: use
machine specific hook for late init") resulted in the addition of this
sparse warning:

arch/arm/mach-omap2/mux.c:791:12: warning: symbol 'omap_mux_late_init' was not declared. Should it be static?

Fix by including the header file containing the prototype.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>

Increase the timeout for disabling an IP block to five milliseconds.
This is to handle the usb_host_fs idle latency, which takes almost
four milliseconds after a host controller reset.

This is the second of two patches needed to resolve the following
boot warning:

omap_hwmod: usb_host_fs: _wait_target_disable failed

Thanks to Sergei Shtylyov <sshtylyov@mvista.com> for finding
an unrelated hunk in a previous version of this patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: Tero Kristo <t-kristo@ti.com>

Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it.  This
patch populates some clock structure clockdomain names to resolve the
following warnings during kernel init:

omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>

The 32k sync timer IP block target idle modes in the hwmod data are
incorrect.  The IP block does not support any smart-idle modes.
Update the data to reflect the correct modes.

This problem was initially identified and a diff fragment posted to
the lists by Benoît Cousson <b-cousson@ti.com>.  A patch description
bug in the first version was also identified by Benoît.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>

If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the
IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup.
Signed-off-by: NDjamil Elaidi <d-elaidi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit e813a55e ("OMAP: board-files:
remove custom PD GPIO handling for DVI output") moved TFP410 chip's
powerdown-gpio handling from the board files to the tfp410 driver. One
gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in
the Beagle board file. This causes the tfp410 driver to fail to request
the gpio on Beagle, causing the driver to fail and thus the DVI output
doesn't work.

This patch removes several boot errors from board-omap3beagle.c:

 - gpio_request: gpio--22 (DVI reset) status -22
 - Unable to get DVI reset GPIO

There is a combination of leftover code and revision confusion.
Additionally, xM support is currently a hack.

For original Beagleboard this removes the double initialization of GPIO
170, properly configures it as an output, and wraps the initialization
in an if block so that xM does not attempt to request it.

For Beagleboard xM it removes reference to GPIO 129 which was part
of rev A1 and A2 designs, but never functioned. It then properly assigns
beagle_dvi_device.reset_gpio in beagle_twl_gpio_setup and removes the
hack of initializing it high. Additionally, it uses
gpio_set_value_cansleep since this GPIO is connected through i2c.

Unfortunately, there is no way to tell the difference between xM A2 and
A3. However, GPIO 129 does not function on rev A1 and A2, and the TWL
GPIO used on A3 and beyond is not used on rev A1 and A2, there are no
problems created by this fix.

Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4.
Signed-off-by: NRuss Dill <Russ.Dill@ti.com>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Here's one more gpio_to_irq conversion that we missed
earlier. Tested with n800 in gadget mode using USB_ETH.

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 62285963 (usb: musb: drop a gigantic amount of ifdeferry)
got rid of a bunch of ifdefs in the MUSB code. Looks like the
platform init code is still using these dropped defines though,
which in many cases results the board defaulting always to host
mode.

Currently the situation is that USB_MUSB_HDRC is the main
Kconfig option with additional USB_GADGET_MUSB_HDRC so only
these two should be used to select between host and OTG mode.

Fix the situation for omaps. The following users should fix the
platform init code in a similar way:

Dropped Kconfig option          Current users

USB_MUSB_OTG                    blackfin, davinci, not in Kconfigs
USB_MUSB_PERIPHERAL             davinci, not in Kconfigs
USB_MUSB_HOST                   davinci, not in Kconfigs
USB_MUSB_HDRC_HCD               blackfin, not in Kconfigs
USB_MUSB_OTG                    blackfin, not in Kconfigs

Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: linux-usb@vger.kernel.org
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove prm_clkdm and cm_clkdm and allow hwmods to have no clockdomain.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Remove the existing alias for pad_fck, prcm_fck from the clock data and
add them as opt_clks to the hwmod data.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Remove the existing alias for pad_fck, prcm_fck from the clock data and
add them as opt_clks to the hwmod data.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Remove the existing alias for pad_fck, prcm_fck from the clock data and
add them as opt_clks to the hwmod data.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Provide an interface for a driver to call SCM functions to
set a boot address and boot mode.
Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

SCM contains boot addr and boot mode registers to control
other processors on different OMAP versions. It controls the
boot address and mode for DSP based subsystems like: IVA 2.1
(OMAP2430), IVA 2.2 (OMAP3) and DSP (OMAP4).

If contained within SCM registers, when a processor is
booting it uses BOOTADDR to start running the code at that
location. BOOTMOD register specifies a different set of
modes for the processor to execute when booting (from direct,
idle, self-loop, user and default).

Since there was no offset associated with OMAP4, this patch
defines it.
Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Rather than use runtime cpu_is* checking inside _init_clkdm, initialize
SoC specific function pointer at init time.
Signed-off-by: NKevin Hilman <khilman@ti.com>
[paul@pwsan.com: convert to use soc_ops function pointers; remove second para
 from commit message since soc_ops function pointers are now set during hwmod
 layer init]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Rather than using cpu_is* checking at runtime, initialize SoC specific
function pointers for the various hard reset functions at init time.
Signed-off-by: NKevin Hilman <khilman@ti.com>
[paul@pwsan.com: convert to use soc_ops function pointers; add kerneldoc]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Rather than using cpu_is* checking at runtime, initialize an SoC specific
function pointer for wait_target_ready().

While here, downgrade the BUG() to a WARN_ON() so it gives a noisy
warning instead of causing a kernel panic.
Signed-off-by: NKevin Hilman <khilman@ti.com>
[paul@pwsan.com: convert to use soc_ops function pointers; add kerneldoc;
 move soc_ops functions to their own section in the code; integrated
 the _wait_target_ready() function with the OMAP2/OMAP4 variants;
 renamed the wait_module_ready field to wait_target_ready]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

_omap4_wait_target_disable() is called only from inside _omap4_disable_module()
which is already protected by SoC specific checks.  Remove the cpu_is check
here.
Signed-off-by: NKevin Hilman <khilman@ti.com>

The enable/disable module functions are specific to SoCs with
OMAP4-class PRCM.  Rather than use cpu_is* checks at runtime inside
the enable/disable module functions, use cpu_is at init time to
initialize function pointers only for SoCs that need them.

NOTE: the cpu_is* check for _enable_module was different than
      the one for _disable_module, and this patch uses
      cpu_is_omap44xx() for both.
Signed-off-by: NKevin Hilman <khilman@ti.com>
[paul@pwsan.com: moved soc_ops function pointers to be per-kernel rather than
 per-hwmod since they do not vary by hwmod; added kerneldoc]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

_enable_module is specific to SoCs with PRCM interfaces similar to
that of the OMAP4, so rename it to be consistent with the
corresponding _omap4_disable_module.
Signed-off-by: NKevin Hilman <khilman@ti.com>
[paul@pwsan.com: tweaked commit message]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

AM33XX PRCM module consists of various clockdomains, in all
total we have 18 clockdomains available, with following
controlling options,
   - SW Sleep: sw forced sleep transition
   - SW Wakeup: sw forced wakeup transition

This patch adds all available clockdomain data, respective
clockdomain operations for AM33XX family of device, and also
integrates it into existing OMAP framework.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
CC: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: removed CLKDM_NO_AUTODEPS from clockdomain flags, removed
 unnecessary .clktrctrl_offs field; updated for 3.5]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add offset & mask fields to struct powerdomain

In case of AM33xx family of devices, there is no consistency between
PWRSTCTRL & PWRSTST register offsers in PRM space, for example -

PRM_XXX           PWRSTCTRL     PWRSTST
=======================================
PRM_PER_MOD:      0x0C,         0x08
PRM_WKUP_MOD:     0x04,         0x08
PRM_MPU_MOD:      0x00,         0x04
PRM_DEVICE_MOD:   NA,           NA

And also, there is no consistency between bit-offsets inside
PWRSTCTRL & PWRSTST register, for example -

PRM_XXX           LOGICRET  MEMON  MEMRET
=======================================
GFX_PWRCTRL:      2,        17,    6
PER_PWRCTRL:      3,        25,    29
MPU_PWRCTRL:      2,        18,    22
WKUP_PWRCTRL:     3,        NA,    NA

This means, we need to maintain and pass on all this information
in powerdomain handle; so adding fields for,
   - PWRSTCTRL/ST register offset
   - Logic retention state mask
   - mem_on/ret/pwrst/retst mask

Currently, this fields is only applicable and used for AM33XX devices.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: this patch is a combination of "Add offset & mask fields to
 struct powerdomain" and the powerdomain portions of "ARM: OMAP3+: am33xx:
 Add powerdomain & PRM support"; updated for 3.5]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

As far as PRM/CM/PRCM modules are concerned, AM33XX device is
different than OMAP3 and OMAP4 architectures; so similar to
PRM implementation, handle AM33XX CM separately.

This patch introduces AM33XX CM module low-level api's, used and
required by omap clockdomain and hwmod framework.

Please note that cm-regbits-33xx.h (register bit field offset)
and cm33xx.h (register addr offset) files are mostly auto generated.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
CC: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: split the hwmod code changes in this patch into a separate
 patch; updated for 3.5]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

As far as PRM/CM/PRCM modules are concerned, AM33XX device is
different than OMAP3 and OMAP4 architectures; so we need to handle it
separately.  This patch adds support for the PRM APIs required for
AM33XX device.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: separated the PRM parts of "ARM: OMAP3+: am33xx: Add
 powerdomain & PRM support" into this patch; fixed Makefile prm33xx.o
 location; cleaned up some checkpatch violations; updated for 3.5]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently dummy voltage domain data is being created
in order to succeed boot process, nothing has been done
w.r.t actual hardware (voltage control).

Also, hook up the AM33XX voltage domain to OMAP framework.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
[paul@pwsan.com: updated for 3.5]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Define AM33XX control register, in order to allow access to
control register address space, also add CONTROL_SEC_CLK_CTRL
register offset; both are required in clock tree data,
for wdt0 and timer0 clock source select configuration.

CONTROL.SEC_CLK_CTRL register is provided to select/configure
clock input for WDT0 and TIMER0.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
[paul@pwsan.com: added include of plat/am33xx.h to fix build break;
 added AM33XX_CONTROL_STATUS bitfields that will be needed for the clock
 tree; fixed some control.h whitespace problems while here]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP dmtimer driver allows you to dynamically configure the functional
clock that drives the timer logic. The dmtimer driver uses the device name and
a "con-id" string to search for the appropriate functional clock.

Currently, we define a clock alias for each functional clock source each timer
supports. Some functional clock sources are common to all of the timers on a
device and so for these clock sources we can use a single alias with a unique
con-id string.

The possible functional clock sources for an OMAP device are a 32kHz clock,
a system (MHz range) clock and (for OMAP2 only) an external clock. By defining
a unique con-id name for each of these (timer_32k_ck, timer_sys_ck and
timer_ext_ck) we can eliminate a lot of the clock aliases for timers. This
reduces code, speeds-up searches and clock initialisation time.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP1 uses an architecture specific function for setting the dmtimer clock
source, where as the OMAP2+ devices use the clock framework. Eventually OMAP1
device should also use the clock framework and hence we should not any
architecture specific functions.

For now move the OMAP2+ function for configuring the clock source into the
dmtimer driver. Therefore, we do no longer need to specify an architecture
specific function for setting the clock source for OMAP2+ devices. This will
simplify device tree migration of the dmtimers for OMAP2+ devices.

From now on, only OMAP1 devices should specify an architecture specific
function for setting the clock source via the platform data set_dmtimer_src()
function pointer.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For OMAP2+ devices, a function pointer that returns the number of times a timer
power domain has lost context is passed to the dmtimer driver. This function
pointer is only populated for OMAP2+ devices and it is pointing to a platform
function. Given that this is a platform function, we can simplify the code by
removing the function pointer and referencing the function directly. We can use
the OMAP_TIMER_ALWON flag to determine if we need to call this function for
OMAP1 and OMAP2+ devices.

The benefit of this change is the we can remove the function pointer from the
platform data and simplifies the dmtimer migration to device-tree.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The platform data variable loses_context is used to determine if the timer may
lose its logic state during power transitions and so needs to be restored. This
information is also provided in the HWMOD device attributes for OMAP2+ devices
via the OMAP_TIMER_ALWON flag. When this flag is set the timer will not lose
context. So use the HWMOD device attributes to determine this.

For OMAP1 devices, loses_context is never set and so set the OMAP_TIMER_ALWON
flag for OMAP1 timers to ensure that code is equivalent.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently, the dmtimer determines whether an timer can support an external
clock source (sys_altclk) for driving the timer by the IP version. Only
OMAP24xx devices can support an external clock source, but the IP version
between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates
that OMAP3 devices can use an external clock source.

Rather than use the IP version, just let the clock framework handle this.
If the "alt_ck" does not exist for a timer then the clock framework will fail
to find the clock and hence will return an error. By doing this we can eliminate
the "timer_ip_version" variable passed as part of the platform data and simplify
the code.

We can also remove the timer IP version from the HWMOD data because the dmtimer
driver uses the TIDR register to determine the IP version.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix the following issues with the timer device attributes for OMAP2+ devices:

1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
   that these timers are in an ALWAYS-ON power domain. This is not the case
   only timer1 is in an ALWAYS-ON power domain.
2. For OMAP3xxx devices, timers 2-7 have the ALWAYS-ON attribute indicating
   that these timers are in an ALWAYS-ON power domain. This is not the case
   only timer1 and timer12 are in an ALWAYS-ON power domain.
3. For OMAP3xxx devices, timer12 does not have the ALWAYS-ON attribute but
   is in an always-on power domain.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Although the OMAP timers share a common hardware design, there are some
differences between the timer instances in a given device. For example, a timer
maybe in a power domain that can be powered-of, so can lose its logic state and
need restoring where as another may be in power domain that is always be on.
Another example, is a timer may support different clock sources to drive the
timer. This information is passed to the dmtimer via the following platform data
structure.

struct dmtimer_platform_data {
	int (*set_timer_src)(struct platform_device *pdev, int source);
	int timer_ip_version;
	u32 needs_manual_reset:1;
	bool loses_context;
	int (*get_context_loss_count)(struct device *dev);
};

The above structure uses multiple variables to represent the timer features.
HWMOD also stores the timer capabilities using a bit-mask that represents the
features supported. By using the same format for representing the timer
features in the platform data as used by HWMOD, we can ...

1. Use the flags defined in the plat/dmtimer.h to represent the features
   supported.
2. For devices using HWMOD, we can retrieve the features supported from HWMOD.
3. Eventually, simplify the platform data structure to be ...

struct dmtimer_platform_data {
	int (*set_timer_src)(struct platform_device *pdev, int source);
	u32 timer_capability;
}

Another benefit from doing this, is that it will simplify the migration of the
dmtimer driver to device-tree. For example, in the current OMAP2+ timer code the
"loses_context" variable is configured at runtime by calling an architecture
specific function. For device tree this creates a problem, because we would need
to call the architecture specific function from within the dmtimer driver.
However, such attributes do not need to be queried at runtime and we can look up
the attributes via HWMOD or device-tree.

This changes a new "capability" variable to the platform data and timer
structure so we can start removing and simplifying the platform data structure.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

During early boot, one or two dmtimers are reserved by the kernel as system
timers (for clocksource and clockevents). These timers are marked as reserved
and the dmtimer driver is notified which timers have been reserved via the
platform data information.

For OMAP2+ devices the timers reserved may vary depending on device and compile
flags. Therefore, it is not easy to assume which timers we be reserved for the
system timers. In order to migrate the dmtimer driver to support device-tree we
need a way to pass the timers reserved for system timers to the dmtimer driver.
Using the platform data structure will not work in the same way as it is
currently used because the platform data structure will be stored statically in
the dmtimer itself and the platform data will be selected via the device-tree
match device function (of_match_device).

There are a couple ways to workaround this. One option is to store the system
timers reserved for the kernel in the device-tree and query them on boot.
The downside of this approach is that it adds some delay to parse the DT blob
to search for the system timers. Secondly, for OMAP3 devices we have a
dependency on compile time flags and the device-tree would not be aware of that
kernel compile flags and so we would need to address that.

The second option is to add a function to the dmtimer code to reserved the
system timers during boot and so the dmtimer knows exactly which timers are
being used for system timers. This also allows us to remove the "reserved"
member from the timer platform data. This seemed like the simpler approach and
so was implemented here.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The OMAP2+ timer code has a definition for the maximum number of timers that
OMAP2+ devices have. This defintion is not used anywhere in the code and
appears to be left over. Furthermore the definition is not accurate for OMAP4
devices that only have 11 timers available because the 12th timer is reserved
as a secure timer and for OMAP3 devices the 12th timer is not available on
secure devices. Therefore, remove this definition.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 7f28427b (ARM: OMAP2+: Move omap_dsp_reserve_sdram_memblock() to mach-omap2)
moved DSP platform init code, but failed to include memblock.h causing:

arch/arm/mach-omap2/dsp.c: In function 'omap_dsp_reserve_sdram_memblock':
arch/arm/mach-omap2/dsp.c:58: error: implicit declaration of function 'arm_memblock_steal'
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Otherwise we will get:

arch/arm/mach-omap2/omap_l3_smx.c: In function ‘omap3_l3_block_irq’:
arch/arm/mach-omap2/omap_l3_smx.c:156: warning: unused variable ‘address’
arch/arm/mach-omap2/omap_l3_smx.c:155: warning: unused variable ‘multi’
arch/arm/mach-omap2/omap_l3_smx.c:154: warning: unused variable ‘initid’
arch/arm/mach-omap2/omap_l3_smx.c:153: warning: unused variable ‘code’
arch/arm/mach-omap2/omap_l3_smx.c: At top level:
arch/arm/mach-omap2/omap_l3_smx.c:68: warning: ‘omap3_l3_code_string’ defined but not used
arch/arm/mach-omap2/omap_l3_smx.c:90: warning: ‘omap3_l3_initiator_string’ defined but not used

Fix it by always showing the L3 error.
Signed-off-by: NTony Lindgren <tony@atomide.com>