msm: acpuclock: Fix acpuclk_data null pointer dereference

If acpuclk_data is null, dereferencing it in acpuclk_get_switch_time
causes a kernel panic.  Add pointer check to fix that.

Change-Id: I69b92671c8cf26cb45ec8f1193c147be2ebe4c16
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
thermal: tsens: Add redundant fuse map support

Add redundant fuse map for 8x10. Redundant fuse
selection is read to check if the tsens
efuse bits are to be read from the redundant region
instead of reading it from the primary region.

Change-Id: Ia57102b991b435e67ba347b385dc190df430d4d6
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
thermal: qpnp-adc-tm: Reduce kernel log flood

Modify the pr_err log that is used for checking if
clients have a valid callback when threshold request
is made to pr_debug. Currently kernel logs are getting
flooded due to periodic request made from the client.

Change-Id: I74bf4115bc25396da16a96ad7378ba3a7375710f
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
msm: thermal: Set vdd restriction initialize level to -1

Currently the init level is set to 0(enabled), but at this point of
time, the actual voltage is not being set yet. If the device boots
up in low temp, it will try to set level to 0(enabled) again. Since
it will check the level against with previous level which is also
0(means enabled), it will not set the actual voltage/frequency for
the rails.

Set the init level to -1(disabled), so that when device defaults to
enable vdd restriction, it will actually set the voltage.

Change-Id: I9997245953c9947889a813901032c3df8c737ad3
Signed-off-by: Jennifer Liu <chihning@codeaurora.org>
thermal: tsens: Fix invalid set temperature check

When setting a temperature value of 0 there is an error
because of an invalid check. Remove this check.

Change-Id: Iefb348aad5e2ebe8a3c6e9b39a25cb6f284abf6d
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>

Conflicts:

	drivers/thermal/msm8974-tsens.c
thermal: tsens: Fix calibration mask for 8x26

Fix two point calibration mask for obtaining
offsets.

Change-Id: I851a52c2f208559dba2f1ee52630366a21ab9456
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
msm: vidc: Fix the filled length for flushed buffers

For the buffers which are flushed internally in the driver,
the filled length should be set to zero. This change fixes
the same.

Change-Id: I21553c7812e2c15af14097f5562dbc8e68107506
CRs-Fixed: 513940
Signed-off-by: Praneeth Paladugu <ppaladug@codeaurora.org>
msm: vidc: Add support for H.264 LEVEL 5.2

For high resolutions and bit rates, H.264 spec
defined new level. This change adds support to
pass LEVEL 5.2 to FW.

Change-Id: I2298989734450a4f5eee285326afacc4a0836b41
Signed-off-by: Praneeth Paladugu <ppaladug@codeaurora.org>
msm: vidc: Fix a race condition with core instances list

All list operations for core instances list needs to be
protected by mutex. Add mutex for the same.While adding
the new instance to the core instances list, the list
needs to be protected by mutex. This is protected by
incorrect mutex.Fix an issue to acquire proper mutex.

Change-Id: Ibbb11678881fb5d63ce4161fcb4fcd317ddf3259
Signed-off-by: Praneeth Paladugu <ppaladug@codeaurora.org>
writeback: put unused inodes to LRU after writeback completion

