msm: pm: warmboot entry/exit counters on IMEM

Add warmboot entry/exit counters for each core on a non-cacheable always
on IMEM memory. This is a useful feature during debug to understand if
the system has correctly warmbooted after a power collapse. The debug
counters start at a memory offset of 0x664 on the IMEM. Each core
reserves 4 words for events, of which 3 are being used to monitor the
following events,
1) power collapse entry
2) warmboot exit
3) failed power collapse when wfi returns with a pending interrupt.

Change-Id: I45aac8e4a4d3421d586790b3b66fd71a8d88ea9d
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: pm-8x60: Setup memory for save/restore cpu registers early

Cores can be offlined early in the boot cycle by certain kernel
drivers.
Ensure that the memory to save and restore the cpu registers is
ready and available early during the boot procedure.

CRs-Fixed: 460083
Change-Id: I925372f066386ceb1e85184d4c58863835c3e88e
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
msm: pm-8x60: Use relative time for events

There is a bug when adjusting for event wakeups. The adjusted time
is being set in absolute mode incorrectly. Instead just use relative
times.

Without this core wakeups may not happen on time.

CRs-fixed: 486466
Change-Id: If625f25bd573b05befb6e0f922c80db646428b86
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
msm: pm: send notification only for SPC and PC

Today the pm notification is sent for all the power
modes of each CPU. This is not necessary for shallow
power modes.

This change is to send the notification for only
standalone power collapse for each core and idle
power collapse of core0.

Change-Id: I9b3df3d72e43d645387c94b1b9c5da3bcf2f2e5f
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
msm: cpufreq: increase priority of thread that increases frequencies

When the cpufreq governors request for increase in frequency from kworker
threads, there is chance that the kworker thread is cpu starved due to
other high priority threads, leading to undesirable increase in frequency
ramp-up latency. Add the calling thread to SCHED_FIFO policy when
requesting for increase in frequency and restore back to original policy
after ramp-up is completed.

Change-Id: Ie4fa199b7f9087717cb94dfcc2eddea27cc0012b
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
msm: pm: add failed stats

for idle and suspend failed cases the stats
are not updated correctly, they are just added to
success bucket.

This patch is to log the failed stats separately.

Change-Id: I4b290944e3f4b74ada13ef0ba51b812c83b5ec5d
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
msm:rq_stats: Add hotplug disable attribute

Register for suspend and resume notifications from kernel. This should
be done as part of core_initcall so as to receive notification as close
as possible to the actual event. Add hotplug_disable attribute to
rq-stats node. Set/clear this attribute based on the suspend/resume events.

CRS-fixed: 452456
Bug: 9022807
Change-Id: I76fee349b57f47df40785e9c2503e2e1cc6e064e
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
Signed-off-by: Mekala Natarajan <mekalan@codeaurora.org>
msm:rq_stats: Register for Cpufreq policy notification

Currently the load of the system is calculated using the max
frequency that is read during startup(It does not get updated
when the policy changes). As a result, the average load of the
system is incorrectly calculated and the system might not bring
the cpus online to manage the additional load. This
reduces the performance of the system.

To fix this issue, register rq_stats to receive cpufreq policy
notifications. Update the policy's max frequency when a
notification is received and use that value to calculate the load.

Change-Id: Icc78e28c736c170e198f723fd96c13dfb2dafe8a
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
msm: rpm: add debug msg for rpm outstanding req

added a debug info for showing the power collapse
abort due to rpm outstanding request.

Change-Id: Ifbc8054033b3cc86ccebc625b501ddb8b2670707
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
Staging: android: binder: Fix memory leak on thread/process exit

If a thread or process exited while a reply, one-way transaction or
death notification was pending, the struct holding the pending work
was leaked.

CRs-Fixed: 477612
Change-Id: I8b7a4f77689731a47c9e2f2fffefcac95c412e00
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 675d66b0ed5fd170d6a44cf8dbb3fa56a5347bdb
Git-repo: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
msm: Fix race condition in domain lookup

During lookup of domains we take a pointer to the root node
of the rb tree before taking the mutex to protect the rb tree.
However, the rb root node might change if another process updates
the rb tree after we take the pointer to the root node. This can
cause us to not find the entry that we are looking for.
Fix this by ensuring we have taken the mutex before getting the
root node pointer.

CRs-fixed: 493503
Change-Id: I4702740e486fda0cd92df0401d8e4706598a899b
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
mmc: core: Allow changing bus frequency for SD/eMMC cards in runtime

Currently, bus frequency is set during the card initialization and
never changed until a new card is inserted. In some low power use
cases, scaling the clock frequencies while the card is in transfer
state would allow power savings. This change allows bus frequency
to be changed after the card initialization.

