qup_i2c: Handle scenario if runtime PM is disable

If  runtime PM is not supported, make sure
the I2C clock and GPIOs enabled at the start
of the transfer(RD/WR)
This is done by i2c_qup_pm_resume_runtime()

CRs-Fixed: 492194
Change-Id: Iaa901a0f0d0cd58318e3f6dd64e1db73c73b630f
Signed-off-by: Dilip Kota <c_dkota@codeaurora.org>
Signed-off-by: Sana Venkat Raju <c_vsana@codeaurora.org>
i2c_qup: Improve implementation of PM callbacks

Refactor PM callbacks and remove redundant variable.
Add support for configuration of clockcontrol event.
Now the clock's state may be set by pm calls (as before)
or by a transfer's begining and ending.
Runtime-PM is still used in autosuspend configuration for
expensive NoC voting/unvoting since that may go to remote
processor.

CRs-Fixed: 592435
Change-Id: I54f7c67f768336f66765a04006b4c8e4734ac277
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Sana Venkat Raju <c_vsana@codeaurora.org>
qup_i2c: export qup_i2c_init_driver

Drivers like onsemi-ncp6335d and fan53555 are clients of i2c-qup driver.
In some targets, these clients have to initialize and probe early before
the i2c-qup driver is ready. Hence export qup_i2c_init_driver to make sure
i2c-qup driver is ready when its clients need to probe.

Change-Id: I0f866d1c4239f9c72f6753674c2283e97f3a3691
Signed-off-by: Ke Liu <keliu@codeaurora.org>
msm: acpuclock-8974: fix CPU voltage limits to support additional parts

The following CPU frequency tables contain voltages higher than
than the previous limit of 1.1V:
	pro_rev1_2p5g_pvs0
	pro_rev1_2p5g_pvs1

Increase the limits to support the parts that use these tables.

Change-Id: Ife39497265ee5301de31ba91dcf0ff0ec2aeef61
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: kgsl: Avoid a possible pointer deference in __force_on_show

Make sure the device pointer is a thing before using it in
__force_on_show().

Change-Id: Ic0dedbad2e47f3bfb22daf43a910ab886200c03c
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Use the standard functions to read the queued timestamp

Use the standard KGSL functions to access the queued timestamp in the
generic event code rather than directly dereference the adreno_device.

Change-Id: Ic0dedbadfc3004ba9bb26dc6bda82dfe61663106
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
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>
sync: signal pt before sync_timeline object gets destroyed

There is a race condition

Assume we have *one* sync_fence object, with *one* sync_pt
which belongs to *one* sync_timeline, given this condition,
sync_timeline->kref will have two counts, one for sync_timeline
(implicit) and another for sync_pt.

Assume following is the situation on CPU

Theead-1 : (Thread which calls sync_timeline_destroy())
  -> (some function calls)
   -> sync_timeline_destory()
    -> sync_timeline_signal() (CPU is inside this
function after putting reference to sync_timeline)

At this time Thread-2 comes and does following

Thread-2 : (fclose on fence fd)
> sync_fence_release() -> because of fclose() on fence object
 -> sync_fence_free()
  -> sync_pt_free()
   -> kref_put(&pt->parent->kref, sync_timeline_free);
    -> sync_timeline_free() (CPU is inside this because
this time kref will be zero after _put)

Thread-2 will free sync_timeline object before Thread-1
has finished its work inside sync_timeline_signal.

With this change we signals all sync_pt before putting
reference to sync_timeline object.

Change-Id: Ic680e4d0bbef1c46bcb7cfba693395645241d203
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
Signed-off-by: Rom Lemarchand <romlem@google.com>
sync: Fix a race condition between release_obj and print_obj

Before this change, a timeline would only be removed from the timeline
list *after* the sync driver had its release_obj() called. However, the
driver's release_obj() may free resources needed by print_obj().

Although the timeline list is locked when print_obj() is called, it is
not locked when release_obj() is called. If one CPU was in print_obj()
when another was in release_obj(), the print_obj() may make unsafe
accesses.

It is not actually necessary to hold the timeline list lock when calling
release_obj() if the call is made after the timeline is unlinked from
the list, since there is no possibility another thread could be in --
or enter -- print_obj() for that timeline.

This change moves the release_obj() call to after the timeline is
unlinked, preventing the above race from occurring.

Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>
cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS

The cpufreq_interactive_timer gets cancelled and rescheduled
whenever the cpufreq_policy is changed. When the cpufreq policy is
changed at a rate faster than the sampling_rate of the interactive
governor, then the governor misses to change the target frequency
for long duration. The patch removes the need of cancelling the
timers when policy->min is changed.

Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
Change-Id: I7862f1c8022a3b98a890e7537f93d02010e86764
cpufreq: interactive: turn boost_pulse off on boost off

Change-Id: I36fe217fa047d68ea90e78b12c7db4537ea8010b
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.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>