Sound Control: WCD9320: expose additional controls

Signed-off-by: Paul Reioux <reioux@gmail.com>
sound control 3.x: Initial GPL release for WCD9320 Audio Codec

This is first official GPL release based on my private implementation.

This release has been tested for xperia Z officially.  It may work
with other devices using the same WCD9320 Audio Codec as well, but not tested

Signed-off-by: Paul Reioux <reioux@gmail.com>
sound control: WCD9320: update speaker gain control for Z1

Signed-off-by: Paul Reioux <reioux@gmail.com>
Sound Control: (Optional) work around for Nexus 4/5 audio issues

(Use this only for devices with audio reset issues)

Also bump version to 3.1

Signed-off-by: Paul Reioux <reioux@gmail.com>

wcd9xxx-core: add register write without mutex protection

This is assuming the calling function will take care of the mutex.

Signed-off-by: Paul Reioux <reioux@gmail.com>
Sound Control: (OPTIONAL) add power amp registers access control as well

Signed-off-by: Paul Reioux <reioux@gmail.com>
sound control: add register cache

bump to version 3.2

Signed-off-by: Paul Reioux <reioux@gmail.com>
[PATCH 1/3] block: cgroups, kconfig, build bits for BFQ-v7r3-3.4

Update Kconfig.iosched and do the related Makefile changes to include
kernel configuration options for BFQ. Also add the bfqio controller
to the cgroups subsystem.

Change-Id: If0aeebc591ada0df80eba0e41ae8bc25c626c548
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
[PATCH 2/3] block: introduce the BFQ-v7r3 I/O sched for 3.4

Add the BFQ-v7r3 I/O scheduler to 3.4.
The general structure is borrowed from CFQ, as much of the code for
handling I/O contexts. Over time, several useful features have been
ported from CFQ as well (details in the changelog in README.BFQ). A
(bfq_)queue is associated to each task doing I/O on a device, and each
time a scheduling decision has to be made a queue is selected and 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 a very low latency.

    - Latency guarantees are preserved also in the presence of NCQ.

    - Also with flash-based devices, a high throughput is achieved
      while still preserving latency guarantees.

    - BFQ features Early Queue Merge (EQM), a sort of fusion of the
      cooperating-queue-merging and the preemption mechanisms present
      in CFQ. EQM is in fact a unified mechanism that tries to get a
      sequential read pattern, and hence a high throughput, with any
      set of processes performing interleaved I/O over a contiguous
      sequence of sectors.

    - BFQ supports full hierarchical scheduling, exporting a cgroups
      interface.  Since each node has a full scheduler, each group can
      be assigned its own weight.

    - If the cgroups interface is not used, only I/O priorities can be
      assigned to processes, with ioprio values mapped to weights
      with 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 weight of each queue. A very
      thin extra bandwidth is however guaranteed to the Idle class, to
      prevent it from starving.

Change-Id: I2ae8bd9d5968477a015c485290b27788e46c6d5a
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
[PATCH 3/3] block, bfq: add Early Queue Merge (EQM) to BFQ-v7r3 for 3.4.0

A set of processes may happen  to  perform interleaved reads, i.e., requests
whose union would give rise to a  sequential read  pattern.  There are two
typical  cases: in the first  case,   processes  read  fixed-size chunks of
data at a fixed distance from each other, while in the second case processes
may read variable-size chunks at  variable distances. The latter case occurs
for  example with  KVM, which  splits the  I/O generated  by the  guest into
multiple chunks,  and lets these chunks  be served by a  pool of cooperating
processes,  iteratively  assigning  the  next  chunk of  I/O  to  the first
available  process. CFQ  uses actual  queue merging  for the  first type of
rocesses, whereas it  uses preemption to get a sequential  read pattern out
of the read requests  performed by the second type of  processes. In the end
it uses  two different  mechanisms to  achieve the  same goal: boosting the
throughput with interleaved I/O.

This patch introduces  Early Queue Merge (EQM), a unified mechanism to get a
sequential  read pattern  with both  types of  processes. The  main idea is
checking newly arrived requests against the next request of the active queue
both in case of actual request insert and in case of request merge. By doing
so, both the types of processes can be handled by just merging their queues.
EQM is  then simpler and  more compact than the  pair of mechanisms used in
CFQ.

Finally, EQM  also preserves the  typical low-latency properties of BFQ, by
properly restoring the weight-raising state of  a queue when it gets back to
a non-merged state.

Change-Id: If7eb6071d7f969c8893c0b38009582613458710e
Signed-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Reviewed-by: Paolo Valente <paolo.valente@unimore.it>
input: add s2w and dt2w

 * Squashed commits from bricked kernel

Change-Id: Ia9bf0cc3e2d32a7b8ec34dd41fc952cba8bded2d
Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
LCD_KCAL: Color Control driver for Nexus 5
msm: mdss: Display gamma control

TODO: confirm rgb channels, identify other tunables, cleanup,
apply values without switching screen (off and) on.

sysfs: /sys/devices/qcom,mdss_dsi_jdi_command_ors.69/*
msm: mdss: Apply commands values without switching screen (off and) on

Change-Id: If91bb71ec272fcf04fb908c686e1739901199096
msm: mdss: Remove tunable for command 32

Even slight changes look ugly or distort the screen.
msm: mdss: distinguish between Gamma RGB polarity Positive/Negative

Change-Id: Iff57031c77068891740382a4b5e4aef56cc93b0a
Signed-off-by: Paul Reioux <reioux@gmail.com>
msm: mdss: Remove sysfs for unused commands

Change-Id: I76a1dd34730220ac20e122da81917f9614e1220e
msm: mdss: Identify white point in sysfs

Change-Id: Ie20ede22dda0dba7c69c6edfecc427e626635319
msm: mdss: Add safety check for user input

Leave more checks either to the control app or the user's intelligence.

Change-Id: I13f24c09bb9f4dd9da1ee2ac79eb85e08d5dadeb
msm: mdss: Finalize gamma interface and cleanup

- Remove all sysfs files of unused commands
- Remove auto sync for negative polarities, these must be written separately
- Protect offset bit of white point command as well
- Apply white point bit 2 as duplicate of bit 1

Change-Id: Ice5ace99c1f11910d058a5f054085cac74169c50
msm: mdss: Send panel commands via separate function

Sending panel comnmands is very expensive, add a separate function to
accomplish this. Once all commands have been stored write anything to
the kgamma_send file.

Change-Id: Ia757be43751960dac934801e0a91861cfbae7c72