mfd: pm8xxx-misc: Add API to read PMIC registers

This API reads the PMIC registers at runtime and can be called
from process/interrupt context. It is currently enabled for PM8921.

Change-Id: I63a80293e37725569d075de814f27f67382976ca
Signed-off-by: Anirudh Ghayal <aghayal@codeaurora.org>
Fix pairing not successful when remote reports missing pin

Fix was added to update the LE Connection parameters to speed
up pairing before sending pairing request from the host.

CRs-fixed: 459212
Change-Id: Iac52fd90007dcb4ca3dc6e0fd612eba104fb83c2
Signed-off-by: Archana Ramachandran <archanar@codeaurora.org>
mm-camera: Changes to remove unused code for security issue reported

Changes to remove MSM_CAM_IOCTL_SET_MEM_MAP_INFO Ioctl support.
This will avoid physical memory mapping to userspace.

Change-Id: If014e6d152786b508c8e7ee6c53631913cd4cfcf
Signed-off-by: Guruprasad Gaonkar <ggaonk@codeaurora.org>
mmc: core: Don't cancel detect work during MMC suspend

When MMC host is suspending the cancellation of the MMC detect
work is in progress. And mmc_rescan() which had triggered for
SD card is blocked since mmcqd/1 has acquired the host lock.
The mmcqd/1 is waiting to proceed for the card status check.
Meanwhile, a write request is received on eMMC but it cannot
proceed as it is waiting for the ongoing runtime suspend to finish.

"kworker/0:1"
----
-000|need_resched()
-001|schedule_timeout(timeout = 2147483647)
-002|wait_for_common(x = 0xD9391E90, ?, state = 2, iowait = 0)
-003|flush_workqueue(wq = 0xD92DCA80)
-004|mmc_suspend_host(host = 0xD8B20000)
-005|msmsdcc_runtime_suspend(dev = 0xC08B0598)
-006|pm_generic_runtime_suspend(?)
-007|__rpm_callback(cb = 0xC02F1BD8, dev = 0xC08B0598)
-008|rpm_suspend(dev = 0xC08B0598, rpmflags = 2)
-009|pm_runtime_work(work = 0xC08B065C)
-010|process_one_work(worker = 0xD9367F40, work = 0xC08B065C)
-011|worker_thread(__worker = 0xD9367F40)
-012|kthread(_create = 0xD924FF18)
-013|kernel_thread_exit(asm)
 ---|end of frame
    |

"kworker/u:4"
----
-000|need_resched()
-001|__mmc_claim_host(host = 0xD8B21000, abort = 0x0)
-002|mmc_sd_detect(host = 0xD8B21000)
-003|mmc_rescan(work = 0xD8B212A0)
-004|process_one_work(worker = 0xCDB12440, work = 0xD8B212A0)
-005|worker_thread(__worker = 0xCDB12440)
-006|kthread(_create = 0xD8BC7F18)
-007|kernel_thread_exit(asm)
 ---|end of frame
    |

mmcqd/1 (running)
----
-000|need_resched()
-001|schedule_timeout(timeout = 2147483647)
-002|io_schedule_timeout(timeout = 2147483647)
-003|wait_for_common(x = 0xD8633E2C, ?, state = 2, iowait = 1)
-004|mmc_wait_for_req_done(host = 0xD8B21000, mrq = 0xD8633E1C)
-005|mmc_wait_for_cmd(host = 0xD8B21000, cmd = 0xD8633E50, retries = 5)
-006|get_card_status(card = 0xD8D8B800, status = 0xD8633EA4, retries = 5)
-007|mmc_blk_err_check(card = 0xD8D8B800, areq = 0xD8624440)
-008|mmc_start_req(host = 0xD8B21000, areq = 0x0, error = 0xD8633F4C)
-009|mmc_blk_issue_rw_rq(mq = 0xD8624008, ?)
-010|mmc_blk_issue_rq(mq = 0xD8624008, req = 0x0)
-011|mmc_queue_thread(d = 0xD8624008)
-012|kthread(_create = 0xD9397D80)
-013|kernel_thread_exit(asm)
 ---|end of frame
    |

mmcqd/0
----
-000|need_resched()
-001|rpm_resume(dev = 0xC08B0598, rpmflags = 4)
-002|__pm_runtime_resume(dev = 0xC08B0598, rpmflags = 4)
-003|msmsdcc_enable(mmc = 0xD8B20000)
-004|__mmc_claim_host(host = 0xD8B20000, abort = 0x0)
-005|mmc_blk_issue_rq(mq = 0xD8C43008, req = 0xC52C9798)
-006|mmc_queue_thread(d = 0xD8C43008)
-007|kthread(_create = 0xD9397D80)
-008|kernel_thread_exit(asm)
 ---|end of frame
    |

So remove the cancellation of the detect work for the
MMC suspend to proceed and avoid this deadlock.

CRs-Fixed: 471053
Change-Id: Id79d6b81e992b08039d639b1c0f6c2eb4a79df62
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
gpu: ion: enable the kmalloc heap

