netfilter: no-loop-parallelize-all in CFLAGS (Linaro Optimisations build fix)

Applied for:
netfilter/nf_conntrack_core.o
netfilter/xt_hashlimit.o
netfilter/ipset/ip_set_hash_ipportip.o
netfilter/ipset/ip_set_hash_ipportnet.o
Dirty port: Bluetooth: kernel 3.4
Makefile: Add Config Variable Os - O2 - O3 for choice Compilation
Makefile optimization for Linaro -o3
OMAP4: cpuidle: don't touch mpu and core state until CPU1 is off

MPU/Core logic and PD states shouldn't be changed until CPU1 is
completely off

Change-Id: Ia90126776e7bd7108c7b885c622df36323982cb0
Signed-off-by: Lianwei Wang <lian-wei.wang@motorola.com>
Signed-off-by: suilunlam <a0868997@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
omap4: cpuidle: Some obvious optimisations to the code path

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
omap44xx: cpuidle: Update target residencies to saner values

The current values are insane.

There is no possible way power saving
can be attained by heading into C4 for not much more than 1ms. The average
values are in the 20ms range, so why do we need to even entertain entering
at much lower values when we will use more power than we save in doing so.

The actual recommended values are shown in 79e796f7b993bd82ad108fa488c35ddd1b9387eb
but for some obscure reason, in 16385c726d55f9e84bbc60ff9e329a84d56a13a3 and
22e2193661b6bffcfdc1a4d17f6af0d1782ba860 they were updated to match the exit_latency.

This seems horribly wrong to me as there comes a point when the target residency is
so low that you use more power actually entering the state than you gain from the
insignificant amount of time you spend there.

With the values in this commit, C4 state is used for >95% of the time when the screen
is off, with C3 picking up the remainder.
During audio playback, C4 is used ~50% of the time, C3 is used ~25% of the time and C2
picks up whatever is left.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
HSMMC:Set disable timeout to 1ms

The disable timeout is reduced from 100ms to 1ms in order
to obtain aggressive power saving.

Cherry picked from p-android-omap-2.6.35 commit ID:
50df9d10a9b33c82ad02003686050b12b03d4dfe

Change-Id: Ieaa47d51396e7b92f6c1ba71e62900c58a05a26c
Signed-off-by: Madhusudhan Chikkature <madhu.cr@ti.com>
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
MMC: OMAP HSMMC: Enable Auto CMD12

Configure OMAP HSMMC module to support Auto CMD12.
This will increase throughput during multi-block
command operations as CMD12 does not have to be
explicitly sent each time by software intervention.
Instead, hardware will send CMD12 after desired
number of blocks are transferred.

Change-Id: I37bf31399c80531d9fd76baa736a59a118c769b0
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
mmc: OMAP HSMMC: Add cmd23 support

Add support for set block count, close ended transfer

Change-Id: Iab7386e1171a42ebdf55306fbf291a3e6dd85b40
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
omap4-hsmmc : Adding ADMA support

Adds ADMA support for HSMMC controllers 1 & 2 on OMAP4
Ensure dma-sg list coming from block layer is unmapped after
every transfer completion.

Change-Id: I1b898f771a3119804920c5cd17ec9c4456c60916
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com>
Signed-off-by: David Taylor <x0158378@ti.com>
mmc: omap: align adma and dma table entries

mmc->max_segs to core layer was set to 1024, but
adma table entry could only hold 512 entries. Increase
adma table entry size to 1024 from 512 to avoid mismatch.

Also set max_blk_count, max_req_size to what adma can
handle.

Change-Id: I8e08ee39bfa966bdf8a6c4374aea82b34fedcc62
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
mmc: omap: Increase number of blks we can handle

The above block layer is doing a "min" of max_req_size
and max_blk_count*512 before submitting each request.

As a result, the maximum size of request we are getting
is only 120*512 = 60KB even though each line in the
ADMA table can handle can handle that data alone.

So, we increase the max_blk_count we can handle. Also,
note that worst case is when above block layer gives
us 512 segments, in which there are 511 single block
entries, but one large block that is of size
mmc->max_req_size - (511*512) bytes.

In this case, we use the reserved 512 table entries
to break up the large request. Also adjust the
max_segs accordingly.

Change-Id: I733effdebea94f51a49bbf323950529afbb00dc4
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
omap-hsmmc: Implementation of i761 errata

Errata description:
Due to a bad behavior of an internal signal, the Card Error interrupt bit
MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the
card response.

Workaround:
After responses of type R1/R1b for all cards and responses of type R5/R5b/R6
for SD and SDIO cards, software must read two registers: MMCHS_RSP10 and
MMCHS_CSRE. When a MMCHS_CSRE[i] bit is set to 1, if the corresponding bit at
the same position in the response MMCHS_RSP10[i] is set to 1, the host
controller indicates a card error and software should proceed in the same way
as if a CERR interrupt would have been detected in the MMCHS_STAT register.

Note:
This errata is applicable for omap44xx.

