mmc: core: remove duplicate code in mmc_rescan

If the card is removed, the wakelock has to be held for
an extended period of time to enable the user-space to
respond. The code to extend the wakelock has been
duplicated. This patch removes this duplicate code.

Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: block: fix race in deferred resume

The actual resume takes place when a request is received. In a
situation when mmcqd and qseecomd(rpmb) both try to resume the
device, a race is ensued. This is because mmcqd first resumes
the device and then claims the host. Ideally, if resume is in
progress in one context the resume in the other context should
be cancelled.
Claim the host before resuming the device in mmcqd context.

Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
[neo: Fix code format.]
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
mmc: core: Fix NULL pointer dereference issue with mmc_blk_reset()

If the mmc_hw_reset() fails, then host->card might be NULL in some
cases. Hence, check for reset errors and report it to the caller so
that the current request can be aborted and also check for host->card
before accessing it so as to prevent NULL pointer dereference issue.

Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: wcd9xxx: Avoid enabling button polling from event notify handler

During insertion, it is possible that recording is already
enabled from handset which will switch to headset. During
POST_MICBIAS_2_ON event, though button polling is not actually
enabled, due to polling_active becomes true, the event
notification handler pauses and re-starts button polling.
This could lead to unknown state for button polling state
machine.

Signed-off-by: Phani Kumar Uppalapati <phaniu@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: interactive: Add check_fast mode to raise freqs faster

It takes too long to scale from min_freq to max_freq. If you ignore
go_hispeed, then it takes over 100ms to step up through all the
frequencies. Even with go_hispeed, I think I figured it was 90ms to go
from idle to max speed.

The core of the problem is that a cpu_load << 100% is meaningful for
scaling.  As that load approaches 100% though, this estimate becomes
meaningless.

Here "meaningful" means that the speed adjusted load is a good approximation
of the total processing work needed and therefore good for estimating the
target frequency.

At 100% it is not meaningful because either it is a perfect estimate (had
we been running faster there is no more work we would have done) or off by
a factor of max_freq/min_freq in the worst case.

This patch recognizes this case and scales more aggressively.  At the same
time it also re-estimates in a shorter time to correct over/under scaling.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: interactive: Disable idle notifier

Instead, just always poll using the timer.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
out: audio: Add Low Latency policy and New rates

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: interactive: Best of all worlds

* We already have optimizations bt different pro
  developers. This patch just stitches all together.
* Needs to be tested. DO NOT MERGE without userspace
  changes.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>