mach-msm: Use ION_CP_MM_HEAP_ID instead of ION_CAMERA_HEAP_ID

Since some msm7x30 devices can't use ION_CAMERA_HEAP_ID on rom side,
we have to change the ion heap used for video encoding/decoding from
ION_CAMERA_HEAP_ID to ION_CP_MM_HEAP_ID.

On rom side, the following commit must be applied on media-caf side:
http://review.cyanogenmod.org/#/c/62863/
Revert "msm: pm2: Setup memory for save/restore cpu registers early"

This reverts commit d00e920c5b1e7ad50bbc8eb3fe62b66c35903c2b, seems
to be not needed anymore.
msm7x30: Use CMA for MM ION heap

By switching from carveout heap type to DMA heap type for the ION heap
targeting MM features (camcorder, video recording/playback/encoder),
the memory area will be allocated via CMA framework. This heap area is
under system memory space and can be re-allocated when it's not being
used by any client.

The option CONFIG_CMA should be enabled to use this feature.

This commit is based on the following commits:
https://github.com/LegacyXperia/android_kernel_semc_msm7x30/commit/36effbe894be25d3a56dbdd76774757f1afaabbf
https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/?h=jb_rel_2.0.3&id=fc6e1100600fabdaa3a9a15941bd33d06e132557

Thanks to Blefish, Chintan Pandya and mikeNG for them.
msm7x30: Update defconfigs to enable CMA
Squashed update of kernel from 3.4.91 to 3.4.92
mm: try_to_unmap_cluster() should lock_page() before mlocking

CVE-2014-3122

A BUG_ON(!PageLocked) was triggered in mlock_vma_page() by Sasha Levin
fuzzing with trinity.  The call site try_to_unmap_cluster() does not lock
the pages other than its check_page parameter (which is already locked).

The BUG_ON in mlock_vma_page() is not documented and its purpose is
somewhat unclear, but apparently it serializes against page migration,
which could otherwise fail to transfer the PG_mlocked flag.  This would
not be fatal, as the page would be eventually encountered again, but
NR_MLOCK accounting would become distorted nevertheless.  This patch adds
a comment to the BUG_ON in mlock_vma_page() and munlock_vma_page() to that
effect.

The call site try_to_unmap_cluster() is fixed so that for page !=
check_page, trylock_page() is attempted (to avoid possible deadlocks as we
already have check_page locked) and mlock_vma_page() is performed only
upon success.  If the page lock cannot be obtained, the page is left
without PG_mlocked, which is again not a problem in the whole unevictable
memory design.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Conflicts:
	mm/mlock.c

Change-Id: Iba4e59fae240ce8863cf6b7e12d01796619cf677
msm:vidc: Amend error checks on ION API failures

This change will validate the ION API failures
to fix target freeze issues.

Change-Id: I00fee94955ba9f0e72734daccd22aa7d0bf86dda
CRs-fixed: 412958
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
ion: cma: Add debug heap ops for CMA heap

For tracking CMA allocation by address and fragmentation
(if any), add debug heap ops which gives buffer allocation
info.

Change-Id: Ia8bed38034b85b2d4dcf84811a348bbbe50dc16b
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
Squashed update of kernel from 3.4.92 to 3.4.93

