cpufreq: interactive: tone up a little bit.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
lib/decompress_unlz4.c: always set an error return code on failures

"ret", being set to -1 early on, gets cleared by the first invocation of
lz4_decompress()/lz4_decompress_unknownoutputsize(), and hence subsequent
failures wouldn't be noticed by the caller without setting it back to -1
right after those calls.

Reported-by: Matthew Daley <mattjd@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Kyungsik Lee <kyungsik.lee@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Merge branch 'nightlies' of https://github.com/franciscofranco/hammerhead into nightlies
thermal: add a 5C threshold to prevent throttled/unthrottled to be triggered a lot when the CPU temp dwells close to the temp threshold.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: subsystem_restart: Add notification to indicate powerup failure

Currently, if powering on a subsystem during restart fails, a
kernel panic is trigerred immediately.
Instead, send a 'powerup failure' notification to the drivers
that have registered for notifications regarding the subsystem.
The drivers can then do the necessary cleanup/logging before a
kernel panic is triggered.

Change-Id: I252f221ee009436b7075c203b2a3de45e395c1b0
Signed-off-by: Deepak Katragadda <dkatraga@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: ssr: Send notification during a cold boot failure

Currently, when powering on a subsystem during cold boot fails,
the drivers that have registered for notifications about the
subsystem are not intimated.
Send the 'powerup failure' notification to these drivers to give
them an opportunity to do the necessary cleanup/logging at their
end before the subsystem is shutdown.

Change-Id: I09c10d5ead7dc153ed3ce3caf8f1c3442a66eb96
Signed-off-by: Deepak Katragadda <dkatraga@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mmc: sdhci-msm: Correct usage of readl_poll_timeout() API

The intention of sdhci_msm_probe() was to wait up to 1ms for
CORE_SW_RST to be set, but only a 10us timeout was passed to
readl_poll_timeout().

Correct the timeout value to be 1ms, and decrease the sleep
time between read attempts to only 10us so that it's less
than the expected wait time of 40us.

Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
iopoll: Use ktime_get() instead of jiffies for timeout calculations

Presently, small timeout values will round up to 1 jiffy which,
on CONFIG_HZ=100 systems, corresponds to a full 10 milliseconds.
This is undesirable for drivers specifying timeouts of only a
few 10's of microseconds (which is common), since they may end
up tight-loop spinning for hundreds or thousands of times longer
than expected before reporting a timeout.

Additionally, jiffies cannot be reliably used with time_after()
when the value of jiffies is small (like 1). In rare but real
scenarios, jiffies may actually increment by more than 1 at a
time. Specifically, this will occur if interrupts are disabled
on for more than 1 jiffy (10 milliseconds for CONFIG_HZ=100) on
the CPU responsible for incrementing jiffies.

If interrupts are re-enabled on that CPU between the time the
iopoll code (on another CPU) calculates the timeout value of
jiffies and when the time_after() comparison is made, then the
iopoll APIs may return -ETIMEDOUT prematurely, even though the
specified timeout has not actually expired.

Using ktime_get() avoid this problem (which arguably also needs
a generic fix to avoid similar problems for other code which use
jiffies to calculate timeouts).

Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rtc: alarm: have dummy set_power_on_alarm function

When !CONFIG_RTC_CLASS we need to have a dummy set_power_on_alarm
function. Otherwise, it is easy to have build issues.

Change-Id: I39310241cc2e59f672964c8bc0ee4c3607aedf4e
Signed-off-by: Maria Yu <aiquny@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rtc: alarm: init power_on_alarm_lock mutex in alarmtimer_rtc_timer_init

Moved mutex_init of power_on_alarm_lock into alarmtimer_rtc_timer_init
so that if CONFIG_RTC_CLASS is not enabled, we dont try to initialize
the mutex.  This fixes a build issue when !CONFIG_RTC_CLASS

Change-Id: I270564b94fd54162aa177a2c9767655098662259
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rtc: alarm: Set power-on alarm 120 sec before actual alarm time