Change-Id: Ib024bfb0624df04b7d6c61c129cbd9a34f919814
Signed-off-by: Semen Protsenko <semen.protsenko@ti.com>
mmc: OMAP HSMMC: DDR support added.

OMAP HSMMC updated to support DDR mode

Change-Id: Ifb8643e264216edf514a7e31ec989316700ee322
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
mmc: Fix bug to enable DDR on MMC

MMC_CAP_UHS_DDR50 is an SD card feature and not
MMC feature. We don't have to check for this flag
to enable DDR on MMC. Checking for MMC_CAP_1.8V_DDR
is sufficient.

Change-Id: I6f44cb1f4dde6fe70cc816a2119c7b2b90944500
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
cpuset: mm: reduce large amounts of memory barrier related damage v3

commit cc9a6c8776615f9c194ccf0b63a0aa5628235545 upstream.

Stable note:  Not tracked in Bugzilla. [get|put]_mems_allowed() is extremely
	expensive and severely impacted page allocator performance. This
	is part of a series of patches that reduce page allocator overhead.

Commit c0ff7453bb5c ("cpuset,mm: fix no node to alloc memory when
changing cpuset's mems") wins a super prize for the largest number of
memory barriers entered into fast paths for one commit.

[get|put]_mems_allowed is incredibly heavy with pairs of full memory
barriers inserted into a number of hot paths.  This was detected while
investigating at large page allocator slowdown introduced some time
after 2.6.32.  The largest portion of this overhead was shown by
oprofile to be at an mfence introduced by this commit into the page
allocator hot path.

For extra style points, the commit introduced the use of yield() in an
implementation of what looks like a spinning mutex.

This patch replaces the full memory barriers on both read and write
sides with a sequence counter with just read barriers on the fast path
side.  This is much cheaper on some architectures, including x86.  The
main bulk of the patch is the retry logic if the nodemask changes in a
manner that can cause a false failure.

While updating the nodemask, a check is made to see if a false failure
is a risk.  If it is, the sequence number gets bumped and parallel
allocators will briefly stall while the nodemask update takes place.

In a page fault test microbenchmark, oprofile samples from
__alloc_pages_nodemask went from 4.53% of all samples to 1.15%.  The
actual results were

                             3.3.0-rc3          3.3.0-rc3
                             rc3-vanilla        nobarrier-v2r1
    Clients   1 UserTime       0.07 (  0.00%)   0.08 (-14.19%)
    Clients   2 UserTime       0.07 (  0.00%)   0.07 (  2.72%)
    Clients   4 UserTime       0.08 (  0.00%)   0.07 (  3.29%)
    Clients   1 SysTime        0.70 (  0.00%)   0.65 (  6.65%)
    Clients   2 SysTime        0.85 (  0.00%)   0.82 (  3.65%)
    Clients   4 SysTime        1.41 (  0.00%)   1.41 (  0.32%)
    Clients   1 WallTime       0.77 (  0.00%)   0.74 (  4.19%)
    Clients   2 WallTime       0.47 (  0.00%)   0.45 (  3.73%)
    Clients   4 WallTime       0.38 (  0.00%)   0.37 (  1.58%)
    Clients   1 Flt/sec/cpu  497620.28 (  0.00%) 520294.53 (  4.56%)
    Clients   2 Flt/sec/cpu  414639.05 (  0.00%) 429882.01 (  3.68%)
    Clients   4 Flt/sec/cpu  257959.16 (  0.00%) 258761.48 (  0.31%)
    Clients   1 Flt/sec      495161.39 (  0.00%) 517292.87 (  4.47%)
    Clients   2 Flt/sec      820325.95 (  0.00%) 850289.77 (  3.65%)
    Clients   4 Flt/sec      1020068.93 (  0.00%) 1022674.06 (  0.26%)
    MMTests Statistics: duration
    Sys Time Running Test (seconds)             135.68    132.17
    User+Sys Time Running Test (seconds)         164.2    160.13
    Total Elapsed Time (seconds)                123.46    120.87

The overall improvement is small but the System CPU time is much
improved and roughly in correlation to what oprofile reported (these
performance figures are without profiling so skew is expected).  The
actual number of page faults is noticeably improved.

For benchmarks like kernel builds, the overall benefit is marginal but
the system CPU time is slightly reduced.

To test the actual bug the commit fixed I opened two terminals.  The
first ran within a cpuset and continually ran a small program that
faulted 100M of anonymous data.  In a second window, the nodemask of the
cpuset was continually randomised in a loop.

Without the commit, the program would fail every so often (usually
within 10 seconds) and obviously with the commit everything worked fine.
With this patch applied, it also worked fine so the fix should be
functionally equivalent.

Change-Id: Iee6899cd3ed28a491aee41845228e283a379ecbc
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: Miao Xie <miaox@cn.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add UKSM 0.1.2

Signed-off-by: Dan Trifan <jimsth@gmail.com>
UKSM: Upgrade to 0.1.2.2

Signed-off-by: Dan Trifan <jimsth@gmail.com>
power: decrease the amount of time the device waits after entering lower power state - Thanks Franco

Signed-off-by: Dan Trifan <jimsth@gmail.com>