msm: pm: clean msm_pm_pc_pgd in the cache after writing

Since a CPU will read the msm_pm_pc_pgd value as it comes
up from power collapse when caches are disabled, it needs
to be guaranteed that the value has been written to memory
before any CPU power collapses.

Change-Id: I7f6358a001255f9bac99a6378532c96fd460f82b
Signed-off-by: Steve Muckle <smuckle@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
Change-Id: Id8353286181fe38a419bd7421518b33f2f8b26aa
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Taniya Das <tdas@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: clock-8960/8660: Support 32/64MHz prng clock frequency plan

Add support for both the 32MHz and the 64MHz prng frequencies.
Some bootloaders configure the PRNG to 32MHz and others choose
64MHz. Support both so that we always vote for the correct
voltage

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
(cherry picked from commit 842a1f6b0eb8ecf40f97fa020fa004745ba1ab48)

Conflicts:

	arch/arm/mach-msm/clock-8960.c
	arch/arm/mach-msm/clock-8x60.c

Change-Id: I732aaa78d2019d6fefd90456f67ca27db1be9874
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
msm: gic: Remove manual GIC programming for PPI trigger type

There is no need to manually program GIC for edge trigger PPIs
through board or device file hooks after the introduction of
enable_percpu_irq(.., type) interface. 2nd parameter of this
API needs to be used for programming the right trigger
type for the PPI.

Change-Id: Ie200928eb70fcbab6646ddd63acfd89a1a87f5fe
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Perf: Dont reset PMU's if perf is not active

Perf would save and restore counters after resetting the PMU when
the CPU's came out of power collapse even if a perf session wasn't
active. Check if perf was running before going into power collapse
and only then reset PMU's while coming out.

This way PMU's can be accessed externally via the RPM or T32 without
perf intruding in counter output.

Change-Id: I33ac11b2a5cae21456341fde015aabe5b4bb8f52
Signed-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>
arm: gic: Register irqdomain after adding it

Recently a change was added to break apart irq_domain_add() into
two functions. The first creates the domain, and the second
registers it.

This change abides to this new interface and registers the
GIC irq_domain after creating it.

Change-Id: I34c6a1f56dc27113a9b72f0fefa577276f91bbc8
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
arm: gic: Check for error code on irq_domain_add

This API now returns an error. Since gic_init_bases() is called
early on, there's probably not a whole lot we can do here except
send a warning.

Change-Id: I2835dacfa191db0ce70434de23e6ee540fe33b57
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
arm: gic: Configure the GIC to run in secure mode

Configure the GIC to run in secure mode and handle
secure as well as non-secure interrupts. This patch
adds an API to configure an IRQ as a secure IRQ so that
it can be treated as an FIQ in the secure mode.

Change-Id: Ic3321e76c95a4c10d6287ba418e84623e7004cb1
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Sathish Ambley <sambley@codeaurora.org>
ARM: gic: Add support to access GIC in secure mode

Currently gic secure mode is enabled for all the v7 cpus.
For 8x25 we do not want to access GIC in secure mode as
we are observe issues of not able to clear the pending clear
registers when we come out of power collapse.

The Kconfig should make it flexible for targets who want to
support GIC in secure/non-secure modes.

Change-Id: Id7c85f5b741346233993966752607e5c4fb23e74
Signed-off-by: Taniya Das <tdas@codeaurora.org>
ARM: gic: Add spinlocks for SGIR/AIR/EOI for 8625

On 8625 due to bug in AHB MUX on hready, back to back write followed
by read (from any CPU) on QGIC2 registers (SGIR(WO) ,IAR(RO) and
write on EOI(WO)) cause the read data to get corrupted on AHB bus.

Due to this whenever a valid irq has occurs, and dispatched to the cpu
interface but still cpu reads the IAR as 0x0 and that particular IRQ
becomes active.
But due to incorrect irq id (read as 0x0), IRQ handler will not do
proper EOI for that particular interrupt and thus it gets trapped
in the active state.

Below is the qgic register dump from CPU-1, in this particular case
we see that SGI-3 is not getting clear as cpu reads this as 0x0.

