qcom-cpufreq: Fix frequency table registration

CPUfreq device is the provider of CPU frequency table, and
it should always keep track of freq tables for every CPU itself.
cpufreq_frequency_get_table() is an API for frequency table user.
qcom-cpufreq should not use this API to obtain CPU freq table in
the init function. Otherwise, the following sequence will lead to init
failure.

Assume CPU 0 and 1 are under control of same policy and online. Say
policy->cpu is CPU 0.

1) Hot unplug CPU0
   update_policy_cpu() will transfer ownership of policy to CPU1
   cpufreq_frequency_table_update_policy_cpu() is called during
   the process to set CPU1's freq table to be the same as CPU0's freq
   table. CPU0's freq table is now NULL.
2) Hot unplug CPU1
   All CPUs in policy are now offline.
3) Hot plug in CPU0
   cpufreq_driver->init() is called for initialization. If this init
   function calls cpufreq_frequency_get_table() on CPU0, the result
   will be NULL.

Current qcom-cpufreq checks return value of cpufreq_frequency_get_table()
and returns an error in init.

Remove the usage of cpufreq_frequency_get_table() and fill in frequency
table for policy->cpu in msm_cpufreq_init().

Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: cpufreq: Remove deprecated APIs

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: hotplug: Try conservative load scale

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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>
msm: kgsl: enable CPU IRQ while suspending context

Make sure that CPU interrupt is enabled before calling adreno
suspend_context when moving from NAP/SLEEP to SUSPEND state.
We send commands to GPU in adreno_drawctxt_switch() which will generate
GPU interrupt. Since CPU interrupt is not enabled, adreno_idle() will
fail because pending interrupt will not be served by CPU this causes
false GPU hang.

Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: kgsl: don't use sscanf()

Friends do not let friends use sscanf().

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Ananta Kishore K <akollipa@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Revert "sched: Limit setaffinity with CPU_HOTPLUG"

This reverts commit 7ad20cfd6d08280490d1e08ad4851f6dd49ba3bf.
workqueue: set delayed_work->timer function on initialization

delayed_work->timer.function is currently initialized during
queue_delayed_work_on().  Export delayed_work_timer_fn() and set
delayed_work timer function during delayed_work initialization
together with other fields.

This ensures the timer function is always valid on an initialized
delayed_work.  This is to help mod_delayed_work() implementation.

To detect delayed_work users which diddle with the internal timer,
trigger WARN if timer function doesn't match on queue.

Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
workqueue: Remove panic

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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.

Signed-off-by: Satyavaraprasad Yerramsetti <satyav@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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.

Signed-off-by: Vivek Veenam <vveenam@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: hotplug: Use correct variable type

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
random: fix BUG_ON caused by accounting simplification

Commit d7e58560111160f5478e13b2387d6b20c4102937 ("random: simplify accounting logic") simplified
things too much, in that it allows the following to trigger an
overflow that results in a BUG_ON crash:

dd if=/dev/urandom of=/dev/zero bs=67108707 count=1

Thanks to Peter Zihlstra for discovering the crash, and Hannes
Frederic for analyzing the root cause.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Peter Zijlstra <peterz@infradead.org>
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Greg Price <price@mit.edu>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
drivers: bluetooth: Make bluesleep aware of clock state

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Revert "msm: hotplug: Try conservative load scale"

This reverts commit df893d1ff59ffc01dc70f1c474f01e7e09625278.
msm: hotplug: One doesnt enter fast lane that easy

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

[ neo: Code style improvement.
  Thanks @Dorimanx and @Alucard24 ]

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>