cpufreq: ondemand: Boost CPU frequency only for touch input

Originally CPU frequency were boosted for any input event.
In some case, sensor sends a lot of input event, which
keep CPU in high frequency.  CPU frequency only need to
be boosted when real user interaction happens.

Change-Id: Ia3ad755b98d8363a17729926610b5dd6f0075288
CR-Fixed: 507519
Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
cpufreq: ondemand: add input_boost interface

Currently Ondemand governor handles any input event
like touch by scaling the CPU frequency to maximum
available on the target.

This change adds a new sysfs interface "input_boost"
whereby the CPU will scale to this frequency on input events.
The value of this sysfs is user defined so input events
can now be handled by scaling the CPU to lower frequencies
than target max.

Change-Id: I5428fd8797c9984b17a66b01a44557f2160e8b68
Signed-off-by: Dilip Gudlur <dgudlur@codeaurora.org>
cpufreq: ondemand: Fix update_sampling_rate race with hotplug

update_sampling_rate has a for loop which goes through each
online cpu and possibly queue up the ondemand work for them.
But while doing this it doesnt take any hotplug lock which
could potentially cause a race condition where ondemand work
is queued after the hotplug code (which sets the policy to NULL)
in the governor has cancelled any pending work. This could cause
a crash while trying to access the NULL policy in dbs_check_cpu.

Protecting the for_each_online_cpu loop with get_online_cpus()
and put_online_cpus().

Change-Id: Ia3f43ca7e4bed542834ab03ca1191d728f13311c
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
cpufreq: Save user policy min/max instead of policy min/max during hotplug

When a CPU is hotplugged off, various fields of the policy are saved so
that they can be restored when the CPU is hotplugged back in.

The existing code saves the policy min/max field during hotplug remove and
restores it into user policy min/max during hotplug add. This results in
the loss of the user policy min/max values across a hotplug remove/add.

Fix it by saving the user policy min/max instead of policy min/max during
hotplug remove. During a hotplug add, after user policy min/max is
restored, the policy min/max is already recomputed. So, there's no risk of
going beyound any limits imposed by the CPUFREQ_ADJUST/INCOMPATIBLE
notifiers.

Change-Id: Ib8e09fa324c1f80f095c5754b5dcf2685e8e4a66
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
cpufreq: Adding traces to the cpufreq

Logging the following events in ondemand for debugging purposes:
1) When thread migration of a foreground event triggers frequency
   synchronization of destination cpu with the source cpu.
2) Ondemand sampling instant when cpu load is evaluated and an
   appropriate frequency is selected corresponding to the load.

Change-Id: I44341c660b66135943f235d467090e3cc863a2fb
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
cpufreq: ondemand: Fix hotplug deadlock with store_powersave_bias

store_powersave_bias() acquires the hotplug lock and the dbs_mutex
lock, but does so in the wrong order.  Deadlocks like the following
can result.

Thread A:
    get_online_cpus+0x3c/0x5c           <- acquires 'cpu_hotplug.lock'
    store_powersave_bias+0x80/0x3f4     <- acquires 'dbs_mutex'
    kobj_attr_store+0x14/0x20
    sysfs_write_file+0x108/0x13c
    vfs_write+0xb0/0x128
    sys_write+0x38/0x64

Thread B:
    cpufreq_governor_dbs+0x7c/0x55c     <- acquires 'dbs_mutex'
    __cpufreq_governor+0x90/0xe0
    __cpufreq_set_policy+0x1b0/0x258
    cpufreq_add_dev_interface+0x2cc/0x334
    cpufreq_add_dev+0x514/0x580
    cpufreq_cpu_callback+0x88/0x9c
    notifier_call_chain+0x38/0x68
    __cpu_notify+0x28/0x40
    _cpu_up+0xe4/0x118                  <- acquires 'cpu_hotplug.lock'
    cpu_up+0x64/0x80
    store_online+0x48/0x78
    dev_attr_store+0x18/0x24
    sysfs_write_file+0x108/0x13c
    vfs_write+0xb0/0x128
    sys_write+0x38/0x64

Fix this by flipping the order in which the locks are acquired and
released in store_powersave_bias so that it is the same as in the
hotplug path.

Change-Id: Idc59fb29d60b8f7fceb8ed0f2bb9eff4670abda7
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
spi_qsd: Add vote for clock path

Currently the spi 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 spi core is not clocked. This patch adds voting for
the entire clock path, thus guarantee clocking to the spi 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: 478465
Change-Id: Ib866399c0e84a875a19a0d1506d77bbe77d5fe61
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
spi_qsd: Config GPIOs by name rather then by index