AZSD:C0000200| 00240008 00000000 00008000 00000000 00000000 00000000
00000000 00000000 ..$.............................
AZSD:C0000280| 00240008 00000000 00008000 00000000 00000000 00000000
00000000 00000000 ..$.............................
AZSD:C0000300| 00040008 00000000 00000000 00000000 00000000 00000000
00000000 00000000 ................................
AZSD:C0000380| 00040008 00000000 00000000 00000000 00000000 00000000
00000000 00000000 ................................

As the interrupt gets trapped, no other interrupt received on the core is
services any more causing the system hang.

CRs-Fixed: 349219
Change-Id: Icad2c65114377a08984b1032566cfba811bb4ca8
Signed-off-by: Taniya Das <tdas@codeaurora.org>
ARM: gic: Move GIC based code out from mpm-8625

Moving code which modifies the GIC registers. As there is no global
lock in gic code, moving the code out.

Change-Id: I85a2bd580dbeefc942a3307f3c0cad8b1da509b7
Signed-off-by: Taniya Das <tdas@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/mpm-8625.c
	arch/arm/mach-msm/platsmp-8625.c
ARM: gic: protect some of 8625 GIC functionality with irq spinlocks

msm_gic_spi_ppi_pending, msm_gic_save and core1_gic_configure_and_raise
gets called with interrupt enabled on the core0, so it is possible
that we get into the spinlock deadlock since interrupt like timer PPI
could get fired on core0 and get locked in gic_handle_irq() routine
itself, so move these spinlocks to irqsave variants to avoid this
scenario.

CRs-Fixed: 363249
Change-Id: I2d40d6e26f5d9dba4ee6b9d4602cd0e685226693
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
ARM: gic: Disable all interrupts before Power collapse

We may enter PC from either suspend or idle path. So even
if we enter from suspend path we should disable all interrupts
before we go to Power collapse, so as to make sure, there
are no pending interrupts(not even the wakeup capable) which
could result in WFI failure.

CRs-Fixed: 363293
Change-Id: Ied25b21f59a9fa0a891a27a2e806876cc337a759
Signed-off-by: Taniya Das <tdas@codeaurora.org>
ARM: gic: Remove unnecessary irq spinlocks from gic_resume path

Remove the unnecessary irq spinlocks from gic resume path since it
always gets called with interrupt disabled. It also fixes the bug
introduced by commit 6278db09f where it called spin_lock again on the same
lock.

CRs-Fixed: 370894
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
(cherry picked from commit 1bf3f2d4cf3595c4cd5aa4fa2f070cf6cf841bf7)

Change-Id: I04a68c3799a08009b90feabd142d0f58f375811f
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
irq: irqdomain: Add support for dynamic irq_desc allocations

The current irq_domain_add() design assumes the underlying
irq_descs are valid when irq_domain_add() is called. It also
assumes that every hwirq enlisted in the irq_domain is valid.
Often, these assumptions are not correct.

Typically, irq_domain_add() is called at board_init time, but
sometimes interrupt chip drivers are not initialized until an
underlying bus is probed. When using SPARSE_IRQ, it's quite
natural to hold off allocating irq_descs until the board
topology specifies them as included.

And in such device topologies, there's no guarantee that chip
interrupt numbers will be contiguous. For example, each hwirq may
map to a particular device, but that device may or may not be
present in the actual hardware configuration. In order to support
this, we need the concept of an irq_domain that supports holes
in it.

In order to solve these problems, let's break the irq_domain
creation from the irq registration process. The irq_domain
creation can occur at init time and then have no dependencies. An
interrupt is not 'registered' with the domain until its resources
have already been allocated by the chip driver. For simple cases,
an additional API is provided to register the entire
logical irq_domain range to provide feature parity with what
already exists.

Change-Id: Ie3340d07ba8663196dc87d1185e3bb7fbed4be4d
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
irq: irqdomain: Change irq_domain_add to detect errors

It should not be valid to add an irq_domain with a logical irq
range that overlaps with another already registered to the
system. Return an error on such an occurrence.

This change also inherently sorts the irq_domains by logical
irq_base as they are added.

Change-Id: Idef697dbe4584d783703d053fbf09f1b17e62ab0
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
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>