USB Fast Charge for Nexus 5

Increases input current limit to 900mA when charging via USB.
This patch does not force AC mode because this device is capable
of a charging at a much higher current limit than some USB ports
are able to deliver.

Signed-off-by: flar2 <asegaert@gmail.com>

Removed info to get less spam in log

Signed-off-by: engstk <eng.stk@sapo.pt>

Conflicts:
	drivers/power/bq24192_charger.c
defconfig: USB Fast Charge

Signed-off-by: engstk <eng.stk@sapo.pt>
lower GPU volt constraints a bit

Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
gpiomux-8974: Modify direction of suspended GPIO

changed the direction and strength for some below mentioned GPIOs
as per 8974 suggested GPIO settings in Rockbottom.
With new config 0.400-0.500mA been saved on floor in Audio
use case.
Settings are applicable when there is no user to GPIOs
Following are the changes made:
	GPIO# Changed       What Changed
	24                  IN->OUT 8mA->2mA
	46                  IN->OUT 8mA->2mA
	80                  8mA->2mA
	82                  IN->OUT 8mA->2mA
	104                 IN->OUT 8mA->2mA PD->NO PULL
	105                 IN->OUT 8mA->2mA
	106                 IN->OUT 8mA->2mA

Change-Id: Iaedc91b3d696a588e0723ffb495be179c7e0ae6c
Signed-off-by: Tirtha Kanti Ghosh <tirtha@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
net: loopback: set default mtu to 64K

loopback current mtu of 16436 bytes allows no more than 3 MSS TCP
segments per frame, or 48 Kbytes. Changing mtu to 64K allows TCP
stack to build large frames and significantly reduces stack overhead.

Performance boost on bulk TCP transferts can be up to 30 %, partly
because we now have one ACK message for two 64KB segments, and a lower
probability of hitting /proc/sys/net/ipv4/tcp_reordering default limit.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
arm/dt: msm8974: Increase "ib" values for VIDC DDR bandwidth request

As per the recommendation by performance team, update the
"ib" values for DDR BW requests. This change fixes the
display under-runs seen during video playback.

Change-Id: I137814c82b257b8c751dab9df4f705e43fd5643e
Signed-off-by: Vinay Kalia <vkalia@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
ARM: dts: msm: increase adsp heap size for msm8974

For hevc hybrid codec, adsp heap size needs to be increased to
64MB to support 1080p video.

Change-Id: I3812cc2f0204f18fbade9ae41d8e784909055569
Signed-off-by: Arun Menon <avmenon@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
msm: kgsl: Allow GPU start to run in a high priority queue

The GPU start sequence needs to run with low latency when coming
out of slumber for the first draw command. For those cases allow the
start function to be queued into a high priority workqueue to reduce
the chance of it getting scheduled out.

Change-Id: Ic0dedbada7ef4d63b54e826862fbefdfb71a092a
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
msm: kgsl: Add an input handler to power up the GPU on a touch event

On a device where the primary input is a touchscreen nobody is
surprised that touch events are often the catalyst for drawing
frames. If the GPU is in slumber we can get a jump on the action
by watching for touch events and turning the GPU on in anticipation
of a draw call. Register for events from all input drivers
returning EV_ABS events and queue a work task to power up the GPU
if it is currently in slumber.

Change-Id: Ic0dedbadbdc96ef9ddd78252ea65f8e1cdd00110
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
ext4: fix memory leak in xattr

If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations.  If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.

Spotted with Coverity.

[ Fixed by tytso to set is and bs to NULL after freeing these
  pointers, in case in the retry loop we later end up triggering an
  error causing a jump to cleanup, at which point we could have a double
  free bug. -- Ted ]

Change-Id: I49b8ca41a6c6d44b563eb23306870258a3affd3b
Signed-off-by: Dave Jones <davej@fedoraproject.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Cc: stable@vger.kernel.org
Git-commit: 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
ARM: dts: msm: Increase OCMEM BW request for video decode

There are framedrops observed on high bitrate clips because
OCMEM BW is not sufficient for these clips. Increase OCMEM BW
to avoid framedrops.

Change-Id: I7f3238036259e43a12899f2f7c73318328ae8eca
CRs-fixed: 571634
Signed-off-by: Vinay Kalia <vkalia@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
msm: kgsl: Fix nice level for higher priority GPU start thread

Before, we were actually setting the lowest possible priority.

Change-Id: I3a52de949eee0faea8061dd91ed303fa8231f0d4

Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>