ASoC: wcd9xxx: Do not use dapm to power up cdc-vdd-mic-bias

Do not use alsa dapm to power up cdc-vdd-mic-bias power supply.
Due to sound card is not initialized, powering up this dapm widget
would get delayed. This leads to wrong mbhc calibration values.

Change-Id: I4e1f3cf523ea9f771b9993317dfd515def2b0615
Signed-off-by: Phani Kumar Uppalapati <phaniu@codeaurora.org>
ASoC: wcd9xxx: Do not acquire codec resource lock to get hph impedance

Acquiring codec resource lock within get impedance function may
cause deadlock when headset inserted/removed repeatedly. Remove
the lock as it is not required to be protected with a mutex.

CRs-fixed: 597226
Change-Id: I20865e0b2bb193f2f8777f2b69e735a0d4997cca
Signed-off-by: Phani Kumar Uppalapati <phaniu@codeaurora.org>
Revert "ASoC: msm: qdsp6v2: disable OCMEM by default"

This reverts commit c7dbbcf2a34c9ec7bf5ca2b474649908a48b2ecf.
Revert changes to disable OCMEM for Audio and Voice use-cases
by default.

Change-Id: I814efe272c8051417753bae2fc6fe805bd817921
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
SELinux: Fix memory leak upon loading policy

commit 8ed814602876bec9bad2649ca17f34b499357a1c upstream.

Hello.

I got below leak with linux-3.10.0-54.0.1.el7.x86_64 .

[  681.903890] kmemleak: 5538 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

Below is a patch, but I don't know whether we need special handing for undoing
ebitmap_set_bit() call.
----------
>>From fe97527a90fe95e2239dfbaa7558f0ed559c0992 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Mon, 6 Jan 2014 16:30:21 +0900
Subject: SELinux: Fix memory leak upon loading policy

Commit 2463c26d "SELinux: put name based create rules in a hashtable" did not
check return value from hashtab_insert() in filename_trans_read(). It leaks
memory if hashtab_insert() returns error.

  unreferenced object 0xffff88005c9160d0 (size 8):
    comm "systemd", pid 1, jiffies 4294688674 (age 235.265s)
    hex dump (first 8 bytes):
      57 0b 00 00 6b 6b 6b a5                          W...kkk.
    backtrace:
      [<ffffffff816604ae>] kmemleak_alloc+0x4e/0xb0
      [<ffffffff811cba5e>] kmem_cache_alloc_trace+0x12e/0x360
      [<ffffffff812aec5d>] policydb_read+0xd1d/0xf70
      [<ffffffff812b345c>] security_load_policy+0x6c/0x500
      [<ffffffff812a623c>] sel_write_load+0xac/0x750
      [<ffffffff811eb680>] vfs_write+0xc0/0x1f0
      [<ffffffff811ec08c>] SyS_write+0x4c/0xa0
      [<ffffffff81690419>] system_call_fastpath+0x16/0x1b
      [<ffffffffffffffff>] 0xffffffffffffffff

However, we should not return EEXIST error to the caller, or the systemd will
show below message and the boot sequence freezes.

  systemd[1]: Failed to load SELinux policy. Freezing.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sched,rt: fix isolated CPUs leaving root_task_group indefinitely throttled

commit e221d028bb08b47e624c5f0a31732c642db9d19a upstream.

Root task group bandwidth replenishment must service all CPUs, regardless of
where the timer was last started, and regardless of the isolation mechanism,
lest 'Quoth the Raven, "Nevermore"' become rt scheduling policy.

Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1344326558.6968.25.camel@marge.simpson.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sched/rt: Avoid updating RT entry timeout twice within one tick period

commit 57d2aa00dcec67afa52478730f2b524521af14fb upstream.

The issue below was found in 2.6.34-rt rather than mainline rt
kernel, but the issue still exists upstream as well.

So please let me describe how it was noticed on 2.6.34-rt:

On this version, each softirq has its own thread, it means there
is at least one RT FIFO task per cpu. The priority of these
tasks is set to 49 by default. If user launches an RT FIFO task
with priority lower than 49 of softirq RT tasks, it's possible
there are two RT FIFO tasks enqueued one cpu runqueue at one
moment. By current strategy of balancing RT tasks, when it comes
to RT tasks, we really need to put them off to a CPU that they
can run on as soon as possible. Even if it means a bit of cache
line flushing, we want RT tasks to be run with the least latency.

When the user RT FIFO task which just launched before is
running, the sched timer tick of the current cpu happens. In this
tick period, the timeout value of the user RT task will be
updated once. Subsequently, we try to wake up one softirq RT
task on its local cpu. As the priority of current user RT task
is lower than the softirq RT task, the current task will be
preempted by the higher priority softirq RT task. Before
preemption, we check to see if current can readily move to a
different cpu. If so, we will reschedule to allow the RT push logic
to try to move current somewhere else. Whenever the woken
softirq RT task runs, it first tries to migrate the user FIFO RT
task over to a cpu that is running a task of lesser priority. If
migration is done, it will send a reschedule request to the found
cpu by IPI interrupt. Once the target cpu responds the IPI
interrupt, it will pick the migrated user RT task to preempt its
current task. When the user RT task is running on the new cpu,
the sched timer tick of the cpu fires. So it will tick the user
RT task again. This also means the RT task timeout value will be
updated again. As the migration may be done in one tick period,
it means the user RT task timeout value will be updated twice
within one tick.

If we set a limit on the amount of cpu time for the user RT task
by setrlimit(RLIMIT_RTTIME), the SIGXCPU signal should be posted
upon reaching the soft limit.

