Sensors: Invensense Motion Apps 5.1.6 Release Candidate 33

Changes:
- Improved the handling of the biases both for factory calibration and
  runtime calibration via the gyro and accel offset and dmp_bias sysfs
  entries
- Prevented a possible race condition in batch mode settings
- Improved the data flow handling for some sensors and sensor scenarios
- Keep track of the batch mode requests for sensors even if the system
  proceeds in continuous mode - necessary when batch mode is restored
- Changed pressure values to floating point for better resolution
- Pedometer time and steps representation is now 64 bits
- Fixes a number of sensor combination corner cases involving Pedometer
  Step Detector
- Fixed long term drift issue in batched Game Rotation Vector
- Fixed misconfiguration caused by Significant Motion getting detected
  while working with other sensors
- Fixed Linear Accelerometer sample count in batching
- Fixed handling of the rates with combination of sensors involving
  virtual sensors
- Output all the data in the FIFO when a Significant Motion is detected.
  Do the same when the system comes back up from suspended.
- Fixed sensors getting left wrongly configured and not outputting any
  data when other sensors are enabled or disabled
- Fixed duplicated timestamp issues with Gravity vector sensor
- Fixed problems with the sensor rates in continuous and batch mode
- Fixed a problem causing high timestamp variance for the Gyroscope sensor
  while running the Step Detector sensor
- Applied patch to self-test fail on heamerhead

Change-Id: I6c54e5aadd9a57fc38a8de8015fc009f1652a90c
Signed-off-by: chohee.park <chohee.park@lge.com>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
Motion Apps 5.1.6 Release Candidate 54

Changes since MA 5.1.6 RC33

- Integrated flush feature within batching support with FLUSH_COMPLETE
  metadata indicator
- Handling accelerometer biases through the device's offset registers
  as for the gyroscope
- Added ability to write the accelerometer and gyroscope biases
  on the offset registers directly after self-test test execution
  for more seamless production floor handling
- Fixed batch mode timestamps across system suspend and resumes
- Estimate the timestamps using the devices's clock more reliably;
- Output the data in the FIFO when switching data mode (batching
  to continuous and vice versa, change of rate, addition/removal of a sensor)
- Accelerometer auto calibration does not overwrite the self-test accelerometer
  biases unless they are improving
- Added dynamic control of the HAL and SensorService logging
  using Android properties.

Change-Id: I94cf6eaedeb719f0bc2292c1dcfd20e24d8134f7
Signed-off-by: chohee.park <chohee.park@lge.com>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
spi_qsd: Add high speed mode support

The SPI mini-core has a specialized signal sampling mode which
improves signal to noise ratio for bus rates that are greater
then or equal to 26MHz.
This patch sets the mini-core in high-speed mode whan
the bus rate is greater or equal to this limit.

CRs-Fixed: 460451
Change-Id: I9a5094c92f3be8b683cd28a7737501d26b45b082
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
slim_msm: Support TX message queues

TX message queues are setup using BAM descriptors and event to
notify when the descriptor is done. This type of access ensures
lesser interrupts for slimbus controller, and offloads CPU from
copying message buffer into registers.
At this time, TX message queues are enabled on non-ported generic
device per HW recommendation.

Change-Id: I26423ef4d9fb3d54594d64555417f9a0c1dac37d
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Add support for report-absent and device-down notification

device_down callback will be called when the device sends
report-absent message per slimbus specification, or if the device
cannot be reached due to some other reason (e.g. bus going down).
device_up will be called when the device sends reports present again.

Change-Id: Ie48c2e3891b55cb1ec9c675a32cdb0a568fdcc18
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Glenn Kasten <gkasten@google.com>
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.