The workaround enabled by CONFIG_MPIC_BROKEN_REGREAD does not work
on non-broken MPICs. The symptom is no interrupts being received.

The fix is twofold. Firstly the code was broken for multiple isus,
we need to index into the shadow array with the src_no, not the idx.
Secondly, we always do the read, but only use the VECPRI_MASK and
VECPRI_ACTIVITY bits from the hardware, the rest of "val" comes
from the shadow.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This patch fixes various badnesses like this for all interrupt
controllers:

------------[ cut here ]------------
Badness at c04db9dc [verbose debug info unavailable]
NIP: c04db9dc LR: c04db9ac CTR: 00000000
REGS: c053de30 TRAP: 0700   Not tainted  (2.6.31-rc1-00432-ge69b2b5-dirty)
MSR: 00021000 <ME,CE>  CR: 22020084  XER: 00000000
TASK = c0500480[0] 'swapper' THREAD: c053c000
GPR00: 00000001 c053dee0 c0500480 00000000 00000050 00000020 3fffffff 00000000
GPR08: 00000001 c0540000 e0080080 00000000 22000084 64183600 3ff8f800 00000000
GPR16: 841b0240 449a0303 00000000 00000000 00000000 00000000 00000000 c04f5bf4
GPR24: 00000000 00000000 00000000 00000050 00000020 00000000 3fffffff 00000050
NIP [c04db9dc] alloc_arch_preferred_bootmem+0x48/0x74
LR [c04db9ac] alloc_arch_preferred_bootmem+0x18/0x74
Call Trace:
[c053dee0] [c000a5a4] __of_address_to_resource+0x44/0xd0 (unreliable)
[c053def0] [c04dba58] ___alloc_bootmem_nopanic+0x50/0x108
[c053df20] [c04dbb28] ___alloc_bootmem+0x18/0x50
[c053df30] [c04d5de0] qe_ic_init+0x5c/0x1b0
[c053df70] [c04d77b0] mpc85xx_mds_pic_init+0xb8/0x10c
[c053dfb0] [c04cf374] init_IRQ+0x28/0x3c