Change-Id: Iac064221199f69d162d91f5311becd735c15700a
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Fix some driver hangs when dealing with broken devices

There are infinite loops in the mmc code that can be caused by bad
hardware.  The code will loop forever if the device never comes back
from program mode, R1_STATE_PRG, and it is not ready for data,
R1_READY_FOR_DATA.

A long timeout is added to prevent the code from looping forever.
The timeout will occur if the device never comes back from program
state or the device never becomes ready for data.

It's not clear whether the timeout will do more than log a pr_err()
and then start a fresh hang all over again.  We may need to extend
this patch later to perform some kind of reset of the device (is
that possible?) or rejection of new I/O to the device.

Change-Id: I1f3e5fddffb5134743fbfbcdef5e97803fd25fc6
Signed-off-by: Trey Ramsay <tramsay@linux.vnet.ibm.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: core: Add load based clock scaling support

The SD3.0/eMMC4.5/SDIO3.0 cards can support clock rates upto
200MHz (SDR104 or HS200 bus speed modes). For some workloads
like video playback it isn't necessary for these cards to run
at such high speed. Running at lower frequency, say 50MHz, in
such cases can still meet the deadlines for data transfers.
Scaling down the clock frequency dynamically has huge power
savings not only because the bus is running at lower frequency
but also has an advantage of scaling down the system core
voltage, if supported.

Provide an ondemand clock scaling support similar to cpufreq
ondemand governor having two thresholds, up_threshold and
down_threshold to decide whether to increase the frequency or
scale it down respectively. The sampling interval is in the
order of milliseconds and should be chosen by host drivers that
enable MMC_CAP2_CLK_SCALE capability to take advantage of clock
scaling. The sampling interval mainly depends on the the clock
switching delays and hence a host driver decision. If sampling
interval is too low frequent switching of frequencies can lead
to high power consumption and if sampling interval is too high,
the clock scaling logic would take long time to realize that the
underlying hardware (controller and card) is busy and scale up
the clocks.

Change-Id: I22a5054beec41b0b66b3bf030ddfcf284de448b3
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Add sysfs entries for dynamic control of clock scaling

Add sysfs attributes to allow dynamic control of clock scaling
parameters. These attributes are used to enable/disable clock
scaling at runtime and change the up_threshold, down_threshold,
and polling_interval values. Complete documentation for these
sysfs entries are provided at "Documentation/mmc/mmc-dev-attrs.txt".

Change-Id: I4753c75c3b3eeea91e93bceba7af2535b793612e
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: claim mmc host while enabling clock scaling from userspace

A race condition can occur while enabling clock scaling and removal
of the card. If the card is removed just after the host->card check
is successful then there could be NULL pointer dereference later.
Claim mmc host before card availability check to avoid this race
condition.

Change-Id: I6339cad5857732ec6b66280940cd6b8b7ed30614
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: run clock scaling only in valid card state

Clock scaling requires the tuning and if the tuning command
is sent to the card in invalid state, tuning procedure will
fail.

With urgent request mechanism implemented, there is a chance
that clock scaling invoked when card is not in a proper state
to receive the tuning command.

This change checks the card state (by sending the status command)
before invoking the clock scaling request.

Change-Id: Icb71a8e74a9afdc70380a5901cd3d28931959e9c
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: core: Log MMC clock frequency transitions

Use kernel's ftrace support to capture MMC clock frequency
transitions which can be useful for debugging issues related
to power consumption.

Usage:
mount -t debugfs none /sys/kernel/debug
echo 1 > /sys/kernel/debug/tracing/events/mmc/mmc_clk/enable
cat /sys/kernel/debug/tracing/trace_pipe

Change-Id: I25c4ee39dcbe30e7665902a9f723a5a421b55ca3
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Add support for notifying host driver while scaling clocks

Host drivers can participate in clock scaling by registering
->notify_load host operation, which allows host driver to carry out
platform specific operations for further power savings or increasing
throughput based on whether load is LOW or HIGH respectively. This
can be applicable to non-ultra high speed cards as well so remove
the check for ultra high speed cards to initialize clock scaling.

Change-Id: Icaab9520135e384f5470db68b2f25c5cdce5663a
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: msm_sdcc: Add support for dynamic bus clock vote

SDCC controller on some targets like 8660, 8960, 8064 and their
variants connects with Daytona Fabric (DFAB). To achieve max.
possible performance the DFAB clock is voted to 64MHz at the
cost of some power consumption. Since we now have dynamic clock
scaling for SD/eMMC clock we can also scale the DFAB clock
accordingly without impact on performance but have some power
savings in low throughput cases.

Change-Id: Ic26541d6845b65803aa813d672ccabdfc4658d9c
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>