This squashed update doesn't include the commits related to
bluetooth drivers. The discarded commits are:
ade988a Bluetooth: Fix missing length checks for L2CAP signalling PDUs
6ec88fc Bluetooth: Fix invalid length check in l2cap_information_rsp()
7f801fc Bluetooth: Support AR3011 in Acer Iconia Tab W500
c2f15c3 Bluetooth: add support for atheros 0930:0219
4126da5 Bluetooth: add support for atheros 0489:e057
a1144ca Bluetooth: Add support for Foxconn/Hon Hai AR5BBU22 0489:E03C
1403b36 Bluetooth: Add support for Sony Vaio T-Series
ec5bf54 Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn
adebaa7 Bluetooth: Add support for BCM20702A0 [04ca, 2003]
4a990f6 Bluetooth: Add support for BCM20702A0 [0b05, 17b5]
3b36e95 Bluetooth: Add support for IMC Networks [13d3:3393]
7a8c99e Bluetooth: Add support for GC-WB300D PCIe [04ca:3006] to ath3k.
340733c Bluetooth: Add support for Foxconn / Hon Hai [0489:e04e]
7a344a22 Bluetooth: Add support for Foxconn / Hon Hai [0489:e056]
e98f05e Bluetooth device 04ca:3008 should use ath3k
d83ff8c Bluetooth: Add support for atheros 04ca:3004 device to ath3k
1a182cc Bluetooth: Device 0cf3:3008 should map AR 3012
2737072 Bluetooth: Add support for Foxconn/Hon Hai [0489:e04d]
5ff1715 Bluetooth: Add support for Mediatek Bluetooth device [0e8d:763f]
61286bc Bluetooth: ath3k: Add support for Fujitsu Lifebook UH5x2 [04c5:1330]
fa6e607 Bluetooth: ath3k: Add support for ID 0x13d3/0x3402
d9b03b2 Bluetooth: Add support for Atheros [0cf3:3121]
ae1c727 Bluetooth: Add support for Atheros [0cf3:e003]
140deab Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.
76b87de Bluetooth: Add support for BCM20702A0 [0b05, 17cb]
mmc: msm_sdcc: Advertise erase capability for ancora

 * Afaik we're not vulnerable to bricks, and this will get
   us working TRIM support.
ancora: Adjust PMEM sizes
gpu: ion: Sync CMA caching logic with carveout heap.

Change-Id: Id759d442a45a54ae6b3410f01a208728cb040a52
defconfigs: Build crypto devices as modules
msm: dma: Moving queue_work() function within spinlock

Currently we are adding a dma command to the staged list with in a
spinlock and then adding to workqueue using queue_work after unlocking
the spinlock. With this there is chance of executing DMA commands in out
of order in below concurrency case.

Tread1                                Thread2
__msm_dmov_enqueue_cmd_ext
   spin_lock_irqsave(..)
   list_add_tail(..)
   spin_unlock_irqrestore(..)
       --PREEMPT--
                                      __msm_dmov_enqueue_cmd_ext
                                         spin_lock_irqsave(..)
                                         list_add_tail(..)
                                         spin_unlock_irqrestore(..)
                                         queue_work()
                                         ..
   queue_work()
So adding queue_work with in spin_lock will make sure that the
work added in the work_queue is processed in the same order as they
are added in staged_commands.

CRs-Fixed: 423190,669409
Change-Id: I2ffd1327fb5f0cd1f06db7de9c026d1c4997fe4d
Acked-by: Gopi Krishna Nedanuri <gnedanur@qti.qualcomm.com>
Signed-off-by: Utsab Bose <ubose@codeaurora.org>
Signed-off-by: Vijay Kumar T M <vtmuni@codeaurora.org>
sched: Reset rq->next_interval before going idle

next_balance, the point in jiffy time scale when a cpu will next load
balance, could have been calculated when the cpu was busy. A busy cpu
will apply its sched domain's busy_factor (usually > 1) in computing
next_balance for that sched domain, which causes the (busy) cpu to load
balance less frequently in its sched domains. However when the same cpu
is going idle, its next_balance needs to be reset without consideration
of busy_factor. Failure to do so would not trigger nohz idle balancer on
that cpu for unnecessarily long time (introducing additional scheduling
latencies for tasks). Fix bug in scheduler which aims to reset
next_balance before a cpu goes idle (as per existing comment) but is
clearly not doing so.

Change-Id: I7e027a51686528c4092d770c7d33c874d38f5df4
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
sched: re-calculate a cpu's next_balance point upon sched domain changes

Commit 55ddeb0f (sched: Reset rq->next_interval before going idle) reset
a cpu's rq->next_balance when pulled_task = 0, which will be true when
the cpu failed to pull any task, causing it go idle. However that patch
relied on next_balance being calculated as a result of traversing cpu's
sched domain hierarchy.

