qup_i2c: Add vote for clock path

Currently the i2c driver votes for its core clock. However, it is
possible that the core-clock's source will be off. When the source
is off, the i2c core is not clocked. This patch adds voting for
the entire clock path, thus guarantee clocking to the i2c core.
Voting for the path cost a few msecs. A client may choose when
to pay this overhead. By default the votes takes place in the
runtime-pm callbacks which tie to transaction requests. A client
may choose to invoke these callbacks itself whenever it likes
by directly calling the driver's runtime-pm. A third option is
to set the active_only flag in platform data which results in the
callbacks being called when the application processor power state
changes.

CRs-Fixed: 483873
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
(cherry picked from commit 0906336a050fa47118be4fddf7a7d2dcf21a3986)

Change-Id: I74cca9054fddf817e9d1d98fdb1c2a9790624b28
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
arm/dt: msm8974: qup_i2c: Add support for clock path voting

Voting for the entire clock path (using the bus-scaling driver)
requires information about the master endpoint number. This
number is configured to the driver via the device tree.
In addition, the device-tree binding document is updated
to reflect the new fields.

CRs-Fixed: 483873
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
(cherry picked from commit 227df1c2aecb79db4101af4d5074a9f2bec042dc)

Change-Id: I0db4e7cebeef019cb536db287e78cd25f4ef88ed
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
msm: pm-8x60: Add PNOC request to prevent PNOC clk gating

Keep a request of 19.2Mhz for PNOC bus when Apps is not
in suspend.

temp change on jb_mr1_rb4 to unblock a CRM

(cherry picked from commit 9b186afca6c206ef1e74c138a10b75bdab4ba422)

Conflicts:

	arch/arm/mach-msm/pm-8x60.c

Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
(cherry picked from commit 7ef27121358916112cf730452f7c7e9b0685954f)

Change-Id: I1f82b16a1f8fdecd14230b7bdd1996f4a0abf8a8
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
msm: pm-8x60: Fix incorrect computation of wakeup times

A incorrect computation of scheduled wakeup times, which is passed on to
RPM for wakeup from deep sleep modes, could result in the Core sleeping
for longer than intended during RPM assisted power collapse.

CRs-fixed: 488889
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
(cherry picked from commit 2f41538efcd9829804e9c0a5190c7e523295ff30)

Change-Id: Id2a3c9a4a576796fbf3c2cad8f38ffad2bbbf93a
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
msm: vidc: Queue buffers to vidc in a different thread

To work around a bug in the V4L2 framework, perform qbufs on the output
port/CAPTURE plane.

Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
(cherry picked from commit bb5d8490274d1c8d23ff677e3fdff6b7336d064a)

Change-Id: I35c4920fbaeb4ec7104946d22e9958694c251196
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
msm: camera: support automode for VDD_CX

While camera preview or recording is in progress,
there are plenty of opportunities for CX to run
in auto mode. However, since these use cases
have relatively high load, running in auto mode
may have an adverse effect on stability. Therefore,
disable auto mode on MSM8974 while the camera is
in use.

Signed-off-by: Hody Hung <hhung@codeaurora.org>
(cherry picked from commit a86d97a27965358b6c2b760182b6e1a6f5edaf8c)

Change-Id: If4ddc872ff723f691b481521946acd4da339b5f7
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
msm: kgsl: Use the correct length when looking for address collision

Use the right length of allocation from the aligned base address of
CPU virtual map to look for collision in the GPU vitual map. This
prevents discarding of usable address ranges due to false collision
hits.

CRs-Fixed: 492041
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
(cherry picked from commit 07a72302186e2a27cf4129e974ccfc3423eccdb3)

Change-Id: Ic98bf0153f9419ed5e7d62878ea930a250f1a01b
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
Revert "msm: vidc: Report sufficient resources event as sufficient resources"

This reverts commit b8ef87dc091fe67fc929f85ec54a17289adbc5b7.
Some clients are not able to handle SUFFICIENT_RESOURCES event
when height
and width of clip changes. This causes green frames for some
clips. With this change, following is the behavior:

1.CONTINUE_DATA_TRANSFER disabled by client (default setting)
	a) FW reports sufficient - driver reports	insufficient.
	b) FW reports insufficient - driver reports insufficient.

2. CONTINUE_DATA_TRANSFER is enabled by client
	a) FW reports	sufficient - driver	reports sufficient.
	b) FW reports	insufficient - driver reports	insufficient.

Signed-off-by: Vinay Kalia <vkalia@codeaurora.org>
(cherry picked from commit 7ff4552e200dad2baeee5ce0643c393bcf953fab)

Change-Id: Ic3ab4362ad81d5483b99537b4d53614b2475e100
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
thermal: tsens8974: Use a dedicated tsense high-priority workqueue

Thermal-mitigation software subscribing the temperature updates
relies upon timely notifications of temperature changes. The existing
implementation scheduled these notifications on the system workqueue,
which may result in addition latency when the system is under heavy
load. Use a high-priority workqueue to solve this problem and ensure
time-sensitive temperature notifications are received as quickly as
possible.

Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
(cherry picked from commit 83026d61375d330b84f202a0532ae41dc849c53a)

Change-Id: I30f36c34f1ef5d32d85143b012662748a60deb48
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
cpufreq: Use dedicated high-priority workqueues

In the process of scaling CPU frequencies, cpufreq and the APIS is
calls may hold resources that will prevent threads critical for
system stability from running.

Specifically, thermal-mitigation software may need to respond
quickly to high-temperature conditions and throttle the CPU speed
in an effort to cool down. If the system is already in the middle
of a CPU frequency switch being executed on behalf of a cpufreq
governor, thermal mitigation will be blocked until the scaling
action has completed. If the system is under heave load of medium
or high-priority threads, this may take a long while and the system
may potentially surpass thermal limits in the meantime.

Resolve this by using high priority workqueues for all ondemand
and conservative governor scaling operations.  This will allow them
to complete promptly and release their hold on resources necessary
for maintaining system stability.

Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
(cherry picked from commit 21d22da902d1b197b698b1fb299fd7e0317ac38e)

Change-Id: I67d171173604c885bc761c173de3b73703a89bb6
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
Merge "qup_i2c: Add vote for clock path"
Merge "arm/dt: msm8974: qup_i2c: Add support for clock path voting"
Merge "msm: pm-8x60: Add PNOC request to prevent PNOC clk gating"
Merge "msm: pm-8x60: Fix incorrect computation of wakeup times"
Merge "msm: vidc: Queue buffers to vidc in a different thread"
Merge "msm: camera: support automode for VDD_CX"
Merge "msm: kgsl: Use the correct length when looking for address collision"
Merge "Revert "msm: vidc: Report sufficient resources event as sufficient resources""
Merge "thermal: tsens8974: Use a dedicated tsense high-priority workqueue"
Merge "cpufreq: Use dedicated high-priority workqueues"