There are some Ion clients who would like to use the kmalloc
heap. Enable it.

Change-Id: Ie818be9e1211d52d489ad2cb63d94e2fddfc0f01
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
spi_qsd: Correction in DMA mode check.

Due to bug in the if() condition msm_use_dm function
is always returning '0' when cs_change is true. Due to
this issue the DMA mode is not bieng used when it has to be.

This patch fixes this issue.

CRs-Fixed: 475841
Change-Id: Ib4d7c4f816c2df71683d0901eb0fab78f441a208
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
msm: ipc: Add check to avoid integer & buffer overflow

In IPC Router service lookup operation, add check to avoid an integer
overflow and hence a buffer overflow.

CRs-Fixed: 457402
Change-Id: Ibe949fe20aad88b15679bdc96ebc505e4395ac3b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
msm_serial_hs: Donot register UART device as PM runtime active

Currently UART device is being registered as PM runtime active
in probe() and set as suspended in shutdown(). With this UART
driver PM runtime suspend is being called when system suspend
is invoked and while resuming from the same which invokes UART
driver LPM functionality. It causes UART communication to stop
if both UART Tx and RX FIFO are empty.

This change donot register UART device as PM runtime active
device as UART driver doesn't use PM runtime APIs for its LPM
functionality.

Change-Id: I33d0c95e4227fdb1b7d6d514498e161e6e4df465
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
media: dvb: Fix SDMX process size when crossing limit in TSIF

When playing live from TSIF, TS packet is always 192 bytes long.
The SDMX process limit size was not calculated correctly taking
this case into account.

Change-Id: Id80da8b648cabb222a179c1d49cacdb138f94316
Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org>
msm: SSR: Fix problems with concurrent SSRs

If one SSR call comes in and queues a work and the work item
starts running and then another SSR call comes in we will end up
with a running work item and a pending work item. The pending
work item will not run until the running work item completes.
With the current code the work item will run to completion and
then the pending work item will run and restart the subsystem
again.

This is wrong since we want to 'short-circuit' the code in this
case and do nothing if multiple SSR calls come in while the
subsystem is in the 'crashed' state.  Add state tracking logic so
that we know what part of the restart process a particular
subsystem is in and use it to fix this problem.

Conflicts:

	arch/arm/mach-msm/subsystem_restart.c

Change-Id: Iac8713951af1f290af1df7e94468d1843fc7980b
CRs-Fixed: 397848
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
ASoC: msm: Add support to have FM playback through ASM loopback mode

- Add support to provide PP on FM playback.
- Add PCM platform driver which enables ASM loopback mode
Define MultiMedia6 front-end dai

Change-Id: Ibf9d2645e706f9a3027dd356223a2135224a0337
Signed-off-by: Damir Didjusto <damird@codeaurora.org>
ASoC: msm: Add msm-pcm-loopback device

Add msm-pcm-loopback platform device for FM loopback

Change-Id: Ic86f9d92d75bd7c19e3f2d827a4114f6828a7ce8
Signed-off-by: Damir Didjusto <damird@codeaurora.org>
ASoC: msm: Add MultiMedia6 dai link

Add MultiMedia6 dai link for FM loopback.

Change-Id: I08118c9c5add4dba2aaf4af620058dbc9160696d
Signed-off-by: Damir Didjusto <damird@codeaurora.org>
ASoC: msm: flush if prior and current backends rate not matching

It is found that during device switch from one backend
with one sample rate to another backend with another sample rate,
the command to QDSP6 ADM which maps audio stream session to a
particular backend would not get carried out until pending
data of audio stream session from previous backend is either
read out or flushed. This scenario occurs when application
stops providing more buffers to retrieve captured data.
Remedy is to flush upon detection of rate mismatching

Change-Id: I2c01c036d9bb71f938a6795337f08948bd986553
CRs-fixed: 422205
Signed-off-by: Patrick Lai <plai@codeaurora.org>
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
ASoC: msm: Handle data loss at device switch for FM

- When device switch happens there are underflow errors
in LPASS. And there is some break in audio observed for
around 2 sec.
- To handle this, ASM run command needs to be sent again
to DSP at device switch.

Change-Id: I26135ad9267ec5c018708b780b86b7cb4998aa0a
Signed-off-by: Laxminath Kasam <lkasam@codeaurora.org>
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
msm_fb: Remove the extra freelist in display_commit

There is an extra freelist call to unmap IOMMU source buffers
in display_commit for LCDC interface. This is causing IOMMU
page faults during boot up on targets with LCDC interfaces.
Remove this extra freelist call.

Change-Id: I12a905efc82c5b9751acbc5941a66d0b58027509
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>
USB: android: Fix kernel panic during ACM enable

92fe88c8 commit (usb: gadget: Support multiple HSIC transport
instances for dun and rmnet) introduced a sysfs file called
"transport_names" for DUN and RMNET to accept transport names
from user space.  The transport names are used for registering
platform drivers.  Update ACM function too.  Otherwise NULL
string is used to register platform driver and kernel panics.

