rtc: qpnp-rtc: Add module parameter to control power-on alarm

Power-on alarm feature can be enabled/disabled by writing 1/0
to the module parameter exported by driver.

CRs-Fixed: 432312
Change-Id: I2a2337adb2ddc186ec312648b11b6a35ea698856
Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org>
regulator: qpnp-regulator: Don't print errors during probe deferral

Make the error printing statements after the qpnp-regulator
drivers calls regulator_register() conditional upon the error
code not being -EPROBE_DEFER.  This removes some unnecessary
kernel log messages that take place when a qpnp-regulator device
attempts to probe before its parent regulator.

Change-Id: I92d4ed61a238d384bae43458e3ca86c0079380c0
Signed-off-by: David Collins <collinsd@codeaurora.org>
power: qpnp-bms: Fix SoC smoothing upon resume

Currently the BMS driver tries to smooth out SoC jumps by limiting
the percent SoC change by the time since the last SoC change.
However, this can lead to an issue where report_state_of_charge is
called before SoC can be unbound. This will increment SoC by 1, but
create a situation where SoC is stuck when the time elapsed gets
reset.

Fix this by resetting the time elapsed only when doing an unbound
SoC report.

Change-Id: I6bdcc8d40b79653b003cc372570091f8adb30164
Signed-off-by: Xiaozhe Shi <xiaozhes@codeaurora.org>
power: qpnp-bms: detect constant voltage charging more accurately

Raise the CV charging threshold now that vddmax adjustments have been
implemented. Before, the BMS driver had to keep a 20 millivolt margin
because there was no guarantee that the charger will hit the set
max voltage. Now that the charger driver guarantees hitting within 5
millivolts of the max voltage, increase the CV detection threshold in
order to detect CV charging more accurately.

This change will smooth out the charging curve when the charger
transitions from CC to CV charging.

Change-Id: I0e399d9964866cc4cf2e7965f0d7d7be9bfab2ff
Signed-off-by: Xiaozhe Shi <xiaozhes@codeaurora.org>
power: qpnp-bms: Prevent SoC from being stuck after EoC

Currently, there is a race condition in the BMS driver that may cause
the State of Charge reported to be stuck after hitting end of charge.
This is because calculated SoC could change from 99 to 100 after
report state of charge checks the SoC value, but before it uses it.

Fix this by locking the calculated SoC update with a mutex

Change-Id: I3894dd8d3cd0d9b457955357e68c1daed00b5f9e
Signed-off-by: Xiaozhe Shi <xiaozhes@codeaurora.org>
power: qpnp-bms: Check for initialization of bms_psy

There is currently a bug in the BMS driver that can cause a kernel
panic. The if an ADC notification arrives before the BMS power supply
is registered, the BMS driver can cause a spin lock bad magic because
the bms_psy is not yet registered.

Fix this by checking if the power supply is registered before calling
power_supply_changed.

Change-Id: I48a46996f189ad9c71caa910486198cfba09db29
Signed-off-by: Xiaozhe Shi <xiaozhes@codeaurora.org>
Signed-off-by: Shashank Babu Chinta Venkata <sbchin@codeaurora.org>
msm: bcl: Calculate current available using vbat and rbat

Remove the code that reads battery current and current now.
Read battery resistance from bms module. Use the equation
below to calculate the available current:
iavailable = vbatt - 3400 / rbatt

CRs-fixed: 488647
Change-Id: I7d7688cddad672155f9a3068583a47dd1bc5dff9
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
PM / devfreq: set min/max freq limit from freq table

Set devfreq device min and max frequency limits when device
is added to devfreq, provided frequency table is supplied.
This helps governors to suggest target frequency with in
limits.

Change-Id: Iab24aef59bfeffcfb3c3118c12ba58e25cd9d479
Signed-off-by: Rajagopal Venkat <rajagopal.venkat@linaro.org>
Patch-mainline: linux-pm @ 01/08/13, 05:50
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
PM / devfreq: predef governors update freq when device is resumed

The predefined performance and powersave governors set the device
frequency on their startup only. That's not enough because the
frequency might have changed after device suspend-resume. With this
fix the governors re-set the required device frequency every time
a device get resumed.

Change-Id: I47ac877fc9e2cfbfc4a46cc676d6f2f838cd41d6
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
PM / Sleep: Print name of wakeup source that aborts suspend

A driver or app may repeatedly request a wakeup source while the system
is attempting to enter suspend, which may indicate a bug or at least
point out a highly active system component that is responsible for
decreased battery life on a mobile device.  Even when the incidence
of suspend abort is not severe, identifying wakeup sources that
frequently abort suspend can be a useful clue for power management
analysis.

In some cases the existing stats can point out the offender where there is
an unexpectedly high activation count that stands out from the others, but
in other cases the wakeup source frequently taken just after the rest of
the system thinks its time to suspend might not stand out in the overall
stats.

It is also often useful to have information about what's been happening
recently, rather than totals of all activity for the system boot.

It's suggested to dump a line about which wakeup source
aborted suspend to aid analysis of these situations.

Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
sync: Fix a race condition between release_obj and print_obj

