touchscreen: tweak some initialization parameters for better UI response

Signed-off-by: faux123 <reioux@gmail.com>
proc: enhance time-average nr_running stats

Add time-average nr_running to loadavg printout

Bug 958978

Change-Id: I5c6904efb52a86f4964eb66c1576fc91f60f5b1d
Signed-off-by: Alex Frid <afrid@nvidia.com>
(cherry picked from commit 86f3642cc44a69d1e4798719bd9182cd6923f526)
Reviewed-on: http://git-master/r/111636
Reviewed-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Tested-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
From 18bc095e952d31d5e07b88b8b89fb2ae8c3048ad Mon Sep 17 00:00:00 2001
From: Arianna Avanzini <avanzini.arianna@gmail.com>
Date: Sat, 4 Feb 2012 10:55:51 +0100
Subject: [PATCH 1/2] block: cgroups, kconfig, build bits for BFQ-v5r1-3.4

Update Kconfig.iosched to include kernel configuration options
for BFQ. Add a Kconfig option and do the related Makefile changes
to compile the scheduler. Also let the cgroups subsystem know about
the BFQ I/O controller.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
rom 2ebfcb6f325e27261c80a5c3b3a9e9e5ba3749a8 Mon Sep 17 00:00:00 2001
From: Arianna Avanzini <avanzini.arianna@gmail.com>
Date: Sun, 5 Feb 2012 01:04:27 +0100
Subject: [PATCH 2/2] block: introduce the BFQ-v5r1 I/O sched for 3.4

Add the BFQ-v5r1 I/O scheduler to 3.4.
The general structure is borrowed from CFQ, as much code. A (bfq_)queue is
associated to each task doing I/O on a device, and each time a scheduling
decision has to be taken a queue is selected and it is served until it expires.

    - Slices are given in the service domain: tasks are assigned budgets,
      measured in number of sectors. Once got the disk, a task must
      however consume its assigned budget within a configurable maximum time
      (by default, the maximum possible value of the budgets is automatically
      computed to comply with this timeout). This allows the desired latency
      vs "throughput boosting" tradeoff to be set.

    - Budgets are scheduled according to a variant of WF2Q+, implemented
      using an augmented rb-tree to take eligibility into account while
      preserving an O(log N) overall complexity.

    - A low-latency tunable is provided; if enabled, both interactive and soft
      real-time applications are guaranteed very low latency.

    - Latency guarantees are preserved also in presence of NCQ.

    - High throughput with flash-based devices, while still preserving
      latency guarantees.

    - Useful features borrowed from CFQ: cooperating-queues merging (with
      some additional optimizations with respect to the original CFQ version),
      static fallback queue for OOM.

    - BFQ supports full hierarchical scheduling, exporting a cgroups
      interface.  Each node has a full scheduler, so each group can
      be assigned its own ioprio and an ioprio_class.

    - If the cgroups interface is used, weights can be explictly assigned,
      otherwise ioprio values are mapped to weights using the relation
      weight = IOPRIO_BE_NR - ioprio.

    - ioprio classes are served in strict priority order, i.e., lower
      priority queues are not served as long as there are higher priority
      queues.  Among queues in the same class the bandwidth is distributed
      in proportion to the weights of each queue. A very thin extra bandwidth
      is however guaranteed to the Idle class, to prevent it from starving.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
block: fiops ioscheduler core

FIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets
for drive without I/O seek. It's quite similar like CFQ, but the dispatch
decision is made according to IOPS instead of slice.

The algorithm is simple. Drive has a service tree, and each task lives in
the tree. The key into the tree is called vios (virtual I/O). Every request
has vios, which is calculated according to its ioprio, request size and so
on. Task's vios is the sum of vios of all requests it dispatches. FIOPS
always selects task with minimum vios in the service tree and let the task
dispatch request. The dispatched request's vios is then added to the task's
vios and the task is repositioned in the sevice tree.

Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O
less writeback, usually a task can only dispatch either sync or async requests.
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
size and so on. In this case, the drive is in idle actually. Solving the
problem need make drive idle, so impact performance. I believe CFQ isn't
completely fair between tasks in such case too.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops read/write request scale

read/write speed of Flash based storage usually is different. For example,
in my SSD maxium thoughput of read is about 3 times faster than that of
write. Add a scale to differenate read and write. Also add a tunable, so
user can assign different scale for read and write.

By default, the scale is 1:1, which means the scale is a noop.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops sync/async scale

CFQ gives 2.5 times more share to sync workload. This matches CFQ.