CRs-Fixed: 479434
Change-Id: I88b56f252f74bcfb2e664a6e37b64fe224739381
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
mmc: block: reduce the block timeout to 30 secs

After completion of block write request, MMC block driver waits for the
card to come out of the programming state. If card doesn't come out of
the programming state in 10 mins, it would be considered as error
condition and card would reinitialized. But this 10 mins is just too huge
and if card is continuously stuck in programming state for 10 mins,
mmcqd thread would take increase the CPU load significantly as we are
continuously polling for the card status (by sending status commands).

This patch reduces this timeout from 10 mins to 30 secs which is quite
reasonable for all well-behaved cards.

Change-Id: I4e8eaf29c836a81419220f312ee867b0dd5cccc7
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
ARM: Do 15e0d9e37c (ARM: pm: let platforms select cpu_suspend support) properly

commit b6c7aabd923a17af993c5a5d5d7995f0b27c000a upstream.

Let's do the changes properly and fix the same problem everywhere, not
just for one case.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hrtimer: Don't reinitialize a cpu_base lock on CPU_UP

commit 84cc8fd2fe65866e49d70b38b3fdf7219dd92fe0 upstream.

The current code makes the assumption that a cpu_base lock won't be
held if the CPU corresponding to that cpu_base is offline, which isn't
always true.

If a hrtimer is not queued, then it will not be migrated by
migrate_hrtimers() when a CPU is offlined. Therefore, the hrtimer's
cpu_base may still point to a CPU which has subsequently gone offline
if the timer wasn't enqueued at the time the CPU went down.

Normally this wouldn't be a problem, but a cpu_base's lock is blindly
reinitialized each time a CPU is brought up. If a CPU is brought
online during the period that another thread is performing a hrtimer
operation on a stale hrtimer, then the lock will be reinitialized
under its feet, and a SPIN_BUG() like the following will be observed:

<0>[   28.082085] BUG: spinlock already unlocked on CPU#0, swapper/0/0
<0>[   28.087078]  lock: 0xc4780b40, value 0x0 .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1
<4>[   42.451150] [<c0014398>] (unwind_backtrace+0x0/0x120) from [<c0269220>] (do_raw_spin_unlock+0x44/0xdc)
<4>[   42.460430] [<c0269220>] (do_raw_spin_unlock+0x44/0xdc) from [<c071b5bc>] (_raw_spin_unlock+0x8/0x30)
<4>[   42.469632] [<c071b5bc>] (_raw_spin_unlock+0x8/0x30) from [<c00a9ce0>] (__hrtimer_start_range_ns+0x1e4/0x4f8)
<4>[   42.479521] [<c00a9ce0>] (__hrtimer_start_range_ns+0x1e4/0x4f8) from [<c00aa014>] (hrtimer_start+0x20/0x28)
<4>[   42.489247] [<c00aa014>] (hrtimer_start+0x20/0x28) from [<c00e6190>] (rcu_idle_enter_common+0x1ac/0x320)
<4>[   42.498709] [<c00e6190>] (rcu_idle_enter_common+0x1ac/0x320) from [<c00e6440>] (rcu_idle_enter+0xa0/0xb8)
<4>[   42.508259] [<c00e6440>] (rcu_idle_enter+0xa0/0xb8) from [<c000f268>] (cpu_idle+0x24/0xf0)
<4>[   42.516503] [<c000f268>] (cpu_idle+0x24/0xf0) from [<c06ed3c0>] (rest_init+0x88/0xa0)
<4>[   42.524319] [<c06ed3c0>] (rest_init+0x88/0xa0) from [<c0c00978>] (start_kernel+0x3d0/0x434)

As an example, this particular crash occurred when hrtimer_start() was
executed on CPU #0. The code locked the hrtimer's current cpu_base
corresponding to CPU #1. CPU #0 then tried to switch the hrtimer's
cpu_base to an optimal CPU which was online. In this case, it selected
the cpu_base corresponding to CPU #3.

Before it could proceed, CPU #1 came online and reinitialized the
spinlock corresponding to its cpu_base. Thus now CPU #0 held a lock
which was reinitialized. When CPU #0 finally ended up unlocking the
old cpu_base corresponding to CPU #1 so that it could switch to CPU
#3, we hit this SPIN_BUG() above while in switch_hrtimer_base().

CPU #0                            CPU #1
----                              ----
...                               <offline>
hrtimer_start()
lock_hrtimer_base(base #1)
...                               init_hrtimers_cpu()
switch_hrtimer_base()             ...
...                               raw_spin_lock_init(&cpu_base->lock)
raw_spin_unlock(&cpu_base->lock)  ...
<spin_bug>

Solve this by statically initializing the lock.

Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Link: http://lkml.kernel.org/r/1363745965-23475-1-git-send-email-mbohan@codeaurora.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>