Optimize slub
smb347-charger.c: host mode charging patch
minor changes to ondemand
defconfig: update for otg charging and variant info display
Revert " arm: tegra: usb: phy: fix hotplug function"

This reverts commit 497c9ebd8b43cc7da9783d9081fbae7de7a71de2.
fsl_udc: remove debug message
tegra3_dvfs.c: voltage fixes
sched_fair.c: tweak cfs parameters
ARM: tegra: clock: Adjust Tegra3 cpu to emc ratio
On Tegra3 changed cpu rate threshold for maximum emc rate request from
750MHz to 925MHz. Adjusted cpu frequency table to provide entries close
to the new threshold for all Tegra3 skus.
ARM: tegra: clock: Share Tegra3 camera EMC bandwidth

Change Tegra3 camera EMC shared user mode from SHARED_FLOOR to
SHARED_BW and combine requests from ISO clients (camera and display,
which is already in SHARED_BW mode).

Bug 652739

Signed-off-by: Alex Frid <afrid@nvidia.com>
(cherry picked from commit f1107ea4fe229d9807c1fba79a003753d0a8be7f)

Change-Id: If5b7f578060a646df1794dde8c9be2944d88e942
Reviewed-on: http://git-master/r/103498
Reviewed-by: Automatic_Commit_Validation_User
Tested-by: Aleksandr Frid <afrid@nvidia.com>
Reviewed-by: Jon Mayo <jmayo@nvidia.com>
GVS: Gerrit_Virtual_Submit

Conflicts:

	arch/arm/mach-tegra/tegra3_clocks.c
ARM: tegra: clock: Account for memory BW efficiency

Account for memory efficiency when processing requests from Tegra3
EMC shared bandwidth users. Do not round requests from these users
until they are aggregated.

The respective debugfs node: /d/tegra_emc/efficiency (in %).

Bug 952739

Signed-off-by: Alex Frid <afrid@nvidia.com>
(cherry picked from commit 86929087f68c4366d6179101eb9a6a6473a4f084)

Change-Id: I4acdd89f44de1401ce5dad8fc4936932df014458
Reviewed-on: http://git-master/r/103499
Reviewed-by: Automatic_Commit_Validation_User
Tested-by: Aleksandr Frid <afrid@nvidia.com>
Reviewed-by: Jihoon Bang <jbang@nvidia.com>
Reviewed-by: Jon Mayo <jmayo@nvidia.com>
GVS: Gerrit_Virtual_Submit
ARM: tegra: clock: Add locked version of round rate

Add locked version of round rate API to be used by tegra arch
specific layer.

Signed-off-by: Alex Frid <afrid@nvidia.com>
(cherry picked from commit 457627966b91f2141439812869adc4acf9242471)

Change-Id: Id68d0bb952d1e7d9e650341872d1b06b0b2d3cea
Reviewed-on: http://git-master/r/100474
Reviewed-by: Automatic_Commit_Validation_User
Tested-by: Aleksandr Frid <afrid@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
tegra3_dvfs.c: revert voltage and dvfs table changes for g cores
revert to stock voltages and dvfs table based on stock 1.5Ghz values for speedo ID 2
ARM: tegra: cpu: enable VDD_CPU rail before LP to G transition
conflict - add decouple mode from flags
When doing LP to G transition, it had a power up latency on VDD_CPU
rail. To reduce the latency, CPU_LP can trun on the VDD_CPU rail
before the LP to G transition.

Bug 930985

Change-Id: I087e185ea5aa90f309b8cafba9bc4bb7d3fc950c
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: http://git-master/r/93141
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Antti Miettinen <amiettinen@nvidia.com>
Tested-by: Antti Miettinen <amiettinen@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Juha Tukkinen <jtukkinen@nvidia.com>

Conflicts:

	arch/arm/mach-tegra/pm.c
kernel:sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire

LOAD_FREQ is (5*HZ+1) to avoid high load average when idle:
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/3/328568

I suggest (4*HZ+61) for a better distribution.

With some seconds based load (like SSL heartbeats)
and LOAD_FREQ at (5*HZ+1) I see Moire patterns like inverse sawtooth,
since 2 or 3 probes hit the jobs (load increases quickly),
followed by several probes missing it.

A 4.61 sec interval gives optimal distribution over when within a
second a probe is taken, as .61 is close to golden ratio phi 1.618...
(test in http://ripke.com/goldenratio.c).

12*4.61 = 55.32 secs is still close to a minute,
and 13*4.61=59.93 is even closer than the current 12*5.01=60.12
(with exponents EXP_x adjusted to a ratio of 13 instead of 12).
ARM: Add optimised swahb32() byteswap helper for v6 and above

ARMv6 and later processors have the REV16 instruction, which swaps
the bytes within each halfword of a register value.

This is already used to implement swab16(), but since the native
operation performaed by REV16 is actually swahb32(), this patch
renames the existing swab16() helper accordingly and defines
__arch_swab16() in terms of it.  This allows calls to both swab16()
and swahb32() to be optimised.

The compiler's generated code might improve someday, but as of
4.5.2 the code generated for pure C implementing these 16-bit
bytesswaps remains pessimal.

swahb32() is useful for converting 32-bit Thumb instructions
between integer and memory representation on BE8 platforms (among
other uses).

Signed-off-by: Dave Martin <dave.martin@xxxxxxxxxx>
Asynchronous I/O latency to a solid-state disk greatly increased
between the 2.6.32 and 3.0 kernels. By removing the plug from
do_io_submit(), we observed a 34% improvement in the I/O latency.

Unfortunately, at this level, we don't know if the request is to
a rotating disk or not.

Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: linux-aio@kvack.org
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
block: recursive merge requests

In my workload, thread 1 accesses a, a+2, ..., thread 2 accesses a+1,
a+3,.... When the requests are flushed to queue, a and a+1 are merged
to (a, a+1), a+2 and a+3 too to (a+2, a+3), but (a, a+1) and (a+2, a+3)
aren't merged.
With recursive merge below, the workload throughput gets improved 20%
and context switch drops 60%.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
cpufreq: update lpj only if frequency has changed

During scaling up of cpu frequency, loops_per_jiffy
is updated upon invoking PRECHANGE notifier.
If setting to new frequency fails in cpufreq driver,
lpj is left at incorrect value.

Hence update lpj only if cpu frequency is changed,
i.e. upon invoking POSTCHANGE notifier.

Penalty would be that during time period between
changing cpu frequency & invocation of POSTCHANGE
notifier, udelay(x) may not gurantee minimal delay
of 'x' us for frequency scaling up operation.

Perhaps a better solution would be to define
CPUFREQ_ABORTCHANGE & handle accordingly, but then
it would be more intrusive (using ABORTCHANGE may
help drivers also; if any has registered notifier
and expect POST for a PRECHANGE, their needs can
be taken care using ABORT)

Signed-off-by: Afzal Mohammed <afzal@ti.com>
Optimized ARM RWSEM algorithm

RWSEM implementation for ARM using atomic functions.
Heavily based on arch/sh/include/asm/rwsem.h

Signed-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>