msm: gpio-v2: Add support for irq_domains

irq_domains are necessary to support interrupt chip drivers with
the Device Tree. In addition, by registering with irq_domains,
other irq chip drivers on the system will respect the virq
allocations made by this driver.

The msm-gpio specification requires two interrupt-cells. The
first specifies the irq chip hwirq, and the second is a default
irq type configuration for the interrupt. It's still possible to
override the default configuration with request_irq() if one
chooses to.

Change-Id: If2d3ce321f4c9ec83b0ee41244533696192e1d42
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
msm: gpio-v2: Fix lockdep warning

In similar fashion as b5eee2f (ARM: mxc: Add missing lockdep
annotation, 2011-04-04) add a lock class so that lockdep knows
the gpio irqs are always locked correctly with respect to the
descriptor lock class.

=============================================
[ INFO: possible recursive locking detected ]
3.0.21-g51ce160-00020-g8eb5789-dirty #2894
---------------------------------------------
swapper/1 is trying to acquire lock:
 (&irq_desc_lock_class){-.....}, at: [<c01ceaf0>] __irq_get_desc_lock+0x74/0x8c

but task is already holding lock:
 (&irq_desc_lock_class){-.....}, at: [<c01ceaf0>] __irq_get_desc_lock+0x74/0x8c

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&irq_desc_lock_class);
  lock(&irq_desc_lock_class);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

3 locks held by swapper/1:
 #0:  (&__lockdep_no_validate__){+.+.+.}, at: device_attach+0x18/0xa4
 #1:  (&__lockdep_no_validate__){+.+.+.}, at: device_attach+0x18/0xa4
 #2:  (&irq_desc_lock_class){-.....}, at: __irq_get_desc_lock+0x74/0x8c

Change-Id: Icc0058370de4db17ae4fadb66f5fe970c37ecc6c
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
msm: gpio-v2: Fix spurious interrupts when gpio-irq is unmasked

To unmask a gpio interrupt, the gpio driver sets the
INTR_RAW_STATUS_EN and INTR_ENABLE bits in the INTR_CFG register.
As soon as the INTR_RAW_STATUS_EN is set, the INTR_STATUS is updated
and this causes a spurious interrupt when the irq is enabled.
This is noticed frequently when the gpio is pulled high and requests
a rising edge interrupt or pulled low and is requesting a falling edge
interrupt.
Due the internal circuit design of the TLMM IRQ block, the above method
causes a spurious interrupt when the irq was initialized.
Hence, to avoid this behavior we set the INTR_RAW_STATUS_EN, clear the
INTR_STATUS only once during setup. Every mask and unmask only toggles
the INTR_ENABLE bit.

CRs-Fixed: 346861
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
(cherry picked from commit b66ea9002b4c400809782e5f94b9f8c87b280381)

Change-Id: I21f4a41473ba4211aff0ef041e6e7260a6f72fd1
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
msm: gpio-v2: Re-arrange the write to RAW_STATUS_EN

Move enabling the RAW_STATUS_EN at the very beginning.
Hardware team clarified that it is better to write to
RAW_STATUS_EN before writing to any other INTR_CFG bits
in order to prevent spurious interrupts.
Removing writing to the GPIO_INTR_CFG_SU register
during every mask/unmask as it could cause spurious
interrupts as well.

Change-Id: Ifbd991364216ef5f163e5211bc35f7f145c75916
CRs-Fixed: 346861
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
msm: gpio-v2: Clear the interrupt status before unmasking

After the change to keep the RAW_STATUS_EN always on, the
interrupt status bit was latched and could be set during
other (non-interrupt) activity on the GPIO line. This would
end up triggering the interrupt as soon as it was unmasked.
Hence, clear the interrupt status before unmasking the gpio
interrupt.
This keeps the behavior and expectations same as when the
RAW_STATUS_EN was toggled and it prevented the interrupt
status from being updated while the interrupt was masked.

Change-Id: I2bbfa36e4ec0f4a961f05047f4061d7d8fc9fd2f
CRs-Fixed: 346861
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
msm: bam_dmux: fix duplicate dfab vote

If the A2 power collapse feature is disabled, bam_dmux will likely vote
for dfab twice in a row, which should not happen.  This is because the
first vote is done when it is assumed that A2 PC will be enabled, and that
vote is not accounted for in the internal driver state when A2 PC is
disabled.

CRs-Fixed: 361733
Change-Id: Ib3b1063dde5f3542b81d699b53d3e2cb35e40fa7
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
(cherry picked from commit 5f57ec970b0eff56c36bea196787c6aa6001993b)
msm: bam_dmux: Add locking around platform device calls

The channel state is used to determine if a platform device has been
registered on a particular channel.  In the case of a subsystem restart
while a channel is being opened, the subsystem restart can occur between
the channel state being set to opened and the platform device being
added.  This will result in the subsystem restart code seeing that the
channel is open and attempting to remove a platform device that has been
added.