Commit 169ebd90131b ("writeback: Avoid iput() from flusher thread")
removed iget-iput pair from inode writeback.  As a side effect, inodes
that are dirty during iput_final() call won't be ever added to inode LRU
(iput_final() doesn't add dirty inodes to LRU and later when the inode
is cleaned there's noone to add the inode there).  Thus inodes are
effectively unreclaimable until someone looks them up again.

The practical effect of this bug is limited by the fact that inodes are
pinned by a dentry for long enough that the inode gets cleaned.  But
still the bug can have nasty consequences leading up to OOM conditions
under certain circumstances.  Following can easily reproduce the
problem:

  for (( i = 0; i < 1000; i++ )); do
    mkdir $i
    for (( j = 0; j < 1000; j++ )); do
      touch $i/$j
      echo 2 > /proc/sys/vm/drop_caches
    done
  done

then one needs to run 'sync; ls -lR' to make inodes reclaimable again.

We fix the issue by inserting unused clean inodes into the LRU after
writeback finishes in inode_sync_complete().

Signed-off-by: Jan Kara <jack@suse.cz>
Reported-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: <stable@vger.kernel.org>		[3.5+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Conflicts:

	fs/fs-writeback.c
bdi: allow block devices to say that they require stable page writes

This patchset ("stable page writes, part 2") makes some key
modifications to the original 'stable page writes' patchset.  First, it
provides creators (devices and filesystems) of a backing_dev_info a flag
that declares whether or not it is necessary to ensure that page
contents cannot change during writeout.  It is no longer assumed that
this is true of all devices (which was never true anyway).  Second, the
flag is used to relaxed the wait_on_page_writeback calls so that wait
only occurs if the device needs it.  Third, it fixes up the remaining
disk-backed filesystems to use this improved conditional-wait logic to
provide stable page writes on those filesystems.

It is hoped that (for people not using checksumming devices, anyway)
this patchset will give back unnecessary performance decreases since the
original stable page write patchset went into 3.0.  Sorry about not
fixing it sooner.

Complaints were registered by several people about the long write
latencies introduced by the original stable page write patchset.
Generally speaking, the kernel ought to allocate as little extra memory
as possible to facilitate writeout, but for people who simply cannot
wait, a second page stability strategy is (re)introduced: snapshotting
page contents.  The waiting behavior is still the default strategy; to
enable page snapshotting, a superblock flag (MS_SNAP_STABLE) must be
set.  This flag is used to bandaid^Henable stable page writeback on
ext3[1], and is not used anywhere else.

Given that there are already a few storage devices and network FSes that
have rolled their own page stability wait/page snapshot code, it would
be nice to move towards consolidating all of these.  It seems possible
that iscsi and raid5 may wish to use the new stable page write support
to enable zero-copy writeout.

Thank you to Jan Kara for helping fix a couple more filesystems.

Per Andrew Morton's request, here are the result of using dbench to measure
latencies on ext2:

3.8.0-rc3:
   Operation      Count    AvgLat    MaxLat
   ----------------------------------------
   WriteX        109347     0.028    59.817
   ReadX         347180     0.004     3.391
   Flush          15514    29.828   287.283

  Throughput 57.429 MB/sec  4 clients  4 procs  max_latency=287.290 ms

3.8.0-rc3 + patches:
   WriteX        105556     0.029     4.273
   ReadX         335004     0.005     4.112
   Flush          14982    30.540   298.634

  Throughput 55.4496 MB/sec  4 clients  4 procs  max_latency=298.650 ms

As you can see, for ext2 the maximum write latency decreases from ~60ms
on a laptop hard disk to ~4ms.  I'm not sure why the flush latencies
increase, though I suspect that being able to dirty pages faster gives
the flusher more work to do.

On ext4, the average write latency decreases as well as all the maximum
latencies:

3.8.0-rc3:
   WriteX         85624     0.152    33.078
   ReadX         272090     0.010    61.210
   Flush          12129    36.219   168.260

  Throughput 44.8618 MB/sec  4 clients  4 procs  max_latency=168.276 ms

3.8.0-rc3 + patches:
   WriteX         86082     0.141    30.928
   ReadX         273358     0.010    36.124
   Flush          12214    34.800   165.689

  Throughput 44.9941 MB/sec  4 clients  4 procs  max_latency=165.722 ms

XFS seems to exhibit similar latency improvements as ext2:

3.8.0-rc3:
   WriteX        125739     0.028   104.343
   ReadX         399070     0.005     4.115
   Flush          17851    25.004   131.390

  Throughput 66.0024 MB/sec  4 clients  4 procs  max_latency=131.406 ms

3.8.0-rc3 + patches:
   WriteX        123529     0.028     6.299
   ReadX         392434     0.005     4.287
   Flush          17549    25.120   188.687

  Throughput 64.9113 MB/sec  4 clients  4 procs  max_latency=188.704 ms

...and btrfs, just to round things out, also shows some latency
decreases:

3.8.0-rc3:
   WriteX         67122     0.083    82.355
   ReadX         212719     0.005     2.828
   Flush           9547    47.561   147.418

  Throughput 35.3391 MB/sec  4 clients  4 procs  max_latency=147.433 ms

3.8.0-rc3 + patches:
   WriteX         64898     0.101    71.631
   ReadX         206673     0.005     7.123
   Flush           9190    47.963   219.034

  Throughput 34.0795 MB/sec  4 clients  4 procs  max_latency=219.044 ms

Before this patchset, all filesystems would block, regardless of whether
or not it was necessary.  ext3 would wait, but still generate occasional
checksum errors.  The network filesystems were left to do their own
thing, so they'd wait too.

After this patchset, all the disk filesystems except ext3 and btrfs will
wait only if the hardware requires it.  ext3 (if necessary) snapshots
pages instead of blocking, and btrfs provides its own bdi so the mm will
never wait.  Network filesystems haven't been touched, so either they
provide their own wait code, or they don't block at all.  The blocking
behavior is back to what it was before 3.0 if you don't have a disk
requiring stable page writes.

This patchset has been tested on 3.8.0-rc3 on x64 with ext3, ext4, and
xfs.  I've spot-checked 3.8.0-rc4 and seem to be getting the same
results as -rc3.

[1] The alternative fixes to ext3 include fixing the locking order and
page bit handling like we did for ext4 (but then why not just use
ext4?), or setting PG_writeback so early that ext3 becomes extremely
slow.  I tried that, but the number of write()s I could initiate dropped
by nearly an order of magnitude.  That was a bit much even for the
author of the stable page series! :)

This patch:

Creates a per-backing-device flag that tracks whether or not pages must
be held immutable during writeout.  Eventually it will be used to waive
wait_for_page_writeback() if nothing requires stable pages.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Ron Minnich <rminnich@sandia.gov>
Cc: Latchesar Ionkov <lucho@ionkov.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
writeback: remove unused bdi_pending_list

There's no user left.  Remove it.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Fengguang Wu <fengguang.wu@intel.com>
writeback: Do not sort b_io list only because of block device inode

It is very likely that block device inode will be part of BDI dirty list
as well. However it doesn't make sence to sort inodes on the b_io list
just because of this inode (as it contains buffers all over the device
anyway). So save some CPU cycles which is valuable since we hold relatively
contented wb->list_lock.

Signed-off-by: Jan Kara <jack@suse.cz>

Conflicts:

	include/linux/fs.h
msm: mdss: Fix NULL pointer dereference in mdss_mdp_display_wait4comp

Add sanity check for ctl to prevent NULL pointer dereference
leading to kernel panic.

CRs-Fixed: 578595
Change-Id: Iace727501856d9f93ba87eca92f9f000c32d2c8f
Signed-off-by: Jayant Shekhar <jshekhar@codeaurora.org>
Linux 3.4.73
mdnie lite control: adjust calibration