Before this change, a timeline would only be removed from the timeline
list *after* the sync driver had its release_obj() called. However, the
driver's release_obj() may free resources needed by print_obj().

Although the timeline list is locked when print_obj() is called, it is
not locked when release_obj() is called. If one CPU was in print_obj()
when another was in release_obj(), the print_obj() may make unsafe
accesses.

It is not actually necessary to hold the timeline list lock when calling
release_obj() if the call is made after the timeline is unlinked from
the list, since there is no possibility another thread could be in --
or enter -- print_obj() for that timeline.

This change moves the release_obj() call to after the timeline is
unlinked, preventing the above race from occurring.

Change-Id: I027827f87afe74876bab738c842d16c6a9420973
Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: re-calculate a cpu's next_balance point upon sched domain changes

Commit 55ddeb0f (sched: Reset rq->next_interval before going idle) reset
a cpu's rq->next_balance when pulled_task = 0, which will be true when
the cpu failed to pull any task, causing it go idle. However that patch
relied on next_balance being calculated as a result of traversing cpu's
sched domain hierarchy.

A cpu that is the only online cpu will however not be attached to any
sched domain hierarchy. When such a cpu calls into idle_balance(), we
will end up initializing next_balance to be 1sec away! Such a CPU will
defer load balance check for another 1sec, even though we may bring up
more cpus in the meantime requiring it to check for load imbalance more
frequently. This could then lead to increased scheduling latency for
some tasks.

This patch results in a cpu's next_balance being re-calculated when its
attaching to a new sched domain hierarchy.  This should let cpus call
load balance checks at the right time we expect them to!

Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
(cherry picked from commit 91b609bdd91513c37c410ffef0204f8a0578e4f8)

Change-Id: Ib457f1a357aad26e49837a01311b73e22e0cc26f
Signed-off-by: Sridhar Nelloru <nellos@codeaurora.org>
HACK: ARM: disable sleeping while atomic warning in do_signal

ARM disables interrupts in do_signal, which triggers a warning in
try_to_freeze, see details at https://lkml.org/lkml/2011/8/23/221.
To prevent the warnings, add try_to_freeze_nowarn and call it from
do_signal.

Change-Id: If7482de21c386adc705fa1ac4ecb8c7ece5bb356
Signed-off-by: Colin Cross <ccross@android.com>
lockdep: remove task argument from debug_check_no_locks_held

The only existing caller to debug_check_no_locks_held calls it
with 'current' as the task, and the freezer needs to call
debug_check_no_locks_held but doesn't already have a current
task pointer, so remove the argument.  It is already assuming
that the current task is relevant by dumping the current stack
trace as part of the warning.

This was originally part of 6aa9707099c (lockdep: check that
no locks held at freeze time) which was reverted in
dbf520a9d7d4.

Change-Id: Idbaf1332ce6c80dc49c1d31c324c7fbf210657c5
Original-author: Mandeep Singh Baines <msb@chromium.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Revert "PM: wakelock: Abort task freezing if a wake lock is held."

This reverts commit 649c5ec14ad0ed76f09262de5dad19c88801e886.
freezer: shorten freezer sleep time using exponential backoff

All tasks can easily be frozen in under 10 ms, switch to using
an initial 1 ms sleep followed by exponential backoff until
8 ms.  Also convert the printed time to ms instead of centiseconds.

Change-Id: I7b198b16eefb623c2b0fc45dce50d9bca320afdc
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
freezer: skip waking up tasks with PF_FREEZER_SKIP set

Android goes through suspend/resume very often (every few seconds when
on a busy wifi network with the screen off), and a significant portion
of the energy used to go in and out of suspend is spent in the
freezer.  If a task has called freezer_do_not_count(), don't bother
waking it up.  If it happens to wake up later it will call
freezer_count() and immediately enter the refrigerator.

Combined with patches to convert freezable helpers to use
freezer_do_not_count() and convert common sites where idle userspace
tasks are blocked to use the freezable helpers, this reduces the
time and energy required to suspend and resume.

Change-Id: I6ba019d24273619849af757a413271da3261d7db
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
futex: use freezable blocking call

Avoid waking up every thread sleeping in a futex_wait call during
suspend and resume by calling a freezable blocking call.  Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.

This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.

Change-Id: I9ccab9c2d201adb66c85432801cdcf43fc91e94f
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
nanosleep: use freezable blocking call

Avoid waking up every thread sleeping in a nanosleep call during
suspend and resume by calling a freezable blocking call.  Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.

This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.

Change-Id: I93383201d4dd62130cd9a9153842d303fc2e2986
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
tracing/sched: Add trace events to track cpu hotplug.

Add ftrace event trace_sched_cpu_hotplug to track cpu
hot-add and hot-remove events.

This is useful in a variety of power, performance and
debug analysis scenarios.

Change-Id: I5d202c7a229ffacc3aafb7cf9afee0b0ee7b0931
Signed-off-by: Arun Bharadwaj <abharadw@codeaurora.org>