Revert "sioplus: increase sync_read_expire to play nice with backported android memory management"

This reverts commit dcc1bb414c688caa73d1b44282316fb342761516.
sioplus: tweak writes_tarved for new memory updates
Fancy Kernel r47
Revert "sioplus: tweak writes_tarved for new memory updates"

This reverts commit 6900fb4f27a68c5da223c744cbb30bc304c2f387.
Fancy Kernel r48
tuna: wifi: revert startup delay to 70 msec
omap: iommu: apply latency constraint based on power domain

When the iommu is taken out of reset, a latency constraint is
set to avoid its power domain going to retention/off. The iommus
for DSP and M3 reside in DSP and Core power domains respectively,
and therefore the API for setting the constraints is different.
This patch uses the appropriate API depending on the iommu (power
domain) the latency constraint is being applied on.

Change-Id: I3fa4485b3c405aa10c32a3fe0b7ac694d484ee21
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
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>
[IVAHD] Disable HWSUP mode and save power
Enabling HWSUP mode is somehow reducing the performance
of SL2 memory leading to increase in power consumption.
This patch disables it and advertises only SWSUP mode
which seems to improve performance and reduce power
consumed in AV record use-case.

Change-Id: Ie7d06b2a7a8d251820afd63bbb093fa34203c3fa
Signed-off-by: Sundar Raman <sunds@ti.com>
OMAPDSS: DISPC: Use FIR filters other than M19

Pass correct arguments to FIR filter selection.  Previously we
always ended up selecting M19 5-tap filter.

This should improve image quality of scaled layers.

Change-Id: Iabe3219df7dcfd62c713fd92ee9c3d12221bc382
Signed-off-by: Lajos Molnar <lajos@ti.com>
ARM: Add init_consistent_dma_size()

This function can be called during boot to increase the size of the consistent
DMA region above it's default value of 2MB. It must be called before the memory
allocator is initialised, i.e. before any core_initcall.

Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

Conflicts:
	arch/arm/include/asm/dma-mapping.h
ARM: Remove support for macro CONSISTENT_DMA_SIZE

There are now no platforms which set this macro.

Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
arm: Increase the DMA consistent memory zone to 4MB

Increase the zone for mapping DMA memory on most platforms from 2MB
to 4 MB. The actual memory comes from the normal pool, this
change just increases the virtual range where the memory can be mappped
(at the cost of 1 more 2MB pagetable).
Fancy Kernel r49