But exactly when the SIGXCPU signal should be sent depends on the
RT task timeout value. In fact the timeout mechanism of sending
the SIGXCPU signal assumes the RT task timeout is increased once
every tick.

However, currently the timeout value may be added twice per
tick. So it results in the SIGXCPU signal being sent earlier
than expected.

To solve this issue, we prevent the timeout value from increasing
twice within one tick time by remembering the jiffies value of
last updating the timeout. As long as the RT task's jiffies is
different with the global jiffies value, we allow its timeout to
be updated.

Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Fan Du <fan.du@windriver.com>
Reviewed-by: Yong Zhang <yong.zhang0@gmail.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1342508623-2887-1-git-send-email-ying.xue@windriver.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[ lizf: backported to 3.4: adjust context ]
Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fix false disconnect due to a signal sent to the reading process

- In the current implementation, when a signal is sent to the reading process,
  read is cancelled by calling usb_ep_dequeue, which lead into calling
  acc_complete_out with ECONNRESET, but the current logic treats it as
  disconnection, which makes the device inaccessible until cable is actually
  disconnected.
- The fix calls disconnect only when ESHUTDOWN error is passed.
- If data has already arrived while trying cancelling, the data is marked
  as available, and it will be read out on the next read. This is necessary
  as USB bulk is assumed to guarantee no data loss.

Signed-off-by: keunyoung <keunyoung@google.com>
msm: kgsl: Don't block on detach if the context is invalid

An invalidated context means that something pretty nasty happened and
likely there was an unrecovered GPU fault along the way. If this is
the case then the GPU is likely not processing commands for the context
anymore. Don't block for the last retired global if the context was
invalidated.

Change-Id: Ic0dedbad22a22b704baf14557d7e18cc4cf1044a
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Refcount mmu clock calls and allow multiple disable events

Allow each mmu clock enable call to enable the clock and let the
clock driver refcounting mechanism deal with switching the clock
off at the right time. This also means that each enable call should
have a disable call or a disable event registered, so allow for
multiple disable events to be registered. This simplifies the mmu
clock handling mechanism which is better for multiple ringbuffer
implementation. With multiple ringbuffers each global timestamp is
tied to a specific ringbuffer and with a single clock disable event
it is hard to figure out when the clock should be turned off.

CRs-fixed: 597193 592485
Change-Id: I924c545140bd19d95890a5fdfd0382c511abe973
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Tarun Karra <tkarra@codeaurora.org>
msm: mdss: Display splash screen during boot up

It is required to display the splash screen as soon
as fb driver is probed. This shows the device life
at early stage before boot animation rendered by
surface flinger. Current implementation shows the
splash screen only when continuous splash is disabled.

Change-Id: Ib1e049c9ae82a621cc709339414096b954d79a09
Signed-off-by: Dhaval Patel <pdhaval@codeaurora.org>
msm: mdss:Add splash logo configuration entry in fb

Framebuffer driver displays penguin logo image
for all targets. Bootloader also displays the
same image. However, customer has to change this
boot image at two places if they want to display
different image than penguin logo. This change allows
customer to disable/enable the splash image from
framebuffer driver.

Change-Id: I56e78ce93aa8c218adffef03bfebd462d6bda254
Signed-off-by: Dhaval Patel <pdhaval@codeaurora.org>
msm: pm: Notify secure code of L2 power mode from last core only

Notify secure code L2 low power mode only if the current core is the
last core down. In certain scenarios, its possible that Linux and
secure code have different views of what a last core and could result in
secure code not invalidating a cache when the L2 was placed in a
non-retention mode.

Consider a two core scenario where Core 1 is power collapsed and Core 0
is the last core down setting L2 to be invalidated. Before Core 0 makes
the scm call, its possible that is interrupted to process a secure
interrupt. If the Core 1 wakes up in this time and decides to vote a
different L2 mode, this mode wouldn't be consistent with what Core 0
passes down to secure code when resuming from interrupt handling. In
these cases, the secure code could end up incorrectly invalidating the L2
on warmboot.

Also, the secure code and Linux should have a consistent view of what
last core down is to flush and invalidate L2. To ensure this, acquire a
remote (hardware) spinlock to serialize the last portion of the
power-collapse sequence. The remote spinlock will be released by the
secure code after it acquires its own lock to serialize the power
collapse sequence.

Change-Id: Ib5e2f360fddce558d22ce094dd7755c395c45a8c
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: pm: Acquire scm_handoff_lock conditionally

Acquisition of the scm_handoff_lock requires a TrustZone software
image that will release the lock. Without this, a deadlock will
occur since the lock will remain held forever.

Since this lock is only really needed if the qcom,allow-synced-levels
property is specified for the lpm-levels device, conditionally acquire
the lock based on this property. This avoid the TrustZone software
dependency when qcom,allow-synced-levels is not specified.

Change-Id: I8f8f1e4f9bdab6e70ef2a5484faba4e8ce8ac20c
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: remote_spinlock: Add support for remote_spin_lock_rlock_id()

remote_spin_lock_rlock_id() and remote_spin_unlock_rlock() are
added to acquire/release a raw remote lock (without a local
spinlock). This is useful when ownership of a lock must transfer
between different execution environments, such as when a lock is
used to guarantee atomicity of a set of actions spread across
different execution environments.

Specifically, these APIs are added to support a new lock which
must be acquired in Linux but released by TrustZone software.

Because no local spinlock is acquired, each thread must use a
different ID so that only one thread can proceed through the
lock at a time.

Support for these new APIs is presently implemented only for
SFPB locks.

Change-Id: Ifc5b1f552090051d2e975107e56e21e22df08924
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>