Kevin discovered that commit c8d82ff6
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3.  This prevents device low power
states.

The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active.  This in turn prevents the WKUP
clockdomain from transitioning to idle.  There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.

It turns out that there is no need to take the 32k sync timer out of
idle.  The IP block itself probably does not have any native idle
handling at all, due to its simplicity.  Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active.  So
we can safely leave the 32k sync timer in target-force-idle mode, even
while we continue to access it.

This workaround is implemented by defining a new clockdomain flag,
CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
guaranteed to be active whenever the MPU is inactive.  If an IP
block's main functional clock exists inside this clockdomain, and the
IP block does not support smart-idle modes, then the hwmod code will
place the IP block into target force-idle mode even when enabled.  The
WKUP clockdomains on OMAP3/4 are marked with this flag.  (On OMAP2xxx,
no OCP header existed on the 32k sync timer.)   Other clockdomains also
should be marked with this flag, but those changes are deferred until
a later merge window, to create a minimal fix.

Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses.  These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource.  But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.

Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI.  But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.

This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.

Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on
an earlier version of this patch.  Thanks to Tero Kristo
<t-kristo@ti.com> for identifying a bug in an earlier version of this
patch.  Thanks to Benoît Cousson <b-cousson@ti.com> for identifying
some bugs in several versions of this patch and for implementation
comments.

References:

1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
   (SWPU223U), available from:
   http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip

2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
   (SWPU223U)

3. ibid.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The commit 503d0ea2
  ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks

added a wrong "prcm_clk" alias for PRCM clock whereas the McBSP
driver and previous OMAPs are using "prcm_fck".

It thus lead to the following warning.

[   47.409729] omap-mcbsp: clks: could not clk_get() prcm_fck

Fix that by changing the opt_clk role to prcm_fck.
Reported-by: NMisael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NSebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP4 usb_host_fs (OHCI) and AESS IP blocks require some special
programming for them to enter idle.  Without this programming, they
will prevent the rest of the chip from entering full chip idle.

To implement the idle programming cleanly, this will take some
coordination between maintainers.  This is likely to take some time,
so it is probably best to leave this for 3.6 or 3.7.  So, in the
meantime, prevent these IP blocks from being registered.

Later, once the appropriate support is available, this patch can be
reverted.

This second version comments out the IP block data since Benoît didn't
like removing it.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

The SYS_NIRQ1 pin is the interupt line for the PMIC part of the TWL6030
and interrupts from the PMIC are needed as wakeup sources.

Ensure this pin is mux'd as input and has wakeup enabled so PMIC
interupts (e.g. RTC) can be used as wakeup sources.

Tested on OMAP4430/Panda.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

In order for suspend/resume dependencies to work correctly, I2C has to
be initialized (more specifically, registered with the driver core)
before MMC.  Without this, the MMC driver fails to adjust the VMMC
regulator (using i2c writes) during the suspend path.

Problem found testing suspend/resume on 3730/OveroSTORM platform.
Signed-off-by: NKevin Hilman <khilman@ti.com>
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>

Using nr_irqs as local variable name triggers the sparse warning..
./arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'nr_irqs' shadows an earlier one
./linux/include/linux/irqnr.h:26:12: originally declared here
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The am35x family of SoCs only support the PWRSTS_ON
state so create a new set of powerdomain structures
that ensure that only the ON state is entered.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>

The am35x family of SoCs do not have an IVA so
a parallel set of clockdomain dependencies are
required that are simililar to OMAP3 but without
any IVA dependencies.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add hwmod support for the EMAC (and MDIO)
ethernet controller that's on the am35x
family of SoC's.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
[paul@pwsan.com: updated subject line; updated to apply on v3.5-rc4;
 added comments to hwmod data regarding IPSS]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset:

omap_hwmod: uart4: softreset failed (waited 10000 usec)

This also results in another warning later in the boot process:

omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or disabled state

From empirical observation, the AM35xx UART4 IP block requires either
uart1_fck or uart2_fck to be enabled while UART4 resets.  Otherwise
the reset will never complete.  So this patch adds uart1_fck as an
optional clock for UART4 and adds the appropriate hwmod flag to cause
uart1_fck to be enabled during the reset process.  (The choice of
uart1_fck over uart2_fck was arbitrary.)