A cpu that is the only online cpu will however not be attached to any
sched domain hierarchy. When such a cpu calls into idle_balance(), we
will end up initializing next_balance to be 1sec away! Such a CPU will
defer load balance check for another 1sec, even though we may bring up
more cpus in the meantime requiring it to check for load imbalance more
frequently. This could then lead to increased scheduling latency for
some tasks.

This patch results in a cpu's next_balance being re-calculated when its
attaching to a new sched domain hierarchy.  This should let cpus call
load balance checks at the right time we expect them to!

Change-Id: I855cff8da5ca28d278596c3bb0163b839d4704bc
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
ARM: 7486/1: sched_clock: update epoch_cyc on resume

Many clocks that are used to provide sched_clock will reset during
suspend.  If read_sched_clock returns 0 after suspend, sched_clock will
appear to jump forward.  This patch resets cd.epoch_cyc to the current
value of read_sched_clock during resume, which causes sched_clock() just
after suspend to return the same value as sched_clock() just before
suspend.

In addition, during the window where epoch_ns has been updated before
suspend, but epoch_cyc has not been updated after suspend, it is unknown
whether the clock has reset or not, and sched_clock() could return a
bogus value.  Add a suspended flag, and return the pre-suspend epoch_ns
value during this period.

The new behavior is triggered by calling setup_sched_clock_needs_suspend
instead of setup_sched_clock.

Change-Id: I7441ef74dc6802c00eea61f3b8c0a25ac00a724d
Signed-off-by: Colin Cross <ccross@android.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
CRs-Fixed: 497236
Git-commit: 237ec6f2e51d2fc2ff37c7c5f1ccc9264d09c85b
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
ARM: 7565/1: sched: stop sched_clock() during suspend

The scheduler imposes a requirement to sched_clock()
which is to stop the clock during suspend, if we don't
do that any RT thread will be rescheduled in the future
which might cause any sort of problems.

This became an issue on OMAP when we converted omap-i2c.c
to use threaded IRQs, it turned out that depending on how
much time we spent on suspend, the I2C IRQ thread would
end up being rescheduled so far in the future that I2C
transfers would timeout and, because omap_hsmmc depends
on an I2C-connected device to detect if an MMC card is
inserted in the slot, our rootfs would just vanish.

arch/arm/kernel/sched_clock.c already had an optional
implementation (sched_clock_needs_suspend()) which would
handle scheduler's requirement properly, what this patch
does is simply to make that implementation non-optional.

Note that this has the side-effect that printk timings
won't reflect the actual time spent on suspend so other
methods to measure that will have to be used.

This has been tested with beagleboard XM (OMAP3630) and
pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
after this patch.

Thanks to Kevin Hilman for helping out with debugging.

Change-Id: Ie2f9e3b22eb3d1f3806cf8c598f22e2fa1b8651f
Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
CRs-Fixed: 497236
Git-commit: 6a4dae5e138a32b45ca5218cc2b81802f9d378c3
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
sched: Set MC (multi-core) sched domain's busy_factor attribute to 1

busy_factor attribute of a scheduler domain causes busy CPUs (CPUs
that are not idle) to load balance less frequently in that domain,
which could impact performance by increasing scheduling latency for
tasks.

As an example, consider MC scheduler domain's attribute values of
max_interval = 4ms and busy_factor = 64. Further consider
max_load_balance_interval = 100 (HZ/10). In this case, a non-idle CPU
could put off load balance check in MC domain by 100ms. This
effectively means that a CPU running a single task in its queue could
fail to notice increased load on another CPU (that is in same MC
domain) for upto 100ms, before picking up load from the overloaded
CPU. Needless to say, this leads to increased scheduling latency for
tasks, affecting performance adversely.

By setting MC domain's busy_factor value to 1, we limit maximum
interval that busy CPU can put off load balance checks to 4ms
(effectively 10ms, given HZ value of 100).

Change-Id: Id45869d06f5556ea8eec602b65c2ffd2143fe060
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
Squashed update of kernel from 3.4.93 to 3.4.94