p.s. commit 85355bb2 ("powerpc: Fix
mpic alloc warning") missed some alloc_bootmem() instances, this is
now fixed.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Since we can use kmalloc earlier we are getting the following since the
mpic_alloc() code calls alloc_bootmem().  Move to using kzalloc() to
remove the warning.

------------[ cut here ]------------
Badness at c0583248 [verbose debug info unavailable]
NIP: c0583248 LR: c0583210 CTR: 00000004
REGS: c0741de0 TRAP: 0700   Not tainted  (2.6.30-06736-g12a31df)
MSR: 00021000 <ME,CE>  CR: 22024024  XER: 00000000
TASK = c070d3b8[0] 'swapper' THREAD: c0740000 CPU: 0
<6>GPR00: 00000001 c0741e90 c070d3b8 00000001 00000210 00000020 3fffffff 00000000
<6>GPR08: 00000000 c0c85700 c04f8c40 0000002d 22044022 1004a388 7ffd9400 00000000
<6>GPR16: 00000000 7ffcd100 7ffcd100 7ffcd100 c04f8c40 00000000 c059f62c c075a0c0
<6>GPR24: c059f648 00000000 0000000f 00000210 00000020 00000000 3fffffff 00000210
NIP [c0583248] alloc_arch_preferred_bootmem+0x50/0x80
LR [c0583210] alloc_arch_preferred_bootmem+0x18/0x80
Call Trace:
[c0741e90] [c07343b0] devtree_lock+0x0/0x24 (unreliable)
[c0741ea0] [c0583b14] ___alloc_bootmem_nopanic+0x54/0x108
[c0741ee0] [c0583e18] ___alloc_bootmem+0x18/0x50
[c0741ef0] [c057b9cc] mpic_alloc+0x48/0x710
[c0741f40] [c057ecf4] mpc85xx_ds_pic_init+0x190/0x1b8
[c0741f90] [c057633c] init_IRQ+0x24/0x34
[c0741fa0] [c05738b8] start_kernel+0x260/0x3dc
[c0741ff0] [c00003c8] skpinv+0x2e0/0x31c
Instruction dump:
409e001c 7c030378 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c0c8
39295700 80090004 7c000034 5400d97e <0f000000> 2f800000 409e001c 38800000

BenH: Changed to use GFP_KERNEL, the allocator will do the right thing
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Commit 31207dab
"Fix incorrect allocation of interrupt rev-map"
introduced a regression crashing on boot on machines using
a "DCR" based MPIC, such as the Cell blades.

The reason is that the irq host data structure is initialized
much later as a result of that patch, causing our calls to
mpic_map() do be done before we have a host setup.

Unfortunately, this breaks _mpic_map_dcr() which uses the
mpic->irqhost to get to the device node.

This fixes it by, instead, passing the device node explicitely
to mpic_map().
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NAkira Tsukamoto <akirat@rd.scei.sony.co.jp>

mpic_find() was overloaded to do two things, finding the mpic instance
for a given interrupt and returning if it's an IPI. Instead we introduce
mpic_is_ipi() and simplify mpic_find() to just return the mpic instance

Also silences the warning:
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_set_priority':
arch/powerpc/sysdev/mpic.c:1382: warning: 'is_ipi' may be used uninitialized in this function
Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
Acked-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Before when we were setting up the irq host map for mpic we passed in
just isu_size for the size of the linear map.  However, for a number of
mpic implementations we have no isu (thus pass in 0) and will end up
with a no linear map (size = 0).  This causes us to always call
irq_find_mapping() from mpic_get_irq().

By moving the allocation of the host map to after we've determined the
number of sources we can actually benefit from having a linear map for
the non-isu users that covers all the interrupt sources.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

according to Ingo, change set_affinity() in irq_chip should return int,
because that way we can handle failure cases in a much cleaner way, in
the genirq layer.

v2: fix two typos

[ Impact: extend API ]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-arch@vger.kernel.org
LKML-Reference: <49F654E9.4070809@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

CoreInt provides a mechansim to deliver the IRQ vector directly
into the core on an interrupt (via the SPR EPR) rather than having
to go IACK on the PIC.  This is suppose to provide an improvment
in interrupt latency by reducing the time to get the IRQ vector.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Convert arch/powerpc/ over to long long based u64:

 -#ifdef __powerpc64__
 -# include <asm-generic/int-l64.h>
 -#else
 -# include <asm-generic/int-ll64.h>
 -#endif
 +#include <asm-generic/int-ll64.h>

This will avoid reoccuring spurious warnings in core kernel code that
comes when people test on their own hardware. (i.e. x86 in ~98% of the
cases) This is what x86 uses and it generally helps keep 64-bit code
32-bit clean too.

[Adjusted to not impact user mode (from paulus) - sfr]
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Impact: cleanup, update to new cpumask API

Irq_desc.affinity and irq_desc.pending_mask are now cpumask_var_t's
so access to them should be using the new cpumask API.
Signed-off-by: NMike Travis <travis@sgi.com>

Impact: change existing irq_chip API

Not much point with gentle transition here: the struct irq_chip's
setaffinity method signature needs to change.

Fortunately, not widely used code, but hits a few architectures.

Note: In irq_select_affinity() I save a temporary in by mangling
irq_desc[irq].affinity directly.  Ingo, does this break anything?

(Folded in fix from KOSAKI Motohiro)
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NMike Travis <travis@sgi.com>
Reviewed-by: NGrant Grundler <grundler@parisc-linux.org>
Acked-by: NIngo Molnar <mingo@redhat.com>
Cc: ralf@linux-mips.org
Cc: grundler@parisc-linux.org
Cc: jeremy@xensource.com
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>

In the CONFIG_SMP case the irq_choose_cpu() code was returning back
a logical cpu id not the physical id.  We were writing that directly
into the HW register.

We need to be calling get_hard_smp_processor_id() so irq_choose_cpu()
always returns a physical cpu id.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Kexec/kdump currently fails on the IBM QS2x blades when the kexec happens
on a CPU other than the initial boot CPU.  It turns out that this is the
result of mpic_init trying to set affinity of each interrupt vector to the
current boot CPU.

As far as I can tell,  the same problem is likely to exist on any
secondary MPIC, because they have to deliver interrupts to the first
output all the time. There are two potential solutions for this: either
not set up affinity at all for secondary MPICs, or assume that a single
CPU output is connected to the upstream interrupt controller and hardcode
affinity to that per architecture.

This patch implements the second approach, defaulting to the first output.
Currently, all known secondary MPICs are routed to their upstream port
using the first destination, so we hardcode that.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

MPIC has 4 ipis, so it can use the new smp_request_message_ipi to
reduce pathlength when receiving an ipi.

This has the side effect of using the common ipi names, and also
continuing to try request the remaining messages when one fails.
Signed-off-by: NMilton Miller <miltonm@bga.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The Freescale implementation of MPIC only allows a single CPU destination
for non-IPI interrupts.  We add a flag to the mpic_init to distinquish
these variants of MPIC.  We pull in the irq_choose_cpu from sparc64 to
select a single CPU as the destination of the interrupt.

This is to deal with the fact that the default smp affinity was
changed by commit 18404756 ("genirq:
Expose default irq affinity mask (take 3)") to be all CPUs.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This converts ppc to use the new helpers for smp_call_function() and
friends, and adds support for smp_call_function_single().

ppc loses the timeout functionality of smp_call_function_mask() with
this change, as the generic code does not provide that.
Acked-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

When I changed irq_alloc_host() to take an of_node
(52964f87: "Add an optional
device_node pointer to the irq_host"), I botched the reference
counting semantics.

Stephen pointed out that it's irq_alloc_host()'s business if
it needs to take an additional reference to the device_node,
the caller shouldn't need to care.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This fixes the following warning, introduced by commit
475ca391 (mpic: Deal with bogus NIRQ
in Feature Reporting Register):

  CC      arch/powerpc/sysdev/mpic.o
arch/powerpc/sysdev/mpic.c: In function 'mpic_alloc':
arch/powerpc/sysdev/mpic.c:1146: warning: suggest explicit braces to avoid ambiguous 'else'
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Compiling ppc64_defconfig with gcc 4.3 gives thes warnings:

arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_get_priority':
arch/powerpc/sysdev/mpic.c:1351: warning: 'is_ipi' may be used uninitialized in this function
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_set_priority':
arch/powerpc/sysdev/mpic.c:1328: warning: 'is_ipi' may be used uninitialized in this function

It turns out that in the cases where is_ipi is uninitialized, another
variable (mpic) will be NULL and it is dereferenced.  Protect against
this by returning if mpic is NULL in mpic_irq_set_priority, and removing
mpic_irq_get_priority completely as it has no in tree callers.

This has the nice side effect of making the warning go away.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Some chips (like the SoCs from Freescale) report the wrong value in NIRQ
and this causes issues if its doesn't match or exceed the value of
irq_count.

Add a flag that board code can set to just use irq_count instead of
FRR[NIRQ].  Eventually we'll add a device tree property with the number
of sources.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

We really need to ack interrupts at mpic_teardown, since
not all platforms reset mpic at kernel start-up. For example,
kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

I was running sparse on something else and noticed sparse warnings
and especially the bogus code that is fixed by the first hunk of
this patch, so I fixed them all while at it.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Milton Miller <miltonm@bga.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

All kobjects require a dynamically allocated name now. We no longer
need to keep track if the name is statically assigned, we can just
unconditionally free() all kobject names on cleanup.
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The mpic_map() and __mpic_map_mmio() need to use phys_addr_t for the
physical address they are passed.
Signed-off-by: NBecky Bruce <becky.bruce@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

By default the OpenPIC on PWRficient will bias to one core (since that
will improve changes of the other core being able to stay idle/powered
down). However, this conflicts with most irq load balancing schemes,
since setting an interrupt to be delivered to either core doesn't really
result in the load being shared. It also doesn't work well with the
soft irq disable feature of PPC, since EE will stay on until the first
interrupt is taken while soft disabled.

Set the gconf0 config bit that enables even distribution of interrupts
among the two cores.
Signed-off-by: NOlof Johansson <olof@lixom.net>

Some PWRficient-based boards have a NMI button that's wired up to a GPIO
as interrupt source. By configuring the openpic accordingly, these get
delivered as a machine check with high priority, instead of as an external
interrupt.

The device tree contains a property "nmi-source" in the openpic node
for these systems, and it's the (hwirq) source for the input.

Also, for these interrupts, the IACK is read from another register than
the regular (MCACK instead), but they are EOI'd as usual. So implement
said function for the mpic driver.

Finally, move a couple of external function defines to include/ instead
of local under sysdev. Being able to mask/unmask and eoi directly saves
us from setting up a dummy irq handler that will never be called.
Signed-off-by: NOlof Johansson <olof@lixom.net>

Implement MSI support for PA Semi PWRficient platforms. MSI is done
through a special range of sources on the openpic controller, and they're
unfortunately breaking the usual concepts of how sources are programmed:

* The source is calculated as 512 + the value written into the MSI
  register
* The vector for this source is added to the source and reported
  through IACK

This means that for simplicity, it makes much more sense to just set the
vector to 0 for the source, since that's really the vector we expect to
see from IACK.

Also, the affinity/priority registers will affect 16 sources at a
time. To avoid most (simple) users from being limited by this, allocate
16 sources per device but use only one. This means that there's a total
of 32 sources.

If we get usage scenarions that need more sources, the allocator should
probably be revised to take an alignment argument and size, not just do
natural alignment.

Finally, since I'm already touching the MPIC names on pasemi, rename
the base one from the somewhat odd " PAS-OPIC  " to "PASEMI-OPIC".
Signed-off-by: NOlof Johansson <olof@lixom.net>
Acked-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Optimize MPIC IPIs, by passing in the IPI number as the argument to the
handler, since all we did was translate it back based on which mpic
the interrupt came though on (and that was always the primary mpic).
Signed-off-by: NOlof Johansson <olof@lixom.net>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we
can save them the trouble and do it in dcr_read()/dcr_write().

As some background to why we just went through all this jiggery-pokery,
benh sayeth:

 Initially the goal of the dcr_read/dcr_write routines was to operate like
 mfdcr/mtdcr which take absolute DCR numbers. The reason is that on 4xx
 hardware, indirect DCR access is a pain (goes through a table of
 instructions) and it's useful to have the compiler resolve an absolute DCR
 inline.

 We decided that wasn't worth the API bastardisation since most places
 where absolute DCR values are used are low level 4xx-only code which may
 as well continue using mfdcr/mtdcr, while the new API is designed for
 device "instances" that can exist on 4xx and Axon type platforms and may
 be located at variable DCR offsets.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Now that dcr_host_t contains the base address, we can use that in the mpic
code, rather than storing it separately.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Hook up affinity-setting for U3/U4 MSI interrupt sources.

Tested on Quad G5 with myri10ge.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Some versions of PWRficient 1682M have an interrupt controller in which
the first register in each pair for interrupt sources doesn't always
read with the right polarity/sense values.

To work around this, keep a software copy of the register instead.  Since
it's not modified from the mpic itself, it's a feasible solution.  Still,
keep it under a config option to avoid wasting memory on other platforms.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The majority of irq_host implementations (3 out of 4) are associated
with a device_node, and need to stash it somewhere. Rather than having
it somewhere different for each host, add an optional device_node pointer
to the irq_host structure.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Some HW platforms, such as the new cell blades, requires some MPIC sources
to be left alone by the operating system. This implements support for
a "protected-sources" property in the mpic controller node containing a list
of source numbers to be protected against operating system interference.

For those interested in the gory details, the MPIC on the southbridge of
those blades has some of the processor outputs routed to the cell, and
at least one routed as a GPIO to the service processor. It will be used
in the GA product for routing some of the southbridge error interrupts
to the service processor which implements some of the RAS stuff, such
as checkstopping when fatal errors occurs before they can propagate.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NArnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

arch/powerpc/sysdev/mpic.c: In function 'mpic_request_ipis':
arch/powerpc/sysdev/mpic.c:1445: warning: ignoring return value of 'request_irq', declared with attribute warn_unused_result
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

MPIC U3/U4 MSI backend. Based on code from Segher, heavily hacked by me.
This only deals with MSI on U3/U4 MPICs, aka. CPC 9x5.

If we find a U3/U4 then we enable this backend, ie. take over the ppc_md
MSI hooks. We might need more elaborate logic in future to decide which
backend is enabled.

We need our own irq_chip so that we can do MSI masking/unmasking on
the device itself. We also need to mask explicitly on shutdown to make
sure we don't get bitten by lazy-disable semantics.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

To support MSI on MPIC we need a way to reserve and allocate hardware irq
numbers, this patch implements an allocator for that purpose.

New firmware platforms must define a "msi-available-ranges" property on their
MPIC node for MSI to work. For U3/U4 we do a best-guess setup.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

On some Apple machines the HT MSI mappings are not enabled by firmware, so
we need to do it by hand.

We can't use the pci routines as this code runs too early.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This adds mpic to the system devices and implements suspend
and resume for them.  This is necessary to get interrupts for
modules back to where they were before a suspend to disk.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The weird TSI 10x MPIC needs an EOI after getting a spurious vector.  This
patch uses the existing MPIC_SPV_EOI flag to fix this issue.
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>