Note this is different with the read/write scale. We have 3 types of
requests:
1. read
2. sync write
3. write
CFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2
are usually different for flash based storage. So we have both sync/async
and read/write scale here.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops add ioprio support

Add CFQ-like ioprio support. Priority A will get 20% more share than priority
A+1, which matches CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops preserve vios key for deep queue depth workload

If the task has running request, even it's added into service tree newly,
we preserve its vios key, so it will not lost its share. This should work
for task driving big queue depth. For single depth task, there is no approach
to preserve its vios key.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops bias sync workload

If there are async requests running, delay async workload. Otherwise
async workload (usually very deep iodepth) will use all queue iodepth
and later sync requests will get long delayed. The idea is from CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops add some trace information

Add some trace information, which is helpful when I do debugging.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
msm: board-8064: Add support for PM8917 regulator power grid

The regulator power grid changes slightly when using a PM8917 in
place of a PM8921 on 8064 targets.  Add configuration data so
that regulators present only on PM8917 are registered when a
PM8917 chip is detected.  Also remove PM8921 only regulators when
PM8917 is detected.  Modify the USB OTG MVS supply chain to
handle the replacement of an external 5V boost regulator with the
boost present inside of the PM8917.

Increase the max_uV value requested in the wlan_riva driver for
the iris_vdddig supply to 1225000 in order to handle the case of
this supply coming from the S1 regulator in the PM8917
configuration.  The S1 regulator only supports 1225000 uV.

Change-Id: Ib5ffa76cbc4590f468003c6863ba73807c4879e7
Signed-off-by: David Collins <collinsd@codeaurora.org>
wcnss: new SMD control channel with WCNSS

A new SMD control channel is opened with WCNSS, currently only the
version information is exchanged thru this channel. WCNSS version is
exposed thru /sys interface.

Change-Id: I45638bdd992846fa6087b6131180684d30805002
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
adapted for Mako kernel from CAF reference

Signed-off-by: faux123 <reioux@gmail.com>
wcnss: Add wcnss support for 8974

- Install 5wire interface for wcnss device.
- Add the powerup sequence for wcnss device.
- Apply regulator settings by dynamically detecting the hardware.
- Add device tree documentation for WCNSS platform driver.

Change-Id: I533b56001313a480231f1e30d16ce12730f15f37
Acked-by: Bharath Pandravada <bharathp@qca.qualcomm.com>
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
adapted for Mako from CAF reference

Signed-off-by: faux123 <reioux@gmail.com>
wcnss: Pre-alloc memory for WLAN driver

WLAN driver will use this pre-allocated memory (when available) for
large memory allocations; this will prevent WLAN driver load
failures because of the un-availability of the large size slabs
during module load.

Change-Id: I8a8139bdf343ddc871036f6d5c6ab90993816de0
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
adapted for Mako kernel from CAF reference

Signed-off-by: faux123 <reioux@gmail.com>
wcnss: Fix the copyright year for wcnss_vreg.c

The copyright year for the original file was 2011-2012; but that was
incorrectly recorded as 2012 while the file was renamed from
wcnss_riva.c to wcnss_vreg.c to support Pronto.

Change-Id: Ice5c84cc13390c6aa47d07731dfa2f3cafe99d54
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
wcnss: Add interface to Reset wcnss

Add wcnss reset interface, this interface generates an FIQ to Riva.
Upon receiving this interrupt, Riva will execute the ERR_FATAL
routine and invoke SSR.

Change-Id: I74c293121cb69b312ed980902a12019adb700792
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
wcnss: Log CCPU registers in reset interrupt API

Reset interrupt is sent to Riva when host drivers fail to communicate
with Riva over SMD. So logging these CCPU registers helps to know the
failure reason at Riva.

Change-Id: Icccf6a5b0644fd75137602cc96b25dc8d392260a
CRs-Fixed: 418813
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
wcnss: Use preferred devm_kzalloc

Replace kzmalloc with preferred devm_kzalloc to avoid explicit memory
free calls.

Change-Id: I5457bad7e9ecab36e9d9fe9d429b121669d2f9d3
CRs-Fixed: 421013
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
Bluetooth: hci_ath: Configure GPIOs as part of bluetooth on.

Configuration of GPIOs should not be part of module init process
as gpios can be shared with other module.
Moved the configuration of gpios as part of driver open and releasing
them as part of driver close, so that there will not be any conflict
between different modules.

Change-Id: Iac507dd1e07e2cd4adb4c28058800fa4f51c9b52
Signed-off-by: Ram Mohan Korukonda <rkorukon@codeaurora.org>