Currently GPIOs are identified (MISO/MOSI/CLK or CS0..3)
by their index in the device-tree entry's array.
Further, chipselect GPIOs must be declared in order.
This allows to set a value for GPIO number three only
if the values for GPIOs one and two are also set.
This patch allows the driver to identify GPIOs by a
unique name, thus allows to specify any arbitrary
chipselect GPIO and reduces chances of simple
user configuration error.

Change-Id: I7cf1fb4329155bd5fc635257fc58d1dfa7312462
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
spi_qsd: Correction in DMA mode check

Due to a bug in the if() condition msm_spi_use_dma
function is always returning '0' when cs_change
is true. Due to this issue the DMA mode is not being used
when it has to be.

CRs-Fixed: 475841
Change-Id: I7da2ee091635f0cfd89058787c35b62adf1984b5
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
spi_qsd: Add support for bam pipe flush on timeout

BAM pipes must be flushed when a transfer timeout
leaving dangling descriptors.

Change-Id: I29fbd2a98964bff5496630a165b3cd0a3f1f2d08
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
spi_qsd: Verify pointers prior to redirection

Redirection on a NULL pointer leads to a system crash.
Here we verify pointers which potentially may be NULL
before a redirection.

Change-Id: I72b856e52f63b13e517c28d8dbb04e1f333f8065
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
spi_qsd: set device's runtime PM status to 'suspended'

Sometimes system suspend is initiated before runtime
PM's auto-suspend delay expires and causing devices to
not suspended runtime. As part of system suspend if
device is not suspended runtime then clocks and gpios
are manages by system suspend.

If spi client does initiate transaction request immediately
after system resume then spi doesn't resume run-time
immediately as spi controller's device state is not in
'suspended state'.

Keep device's runtime PM status to suspended during
system suspend.

CRs-Fixed: 512718
Change-Id: I5c0cb39c0b91782d8686c1b3da81125169ccf9be
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
spi_qsd: Correct an error reporting check

When reading values from the device tree, the error
check on BAM producer pipe must be negated.

Change-Id: Ia766cabdde47390c5a3c79b1c98a704e695fc571
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
spi_qsd: Remove redundant input first setting in bam mode

The HW is not mandating the use of input first in bam mode,
therefore, that statement is removed.

CRs-Fixed: 519665
Change-Id: I7c5bbe8a71ea5b8a0e25efdea585251c7c4d4d14
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
spi_qsd: Do not fail probe on DMA init error

Rather than failing the probe function on DMA
initialiation error, this patch just disables DMA
mode and logs an error. The driver continues to
function in FIFO mode.

Change-Id: Ib2532e3497192e1ef7efa02d2dff855826ad6091
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
spi_qsd: correct the chip select gpios valid field entry

During probe Chip select gpio's valid field is set to non-zero.
This is causing gpio free to get called for not-used gpios
during runtime suspend.

CRs-Fixed: 525743
Change-Id: Ib0de417d640f30908ad11650b584833dac286646
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
thermal: qpnp-adc-tm: Reduce kernel log flood

Modify the pr_err log that is used for checking if
clients have a valid callback when threshold request
is made to pr_debug. Currently kernel logs are getting
flooded due to periodic request made from the client.

Change-Id: I74bf4115bc25396da16a96ad7378ba3a7375710f
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
msm: thermal: Set vdd restriction initialize level to -1

Currently the init level is set to 0(enabled), but at this point of
time, the actual voltage is not being set yet. If the device boots
up in low temp, it will try to set level to 0(enabled) again. Since
it will check the level against with previous level which is also
0(means enabled), it will not set the actual voltage/frequency for
the rails.

Set the init level to -1(disabled), so that when device defaults to
enable vdd restriction, it will actually set the voltage.

Change-Id: I9997245953c9947889a813901032c3df8c737ad3
Signed-off-by: Jennifer Liu <chihning@codeaurora.org>
mmc: card: change long_sequential_test time measurements to ktime

Change time measurements in long_sequential_test from jiffies to ktime,
and make the relevant change in test-iosched infrastructure.

In long_sequential_test we measure throughput, and the jiffies resolution
is not sensitive enough for this calculation.

Change-Id: If7c9a03c687f61996609c014e056bcd7132b9012
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
block: row: Remove warning massage from add_request

Regular priority queues is marked as "starved" if it skipped a dispatch
due to being empty. When a new request is added to a "starved" queue
it will be marked as urgent.
The removed WARN_ON was warning about an impossible case when a regular
priority (read) queue was marked as starved but wasn't empty. This is
a possible case due to the bellow:
If the device driver fetched a read request that is pending for
transmission and an URGENT request arrives, the fetched read will be
reinserted back to the scheduler. Its possible that the queue it will be
reinserted to was marked as "starved" in the meanwhile due to being empty.

CRs-fixed: 517800
Change-Id: Iaae642ea0ed9c817c41745b0e8ae2217cc684f0c
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>