This change adds mutex protection around the channel state updates and
the platform device add/remove calls to handle any race conditions.

CRs-fixed: 378060
Signed-off-by: Eric Holmberg <eholmber@codeaurora.org>
(cherry picked from commit a623da8bda62e95acf5991905af2847e8e326e09)

Change-Id: I8eef024141a2c81552439856aa9c77fc491354a3
Signed-off-by: Ramakrishna Prasad N <crpn@codeaurora.org>
msm: bam_dmux: Extend locking around SPS transfer call

When a new receive packet is created in queue_rx(), it is added to the
receive packet queue and also queued with the SPS driver.  Once the
packet is filled, then BAM DMUX calls sps_get_iovec() to get the filled
receive buffer.  BAM DMUX then pulls the receive packet info off of the
RX queue and compares the DMA address from the sps_get_iovec() call to
the expected DMA address.  In some cases, they do not match resulting in
BAM DMUX processing the wrong RX buffer.

Going back to the queue_rx() processing, the packet is added to the
receive queue with a mutex locked, but then the mutex is unlocked before
the call to sps_transfer_one() which allows a race condition to exist if
multiple threads call queue_rx().

During normal operation, queue_rx() is only called by the
single-threaded receive workqueue, but during the call to
reconnect_to_bam(), a race condition is expected between the call to
rx_siwtch_to_interrupt_mode() and the final call to queue_rx() if a
packet comes in and is processed before the queue_rx() call is
completed.

This change extends the receive pool mutex locking around
sps_transfer_one() call which resolves the issue.

CRs-Fixed: 377609
Change-Id: Iba5b10e291a1612846fa58dae87aadbd79aa297b
Signed-off-by: Eric Holmberg <eholmber@codeaurora.org>
(cherry picked from commit 00cf869cf08158aae15e568d687603512f99dfd6)
msm: cpufreq: fix a race between hotplug and cpufreq

When msm_cpufreq_target() is called without holding the policy
semaphore, there is a rare chance that the cpu gets hotplugged in
the acpuclk_set_rate. The probability of this issue increases
when cross-calling is used or using interactive governor which
tries to set all cpu frequencies from a single thread.

Add a hotplug notifier and set the device_suspended flag holding
the suspend mutex, when cpu is going down. This mutex is always
held when frequency changes are done.

Change-Id: Ide3aa6927ad60d2512d63761c51bb15117461250
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
msm: cpufreq: Check cpufreq_frequency_table NULL

This is required during single kernel binary support where one target
supports cpufreq and other target is at the initial stages of bringup.
Since we cannot remove CONFIG_CPU_FREQ_MSM from the config file, but
still support the boot on both of them adding a check for targets where
table is not initialized by the acpu clock driver.

Change-Id: I5f52c246586f0c0378a1b2873a064ef69601e3c6
Signed-off-by: Taniya Das <tdas@codeaurora.org>
msm: Asoc: audio: Migrate to ION from pmem, dma alloc

-Voice driver and RT proxy driver are using Pmem and
DMA alloc. Migrate them to use ION memory to save memory
and avoid stability issues.

CRs-Fixed: 369303
Change-Id: If58b69b9f8b7b03661a36451c1a5c27885fbf976
Signed-off-by: Laxminath Kasam <lkasam@codeaurora.org>
msm: Asoc: LPA: Fix pause and next clip play issue

- When paused and press next button to play next song,
sometimes CMD_EOS fails to get Ack from LPASS and
is wait timeout for 5sec causing delay for next
playback start.
- In the failure case, even before trigger start
of driver is done,LPA driver receives pcm_close.
In this case, though EOS is issued, it is not
getting honored from LPASS.
- If trigger start not happen in LPA driver,
avoid CMD_EOS to LPASS as it will not be handled.

CRs-Fixed: 368519, 366926
Change-Id: Ib5ff21925bb44849b27ed4709b72efcccf412b5d
Signed-off-by: Laxminath Kasam <lkasam@codeaurora.org>
ASoc: msm: Multi channel AAC clips don't play

Send channel mapping command to DSP; This command
is used to identify the output PCM buffers's
upsampling/downsampling sequence.

CRs-fixed: 351804 388355 351817
Signed-off-by: Swaminathan Sathappan <Swami@codeaurora.org>
(cherry picked from commit 6f53088ba27a28dc4b894180695538dfffaa7ef7)

Change-Id: I040d4c3ca7ef63c88133a798c1dc537f45c3e9b3
Signed-off-by: Ramakrishna Prasad N <crpn@codeaurora.org>
msm: audio: qdsp6v2: Fix voice RTAC

There was data type mismatch which caused the corruption during
memory copy. It leads to the voice RTAC failure.