Unfortunately this observation raises many questions.  Is it necessary
for uart1_fck or uart2_fck to be controlled with uart4_fck for the
UART4 to work correctly?  What exactly do the AM35xx UART4 clock
tree and the related PRCM idle management FSMs look like?  If anyone
has the ability to answer these questions through empirical functional
testing, or hardware information from the AM35xx designers, it would
be greatly appreciated.

Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kyle Manna <kyle.manna@fuel7.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NMark A. Greer <mgreer@animalcreek.com>

Add missing terminators to the arrays of IRQ, DMA, and address space
structure records in the AM35xx UART4 hwmod data.  Without these
terminators, the following warnings appear on boot:

omap_uart.3: failed to claim resource 58
omap_device: omap_uart: build failed (-16)
WARNING: at /home/paul/linux/arch/arm/mach-omap2/serial.c:375 omap_serial_init_port+0x198/0x284()
Could not build omap_device for omap_uart: uart4.

Also, AM35xx uart4_fck has an incorrect parent clock pointer.  Fix it
and clean up a whitespace issue.

Fix some incorrectly-named macros related to AM35xx UART4.

Cc: Kyle Manna <kyle.manna@fuel7.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NMark A. Greer <mgreer@animalcreek.com>

Partially fix the hwmod data for the AM35xx USB OTG hwmod.  This
should resolve the following boot warning on AM35xx platforms:

omap_hwmod: am35x_otg_hs: cannot be enabled for reset (3)

While here, also fix the clkdev records, to avoid warnings about
duplicate clock aliases.

The hwmod is also connected to the wrong interconnect.  It should be
connected to the IPSS, not the L4 CORE.  But that is left for a future
fix, since it probably has a dependency on some hwmod core changes.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Hema HK <hemahk@ti.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NMark A. Greer <mgreer@animalcreek.com>

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>

The beagleboard USB Host Port that is used is Port 2. The platform driver
sets MODE_PHY for port 1 causing pin muxing to override the pins on the
expansion connector P17 when using board_mux[]. Since USBHS Port 1 is not
connected remove the case for muxing the USB Port1 pins by default.

Tested with BeagleBoard xM revC and checked the userguides for Beagle xM
and revC to be sure USB Port2 is what is used.
Signed-off-by: NBrian Austin <brian.austin@cirrus.com>
Acked-by: NRuss Dill <Russ.Dill@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

If the kernel is built only for OMAP2 the following warning will show up:

arch/arm/mach-omap2/twl-common.c:52: warning: ‘twl_set_voltage’ defined but not used
arch/arm/mach-omap2/twl-common.c:58: warning: ‘twl_get_voltage’ defined but not used

The twl_set/get_voltage callbacks only used when OMAP3/4 is selected.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

In case a board provides the gpio_pendown and not board_pdata,
the GPIO debounce is not taken care of.
Fix this by taking care of GPIO debounce in any case.
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NTony Lindgren <tony@atomide.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>

The TWL driver has been converted to use SPARSE_IRQ and no longer
needs to be passed IRQ base/end.  Since driver no longer uses these
fields, so remove them from the reamaining users.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Commit 9fa2df6b
(ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not present)
makes the logic:
for (i = 0; i < opp_def_size; i++) {
	<snip>
	if (!oh || !oh->od) {
		<snip>
		continue;
	}
<snip>
opp_def++;
}

In short, the moment we hit a "Bad OPP", we end up looping the list
comparing against the bad opp definition pointer for the rest of the
iteration count. Instead, increment opp_def in the for loop itself
and allow continue to be used in code without much thought so that
we check the next set of OPP definition pointers :)

Cc: Steve Sakoman <steve@sakoman.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: stable@vger.kernel.org
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.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>

prcm_setup_regs() blindly accesses IVA bits
in the PRM and calls omap3_iva_idle() which
does more IVA related register accesses.
Only do this if the IVA hardware actually
exists.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NKevin Hilman <khilman@ti.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>

The omapdss arch initialization code registers all the output devices as
omap_devices. However, DPI and SDI are not proper omap_devices, as they
do not have any corresponding HWMOD. This leads to crashes or problems
when the platform code tries to use omap_device functions for DPI and
SDI devices.

One such crash was reported by John Stultz <johnstul@us.ibm.com>:

