staging: ion: Add source of allocated page

It might be useful for higher levels in the call chain to know whether a
page came from the page pool or from the buddy allocator. If a page came
from the page pool we know that the page has been zeroed already and we
do not have to do that again.

Change-Id: I849591a56e5af8a5bc4340bff70f23e3702e62fb
CRs-fixed: 660049
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
staging: ion: Add GFP_NO_KSWAPD flag to high order allocations

When allocating from system heap we try higher order allocations first
before falling back on lower allocations. However, we do not want to
incur much overhead by doing the fallback. So don't try to run kswapd
during these allocation attempts.

CRs-fixed: 660049
Change-Id: I80895c456c80342cc3b2100470dfd9550c81bd29
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
msm: rq_stats: Use cpufreq API to get the current frequency

Since the acpuclock APIs are deprecated, use the cpufreq to
get the current frequency of CPUs to calculate the cpu
normalized load value.

Change-Id: I6e381d584d6725ef964bad86c835d44f3046e9c3
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
msm: rq_stats: Fix wrong usage of cpufreq_quick_get()

cpufreq_quick_get() returns frequency in KHz, which is exactly what
cur_freq expect. Remove the wrong multiplication.

CRs-fixed: 645518
Change-Id: Ia8b080a188023964f5eee77c8586828097d11ad4
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
msm: rq_stats: update related_cpus in the cpu_load runtime

"related_cpu" indicates the list of CPUs that need some
sort of frequency coordination, whether software or hardware.
ex:- if all cpus shares the same clock, all 4 cpus belongs to
related_cpus.

cpufreq driver updates the related_cpus during hotplug offline/online
events. Hence update related_cpus for all cpus during hotplug notifier.

CRs-fixed: 548631
Change-Id: I6543ddaeebf73d18334066b090ee7c4a72466e4a
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
msm: rq_stats: Calculate load based on current freq limit

Prior to this patch, load has been calculated based on an
initial value of policy.cpuinfo.max_freq. This value may
change for several reasons: userspace settings or thermal
throttling (hello hammerhead!). This results in unreliable
calculations that confuse mpdecision which accesses
/sys/devices/system/cpu/cpu0/rq-stats/* for stats info.
Consider current policy.max to fix this behaviour.

Change-Id: Iae1f2fc7f4aa470f7e80371c1ebcf7be423f51ca
cpufreq: cpu-boost: Readd missing bits

The cpufreq patch series was somehow out of sync and
incomplete. Readd the unchanged policy update to source cpu
bit and readd the check for a possible corner case in
try_to_wake_up() that was already missing before.

Change-Id: I1468c47761dee00559631b0a7fd0e14726318b33
cpufreq: interactive: Optimize sync_freq implementation

Don't let frequency drop below sync_freq if either load or
frequency among other cpus is above a certain threshold,
not necessarily both.

Change-Id: Iada28e08e812498e16d5189b309a7314f88814dd
mmc: sdhci: Poll for register status much tightly

On fast path, waiting for 1ms interval to poll registers cause
performance degradation. Also having 1ms delays for polling with
interrupts disabled cause considerable system latencies, hence
poll at 1us interval.

Change-Id: I40113ccf56050b3c46604112846e9b37b254d2be
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
mmc: core: fix block request queue hang during data crc errors

When data CRC errors occur during write transactions, mmc
block layer queries the card for successful writes. If the card
reports bytes requested as bytes successfully written, the mmc
block layer will end the request with blk_end_request(). If there
is a following async request pending for execution, the request
is thrown away while handling CRC errors leading to hang in
request queue. The hang is visible when user issues a sync()
system call.

The sequence of events are as follows -

mmcqd -> fetch a request -> send it to host driver -> fetch another
request -> wait for previous request to complete -> previous request
is in error -> skip sending current request to host driver and
do error handling for previous request in error.

During the last step, after error handling is completed the mmc
block layer does not requeue the current request which is skipped
and hence the request is infinitely stuck in the driver.

Change-Id: I9528fbe3ccb5b723fcd0793f86cca43906c4c29c
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: sdhci-msm: Correct usage of readl_poll_timeout() API

The intention of sdhci_msm_probe() was to wait up to 1ms for
CORE_SW_RST to be set, but only a 10us timeout was passed to
readl_poll_timeout().

Correct the timeout value to be 1ms, and decrease the sleep
time between read attempts to only 10us so that it's less
than the expected wait time of 40us.

Change-Id: I7007a68232bfba76409e2dbae3060622fa5c1913
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Merge branch 'cm-11.0' of https://github.com/CyanogenMod/android_kernel_samsung_hlte into kk4.4