CRs-Fixed: 391392
Signed-off-by: Jay Wang <jaywang@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/qdsp6v2/rtac.c

Change-Id: I300bd546aa5354885072c77a2e929285b6585d3f
Signed-off-by: Sudhir Sharma <c_sudsha@quicinc.com>
(cherry picked from commit 94c498ec3380730a511a888104eb3ead12161967)
mint: update cm defconfig

Change-Id: I520a27c5fc68d4e0bc8534bd1c754179ff058f5a
update defconfig

Change-Id: I31f9f86726e984f2a90d9e211c7fd20e6de3dedf
wcnss: Pre-alloc memory for WLAN driver

WLAN driver will use this pre-allocated memory (when available) for
large memory allocations; this will prevent WLAN driver load
failures because of the un-availability of the large size slabs
during module load.

Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
(cherry picked from commit 24db5288a9f82ced747746a2064a60f368ea6646)

Conflicts:

	drivers/net/wireless/Kconfig
	drivers/net/wireless/wcnss/wcnss_wlan.c
	include/linux/wcnss_wlan.h

Change-Id: I79da592689014a16e25382176e5edf8ea4e91d6c
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
(cherry picked from commit 60b943e1d425e76d250cb07563021140a21b9d93)
msm: mpdecision: Add in-kernel CPU hotplug management

mach-msm: Add msm_mpdecision Kconfig & Makefile hooks

Change-Id: I1bb994370cf5568c01b1e99d74475f5d1ec52fe4
Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: Add msm_mpdecision

This currently only does the following thing:
Screen on -> CPU1 online
Screen off -> CPU1 offline

More to come.

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: small cleanup

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: add load based decision making

This now works like the mpdecision binary from QCOM.
CPU hotplugging/unplugging based on system load.

A sysfs interface will be built in with a later commit.

Change-Id: I6b8307a8e9f7425d99a84eb25798e8498cb9ba5a
Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: restructure locks, add delay

The new delay allows the CPU to come up before any other action is taken.
This prevents fast plugging and also ensures the CPU hotplug process
is really done, before trying to unplug it again (or plug it).

The new locks are more efficient, and only used if necessary.

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: pause if CPU is unplugged outside of mpdecision

This fixes cpu wars if something else tries to control the cpus.
default delay: 10000ms

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: change early_suspend_level to blank_screen

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: don't start immediately

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: show cpumask after up/down

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: always set the suspend var

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: remove up/down delay, our default delay is large enough

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: remove debug output

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: add email to (c)

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: fix foreign hotplug/unplug detection

Signed-off-by: showp1984 <showp1984@gmail.com>

Conflicts:

	arch/arm/mach-msm/msm_mpdecision.c

mach-msm: mpdecision: show how long the cpu was online

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: rename msm_mpdec_suspend to msm_mpdec_cpudata

Since this is being used for more than suspend stuff the old name
just isn't accurate anymore.

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: add sysfs interface

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: increase startdelay for sense

Surprise! Sense needs a lot longer to boot up than aosp...

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: adjust thresholds for sense

Sense is just too hungry...

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: fix foreign cpu control detection

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: allow mpdecision to be disabled (sysfs)

This allows disabling/enabling of mpdecision over sysfs.

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: increase start delay for Sense

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: increase up threshold for Sense

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: sysfs: check if cpu is offline before hotplugging it

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: don't turn off cpu1 if freq > idle

This fixes cpu1 being turned off though it is still working
with a high frequency. The idle_freq can be modified through sysfs.

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: fixup: move idle block to mpdecision()

This belongs in mp_decision() because this influences the decision
mpdecision is about to make.

Signed-off-by: showp1984 <showp1984@gmail.com>

mach-msm: mpdecision: don't turn on cpu1 if cpu0 freq is below idle_freq
If the clock of cpu0 is below the set idle_freq don't enable cpu1 and
disregard the runqueue value.

Signed-off-by: showp1984 <showp1984@gmail.com>

msm: mpdecision: 8960 compat

Change-Id: I49541f2a644d61e567e9997a742f54154e703674

msm: mpdecision: Use the standard get_rate api

Change-Id: I738cfe2165899001a0fca37c1dd2a5746c6ba53b
msm: 8625: Disable Run Queue Statistics while running on single core.

This change disables Run Queue stats collection on single core targets.
Along with that this change also adds a new config option to make
RQS independent from SLEEP_STATS.

Change-Id: I27f5d7f35015378226215a40b961bbf059b8f502
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
cpufreq: interactive: take idle notifications only when active

Register an idle notifier only when the governor is active.  Also
short-circuit work of idle end if the governor is not enabled.

Signed-off-by: Sam Leffler <sleffler@chromium.org>
Change-Id: I4cae36dd2e7389540d337d74745ffbaa0131870f