omap4: hwmod_data: add clocks to ipu processor devices

The ipu processor hwmod devices (ipu_c0 & ipu_c1) are defined
primarily as pseudo-hwmod devices with only reset controls.
These share the same functional clock along with the ipu hwmod
device that is mainly used for controlling the MMU. This clock
name is added to these pseudo-hwmod devices, as it will improve
the robustness to any HW_AUTO settings performed within the
hwmod framework. There is no major effect on the clock framework
itself, as the clock enable & disable will simply be reference
counted and the functionality would be identical as before.

Change-Id: I865e9690b503e601df27aa0a55cfac45622c4259
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: iommu: relax constraint value to allow CSWR

The iommu driver currently requests a latency constraint,
if configured in platform data, on the power domain it is
present in. These values are required only for OMAP4 and
beyond and is done to ensure the AMMU context is maintained
when the corresponding power domain goes to a low power state
during cpuidle path. The AMMU context is retained in CSWR, but
is lost in OSWR.

The current constraint value (10) for OMAP4+ is high and
restricts the power domain to remain in ON state as long as
the processor is active. This value is relaxed to 400 to
allow a lower power CSWR state during cpuidle path.

The context is saved and restored properly when suspending
the remote processor.

Change-Id: I89fd125f2244ae1691843c3c078aa6314a7ae8a6
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

Conflicts:

	arch/arm/mach-omap2/omap-iommu.c
Revert "omap: iommu: relax constraint value to allow CSWR"

This reverts commit 5c6511ea012cc17b8f3c5ad2b449ea36df99e2fa.
omap: iommu: program constraints based on platform data

IOMMU driver requests and releases constraints in iommu_get
and iommu_put respectively. These constraints are actually
needed only on OMAP4 and beyond for sub-systems that have
an AMMU. The current driver code has these values hard-coded
for all the chips.

A new platform data field has been added now for the constraints
values, and this allows the values to be programmed based on
the OMAP chip and also allow a unique value if needed for each
iommu instance.

The logic in IOMMU driver code is adjusted to request the
constraints only if the relevant platform data field is set.

Change-Id: Iab18cbdde1d7fa7507dbff0b9512c8577b42fefd
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: iommu: relax constraint value to allow CSWR

The iommu driver currently requests a latency constraint,
if configured in platform data, on the power domain it is
present in. These values are required only for OMAP4 and
beyond and is done to ensure the AMMU context is maintained
when the corresponding power domain goes to a low power state
during cpuidle path. The AMMU context is retained in CSWR, but
is lost in OSWR.

The current constraint value (10) for OMAP4+ is high and
restricts the power domain to remain in ON state as long as
the processor is active. This value is relaxed to 400 to
allow a lower power CSWR state during cpuidle path.

The context is saved and restored properly when suspending
the remote processor.

Change-Id: I89fd125f2244ae1691843c3c078aa6314a7ae8a6
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: mailbox: add pm constraint field to mbox structure

By adding this field, the pm qos apis can be selectively applied
only if the pm constraint is set to a +ve value.

Change-Id: I3b6930e85f65f7354826813798dec76b25149370
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: mailbox: relax constraint to allow powerdomain to go to CSWR

The mailbox registers can be accessed and configured by other remote
processor initiators, and hence the driver has to be responsible for
maintaining the register context when they are active. This is
achieved by the mailbox driver by requesting a latency constraint
on the power domain that it belongs to.

The current constraint value (10) is high and restricts the power
domain to remain in ON state as long as a remote processor is
active. This value is relaxed to 400 to allow a lower power CSWR
state that can still retain the context during cpuidle path and
a remote processor is active.

The constraint is completely removed when the remote processor is
suspended. The mailbox context is saved and restored properly
when suspending the remote processor.

Change-Id: I152b57e982dc8e5739808cbbbe8bd5cc96223ffa
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
i2c: omap: implement shutdown handler

Once i2c driver shutdown has been called, ignore any more
transfer requests. This patch adds the missing callback.

Leave the PMIC i2c (i2c-1) alive, since power_off case needs it
well after shutdown handlers have been called for power_off case.

Change-Id: I4f4553327e5c024f78acb8501864dd9beb1883c3
Signed-off-by: Semen Protsenko <semen.protsenko@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>

Conflicts:

	drivers/i2c/busses/i2c-omap.c
mm, oom: fix potential killing of thread that is disabled from oom killing

/proc/sys/vm/oom_kill_allocating_task will immediately kill current when
the oom killer is called to avoid a potentially expensive tasklist scan
for large systems.

Currently, however, it is not checking current's oom_score_adj value
which may be OOM_SCORE_ADJ_MIN, meaning that it has been disabled from
oom killing.

This patch avoids killing current in such a condition and simply falls
back to the tasklist scan since memory still needs to be freed.

Signed-off-by: David Rientjes <rientjes@google.com>
modified for TUNA kernel from Linux 3.5+ by faux123

Conflicts:

	mm/oom_kill.c
Revert "i2c: omap: implement shutdown handler"

This reverts commit 2af6128575fef8a20f254ca34b609ce131d1c55e.
Update defconfig, up version numbers, update build script