This will add extra buffer time for booting-up the device before
actual alarm expiration time.

Change-Id: I02cad84c394a6aab943fff37a1a0de56bb511f56
Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.org>
Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
kernel: alarm: :fix the BUG that device automatically powers on

The value of alarm.time is invalid if we get it by:
    memset(&alarm, 0, sizeof(alarm)).
So function of rtc_set_alarm aborts before it really calls into:
    rtc->ops->set_alarm.
Then we can`t disable the RTC alarm by that. The result is some
alarms enabled by alarm_suspend are not disabled correctly during
alarm_resume. And device will automatically power on.

CRs-fixed: 524051
Change-Id: Ibc99e62878d17ad4f50325630bf0862207e2cf3f
Signed-off-by: Figo Wang <figow@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
kernel: alarm: add dedicated alarm type for poweroff alarm

Now we use type of RTC_WAKEUP for the poweroff alarm.
Actually lots of other applications also use this type.
But these applications never expect the device will
power on after it has been shut down. So we need to
add dedicated alarm type for the Deskclock or similar
applications.

CRs-fixed: 529674
Change-Id: I9b7911906446daa1aeb5835478c9837f8ef797f2
Signed-off-by: Figo Wang <figow@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
kernel: alarm: Do not call rtc_alarm_irq_enable in IRQ Disabled context

Currently shutdown hook of alarm driver is calling
the rtc_alarm_irq_enable API in interrupts disabled
context. So fix the alarm_shutdown function to call
in API rtc_alarm_irq_enable in interrupt enabled context.

CRs-Fixed: 591790
Change-Id: Iebd82482be1dc95c6c978b617e1c18eb36e1b6eb
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rtc: alarm: Proper handling of spinlock

In alarm_shutdown hook, taking interruptible mutex
lock in interrupt disabled context. This patch fixes
alarm_shutdown function to call rtc_read_time and
rtc_set_alarm APIs in interrupt enabled context.

Change-Id: I9392d8908c19365993dccc22504f4b6f83ae8f72
CRs-Fixed: 619657
Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rtc: qpnp-rtc: Sets RTC time correctly

Currently RTC driver is not setting the RTC time
correctly. RTC H/w needs to be disabled before the
writes, and then re-enabled after the writes are completed.

Change-Id: I4f66a2ea5b8ba52a5e9dcf21da7a09c36b1c9074
CRs-Fixed: 610221
Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
kernel: alarm: setup the RTC immediately for poweroff alarm

Currently we setup the RTC for poweroff alarm when the system
performs shutdown. But if the phone is shut down unexpectedly
before that, the poweroff alarm can't work. So we can do that
immediately.

CR-fixed: 532743
Change-Id: Ib26a56fba8cd64efe94f2f07ee232482228429dc
Signed-off-by: Figo Wang <figow@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rtc: alarm: update power_on alarm setting logic

The previous power_on alarm value should be checked to avoid
cancelling the alarm by mistake.

CRs-fixed: 551966
Change-Id: I4de12265416fab41a9c591d09961c9fef0d25917
Signed-off-by: Xiaocheng Li <lix@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rtc: qpnp-rtc: Set alarm control register properly

RTC Alarm enable bit does not get conserved during
RTC probe function. This patch fixes that issue.

CRs-Fixed: 636652
Change-Id: I28203b8e301510d34d2e726c0bd25e78737f7524
Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
rtc:alarm: remove alarm_shutdown hook in alarm driver

Putting alarm_shutdown into set_power_on_alarm is to set rtc alarm
time immediately after an alarm being set. It can avoid shutting
down unexpectedly before calling alarm_shutdown hook like removing
battery.Then power_on_alarm will be set to rtc twice when an alarm
is created and the device performs shutdown for a power off alarm.
The set process during shutting down is duplicated to the set
process when an alarm is created. So the alarm_shutdown hook become
unnecessary.

CRs-Fixed: 639119
Change-Id: Ie46bcf6f568f04650d94ba40ad6d4521d31a2f96
Signed-off-by: Xiaocheng Li <lix@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>