[   18.756835] Unable to handle kernel NULL pointer dereference at
virtual addr8
[   18.765319] pgd = ea6b8000
[   18.768188] [00000018] *pgd=aa942831, *pte=00000000, *ppte=00000000
[   18.774749] Internal error: Oops: 17 [#1] SMP ARM
[   18.779663] Modules linked in:
[   18.782836] CPU: 0    Not tainted  (3.5.0-rc1-dirty #456)
[   18.788482] PC is at _od_resume_noirq+0x1c/0x78
[   18.793212] LR is at _od_resume_noirq+0x6c/0x78
[   18.797943] pc : [<c00307ec>]    lr : [<c003083c>]    psr: 20000113
[   18.797943] sp : ec3abe80  ip : ec3abdb8  fp : 00000006
[   18.809936] r10: ec1148b8  r9 : c08a48f0  r8 : c00307d0
[   18.815368] r7 : 00000000  r6 : 00000000  r5 : ec114800  r4 :
ec114808
[   18.822174] r3 : 00000000  r2 : 00000000  r1 : ec154fe8  r0 :
00000006
[   18.829010] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment user
[   18.836456] Control: 10c5387d  Table: aa6b804a  DAC: 00000015
[   18.842437] Process sh (pid: 1139, stack limit = 0xec3aa2f0)
[   18.848358] Stack: (0xec3abe80 to 0xec3ac000)

DPI and SDI can be plain platform_devices. This patch changes the
registration from omap_device_register() to platform_device_add().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NJohn Stultz <johnstul@us.ibm.com>
Tested-by: NJean Pihet <jean.pihet@newoldbits.com>

The commit (bce492c0  ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads were used in
different mode by any other module then it would fail since the default
pads took over all the uart pins forcefully. With removal of default pads
the rx_pad wakeup for console uart while waking up from off mode is broken.

Utilise the mux api available to probe the availability of mux pins
in uart mode and probe for availability of uart pin in mux mode0
if uart is available as uart pin itself then configure rx pin
as wakeup capable.

This patch itself doesn't cater to all boards. Boards using uart rx wakeup
mechanism should ensure the usage of omap_serial_init_port by configuring
required uart ports and pass necessary mux data, till then this probing of
uart pins can cater to enabling of rx pad wakeup to most of the boards.

This patch can also throw some boot warning from _omap_mux_get_by_name
if pin is requested for availability is not present while dynamically probing
the uart pins availability such boot warnings can be addressed only when board
files are patched with omap_serial_init_port calls passing the right pads
needed for a given port.

Discussion Threads for reference:
http://www.spinics.net/lists/linux-omap/msg69859.html
http://www.spinics.net/lists/linux-omap/msg68659.html

Cc: Felipe Balbi <balbi@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Russ Dill <russ.dill@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Ameya Palande <ameya.palande@ti.com>
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
[tony@atomide.com: updated to fix compile when CONFIG_OMAP_MUX is not set]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 3b511201 (ARM: OMAP: rx51: Platform support for lis3lv02d accelerometer)
added support for lis3lv02d accelerometer.

The patch was still using OMAP_GPIO_IRQ which no longer exists.

Fix it by using gpio_to_irq().
Signed-off-by: NTony Lindgren <tony@atomide.com>

Use the more generic SoC family soc_is_am35xx() instead of the specific
cpu_is_omap3517() (which is being removed.)
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NMark A. Greer <mgreer@animalcreek.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

This patch adds a simple BCH ecc computation api, similar to the
existing Hamming ecc api. It is intended to be used by the MTD layer.
It implements the following features:

- support 4-bit and 8-bit ecc computation
- do not protect user bytes in spare area, only data area is protected
- ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs

This last feature is obtained by adding a constant polynomial to
the hardware computed ecc. It allows to correct bitflips in blank pages
and is extremely useful to support filesystems such as UBIFS, which expect
erased pages to contain only 0xFFs.

This api has been tested on an OMAP3630 board.

Artem: The OMAP maintainer Tony Lindgren gave us his blessing for merging
this patch via the MTD tree.
Signed-off-by: NIvan Djelic <ivan.djelic@parrot.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Sparse found out that hwspinlocks_init() wasn't marked static,
and it should've been.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>

Irq and clock names were wrong for dsp iommu configuration
for omap4.

- Renamed tesla_ick to dsp_fck:
   This is required because the new naming convention introduced
   by: commit 0e433271 "OMAP4 clock: Fix clock names and align
   with hwmod names"

- Renamed INT_44XX_DSP_MMU to OMAP44XX_IRQ_TESLA_MMU.
   Naming convention adopted since: commit e927f8d0 "omap4: Add
   auto-generated irq and dma headers"

- dsp-iommu is enabled by default.
Signed-off-by: NJuan Gutierrez <jgutierrez@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>