Intelli Thermal driver: switch to local CPUFREQ Limit control.

Remove msm_cpufreq_set_freq_limits and register with
CPUFREQ_POLICY_NOTIFIER to get immediate update on cpu frequencies
as long as a cpufreq_update_policy is called. Ensure that when
cpufreq_update_policy is called, cpu will not be hotplugged by
calling get_online_cpus().

Change-Id: I802d51ad1c352a19d2e456f9f6a89f8d5b89aad8
Signed-off-by: Jennifer Liu <chihning@codeaurora.org>
Small cleanup in thermal driver.
thermal-core: Fix invalid sensor request not accounted correctly

Add NULL check for sensor name before using it in sensor_get_id and
return NULL explicitly when sensor id is not valid in get_sensor of
thermal core.

Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: thermal: Update thermal sysfs nodes permission

Update the permissions of the sysfs nodes exposed
by the kernel thermal monitor.

Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
intelli_plug: Simplify mp_decision

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: cpu-boost: Do not consider keypad events for boost

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Intelli Thermal Control by faux123, independent freq limit control!

*Fixes for schedule_delayed_work, it's bad to start as 0 delay.
*Tuned max temp and cooldown range.
*Replaced __cpuinit with __ref
*Added debug switch on/off
*Fixed no mutex locks when was needed.

Merged updates from Myfluxi source.
Default Intelli Thermal (merged with original) fixed derps + work delay.
MSM HOTPLUG: Small fixes for bail out, and last ifdef for suspend.
CPUFREQ: Ondemand, Remove cpu touch boost notify, as we have it in cpu boost!

Also restore some tuning to make GOV more relaxed on small load spikes!

Now MSM HotPlug also relaxed when using it with ondemand.
MSM HOTPLUG: Add fast_lane_min_freq value.

This help to make fast_lane function that turn on all CORES on high load
little more smart. as small spikes on low freq can generate 100% load value
but freq is 300Mhz and we dont need all cores online!

So enable that TURBO function match only when 2 conditions!

load >= 95
cur_freq on cpu 0 >= 1728000

Thanks to @Alucard24 for help.
Tune All BLOCK govs for Android needs, and allow more write power in ROW.
Revert "Boost global HZ value from 100 to 200! Lets boost this backet.."

This reverts commit 7b7b7e9e29dd54f21d0b535827e0de9e3c358be1.

Revert "Boost global HZ value from 100 to 200! Lets boost this backet.."

This reverts commit 7b7b7e9e29dd54f21d0b535827e0de9e3c358be1.

Setting 200 brake too much for cpu code, and give little boost..
so set the SLOW HZ=100 as stock..
MSM HOTPLUG: After i have reverted HZ = 200 to 100, i can set here HZ
CPUFREQ Ondemand: Merged LG latest GOV freq calculation. must better!

Now i have 2 Mods! LG as performance! and Samsung as Battery save!

Any way i have tuned both of them, it's not default.
workqueue: Remove panic

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
MSM HOTPLUG: Code style fix by neobuddy89
msm: camera_v2: Don't touch CCI if camera daemon crashed.

If daemon crashes, refrain from writing to the CCI. This is needed
because these writes will not wait in a process crash scenario and can
potentially leave the CCI in a bad state.

Change-Id: I785cb4af8dc3893b8a7f11e1d1c2a2e1ad775665
Signed-off-by: Satyavaraprasad Yerramsetti <satyav@codeaurora.org>
Signed-off-by: Satyavaraprasad Yerramsetti <satyav@codeaurora.org>
msm: Camera: Return proper value for msm_camera_qup_i2c_txdata().

msm_camera_qup_i2c_txdata() is not returning proper value.
Due to which session tear down is not happening properly
in case of i2c failure.
CRs-Fixed: 640328

Change-Id: Iac8be9d4755f807b45a6ede4f660b52cb88aedd4
Signed-off-by: Vivek Veenam <vveenam@codeaurora.org>
msm: mdss: fix sync fence deadlock when rotator is used

In the current implementation, whenever rotator play is called, it
forces DMA pipes to be released by calling commit on video mode ctl
paths if they are using DMA pipes. Here assumption was that DMA pipes
will either be used in block mode or line mode, all or none. But this
assumption is not valid any more where we can have a use-case where
DMA0 is used for rotator and DMA1 for video mode ctl path. In this
use-case, current implementation can lead to sync fence deadlock. Fix
this by removing obsolete assumption.

Signed-off-by: Ujwal Patel <ujwalp@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>