Signed-off-by: NHarninder Rai <harninder.rai@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

BSC9131RDB doesn't have SDHC enabled. As a result of this typo,
the node was not getting disabled from the device tree which was
leading to linux hang during bootup
Signed-off-by: NHarninder Rai <harninder.rai@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The MPIC code will disable coreint if it detects an insufficient
MPIC version.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This will be used by the qemu-e500 platform, as the MPIC version (and
thus whether we have coreint) depends on how QEMU is configured.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The pci controller structure has a provision to store the device structure
pointer of the corresponding platform device. Currently this information is
not stored during fsl pci controller initialization. This information is
required while dealing with iommu groups for pci devices connected to the
fsl pci controller. For the case where the pci devices can't be paritioned,
they would fall under the same device group as the pci controller.

This patch stores the platform device information in the pci controller
structure during initialization.
Signed-off-by: NVarun Sethi <Varun.Sethi@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Initial board support for the Prodrive PPA8548 AMC module. Board
is an MPC8548 AMC platform used in RapidIO systems. This module is
also used to test/work on mainline linux RapidIO software.

PPA8548 overview:
- 1.3 GHz Freescale PowerQUICC III MPC8548 processor
- 1 GB DDR2 @ 266 MHz
- 8 MB NOR flash
- Serial RapidIO 1.2
- 1 x 10/100/1000 BASE-T front ethernet
- 1 x 1000 BASE-BX ethernet on AMC connector
Signed-off-by: NStef van Os <stef.van.os@prodrive.nl>
Acked-by: NTimur Tabi <timur@tabi.org>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The Freescale DIU driver was recently updated to not require every DIU
platform function, so now we can remove the unneeded functions from
some boards.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Delete successive tests to the same location.  The code tested the result
of a previous call, that itself was already tested.  It is changed to test
the result of the most recent call.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@s exists@
local idexpression y;
expression x,e;
@@

*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
 { ... when forall
   return ...; }
... when != \(y = e\|y += e\|y -= e\|y |= e\|y &= e\|y++\|y--\|&y\)
    when != \(XT_GETPAGE(...,y)\|WMI_CMD_BUF(...)\)
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
 { ... when forall
   return ...; }
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This facilitates getting the physical address of the SEC node.
Signed-off-by: NLiu po <po.liu@freescale.com>
Reviewed-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Synchronize this defconfig with latest kernel version.
Signed-off-by: NHolger Brunck <holger.brunck@keymile.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

There is no point in applying this quirk when par_io is not present.
Signed-off-by: NGerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: NHolger Brunck <holger.brunck@keymile.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Move the code for this quirk to a dedicated function.
Signed-off-by: NGerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: NHolger Brunck <holger.brunck@keymile.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Signed-off-by: NHolger Brunck <holger.brunck@keymile.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Signed-off-by: NHolger Brunck <holger.brunck@keymile.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Fix and/or improve the compatible strings of the PCI device tree nodes for
some Freescale SOCs.  This fixes some issues and improves consistency among
the SOCs.

Specifically:

1) The P1022 has a v1 PCIe controller, so the compatible property should just
say "fsl,mpc8548-pcie".  U-Boot does not look for "fsl,p1022-pcie", so it
wasn't fixing up the node.

2) The P4080 has a v2.1 PCIe controller, so add that version-specific string
to the device tree.  Update the kernel to also look for that string.
Currently, the kernel looks for "fsl,p4080-pcie" specifically, but
eventually that check should be deleted.

3) The P1010 device tree claims compatibility with v2.2 and v2.3, but that's
redundant.  No other device tree does this.  Remove the v2.2 string.

4) The kernel looks for both "fsl,p1023-pcie" and "fsl,qoriq-pcie-v2.2",
even though the P1023 device trees has always included both strings.  Remove
the search for "fsl,p1023-pcie".
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The PAMU caches use the LIODNs to determine which cache lines hold the
entries for the corresponding LIODs.  The LIODNs must therefore be
carefully assigned to avoid cache thrashing -- two active LIODs with
LIODNs that put them in the same cache line.

Currently, LIODNs are statically assigned by U-Boot, but this has
limitations.  LIODNs are assigned even for devices that may be disabled
or unused by the kernel.  Static assignments also do not allow for device
drivers which may know which LIODs can be used simultaneously.  In
other words, we really should assign LIODNs dynamically in Linux.

To do that, we need to describe the PAMU device and cache topologies in
the device trees.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Acked-by: NStuart Yoder <stuart.yoder@freescale.com>
Acked-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This new property defines the era of the particular SEC version.
The compatible property in device tree "crypto" node has been updated
not to contain SEC era numbers.
Signed-off-by: NVakul Garg <vakul@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This board has soldered on flash, and a SODIMM flash module.
Both can be used for booting, via switching JP12 and SW2.8
and using the sbc8548-altflash.dts when booting from SODIMM.

Here we enable MTD in kernel so that we can see the bootloader
(and other flash sectors) from linux.

Normal configuration:

 root@sbc8548:~# cat /proc/mtd
 dev:    size   erasesize  name
 mtd0: 007a0000 00020000 "space"
 mtd1: 00060000 00020000 "bootloader"
 mtd2: 03f00000 00080000 "space"
 mtd3: 00100000 00080000 "bootloader"
 root@sbc8548:~# dd if=/dev/mtd1 count=1 bs=48|hexdump -C
 1+0 records in
 1+0 records out
 00000000  27 05 19 56 55 2d 42 6f  6f 74 20 32 30 31 32 2e  |'..VU-Boot 2012.|
 00000010  31 30 2d 64 69 72 74 79  20 28 4a 61 6e 20 31 39  |10-dirty (Jan 19|
 00000020  20 32 30 31 33 20 2d 20  31 39 3a 34 30 3a 31 31  | 2013 - 19:40:11|
 00000030
 root@sbc8548:~# dd if=/dev/mtd3 count=1 bs=48|hexdump -C
 1+0 records in
 1+0 records out
 00000000  27 05 19 56 55 2d 42 6f  6f 74 20 32 30 31 32 2e  |'..VU-Boot 2012.|
 00000010  31 30 2d 64 69 72 74 79  20 28 44 65 63 20 31 33  |10-dirty (Dec 13|
 00000020  20 32 30 31 32 20 2d 20  31 35 3a 30 30 3a 30 37  | 2012 - 15:00:07|
 00000030
 root@sbc8548:~#

Alternate configuration, with sbc8548-altflash.dts:

 root@sbc8548:~# cat /proc/mtd
 dev:    size   erasesize  name
 mtd0: 03f00000 00080000 "space"
 mtd1: 00100000 00080000 "bootloader"
 mtd2: 007a0000 00020000 "space"
 mtd3: 00060000 00020000 "bootloader"
 root@sbc8548:~# dd if=/dev/mtd1 count=1 bs=48|hexdump -C
 1+0 records in
 1+0 records out
 00000000  27 05 19 56 55 2d 42 6f  6f 74 20 32 30 31 32 2e  |'..VU-Boot 2012.|
 00000010  31 30 2d 64 69 72 74 79  20 28 44 65 63 20 31 33  |10-dirty (Dec 13|
 00000020  20 32 30 31 32 20 2d 20  31 35 3a 30 30 3a 30 37  | 2012 - 15:00:07|
 00000030
 root@sbc8548:~# dd if=/dev/mtd3 count=1 bs=48|hexdump -C
 1+0 records in
 1+0 records out
 00000000  27 05 19 56 55 2d 42 6f  6f 74 20 32 30 31 32 2e  |'..VU-Boot 2012.|
 00000010  31 30 2d 64 69 72 74 79  20 28 4a 61 6e 20 31 39  |10-dirty (Jan 19|
 00000020  20 32 30 31 33 20 2d 20  31 39 3a 34 30 3a 31 31  | 2013 - 19:40:11|
 00000030
 root@sbc8548:~#

Note that in the latter, the larger SODIMM device appears 1st,
as mtd0 and mtd1, as indicated in the sizes, and in the date
of the u-boot image.

The kernel configuration is the same in both cases; only the dtb
needs to be changed in accordance with the JP12/SW2.8 settings.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

By moving the two JP12 jumpers 90 degrees, and switching the
setting of SW2.8, the sbc8548 can be configured to boot off
the alternate 64MB SODIMM, which when populated with u-boot
can be a handy recovery option, in case the u-boot in the
8MB soldered on flash gets corrupted.  Here we add an alternate
dts file to match that configuration.

To better highlight the differences, the output from the u-boot
"fli" command is shown for the normal configuration and then
the alternate configuration.

Normal:
 -----------------------
Bank # 1: CFI conformant flash (8 x 8)  Size: 8 MB in 64 Sectors
  Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x17
  Erase timeout: 4096 ms, write timeout: 1 ms
  Buffer write timeout: 2 ms, buffer size: 32 bytes

  Sector Start Addresses:
  FF800000 E      FF820000 E      FF840000 E      FF860000 E      FF880000 E
 [...]
  FFEE0000 E      FFF00000 E      FFF20000 E      FFF40000 E      FFF60000 E
  FFF80000        FFFA0000   RO   FFFC0000   RO   FFFE0000   RO

Bank # 2: CFI conformant flash (32 x 8)  Size: 64 MB in 128 Sectors
  Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
  Erase timeout: 4096 ms, write timeout: 1 ms
  Buffer write timeout: 2 ms, buffer size: 32 bytes

  Sector Start Addresses:
  EC000000 E      EC080000 E      EC100000 E      EC180000 E      EC200000 E
 [...]
  EFC00000 E      EFC80000 E      EFD00000 E      EFD80000 E      EFE00000 E
  EFE80000 E      EFF00000        EFF80000
 -----------------------

Alternate:
 -----------------------
Bank # 1: CFI conformant flash (32 x 8)  Size: 64 MB in 128 Sectors
  Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
  Erase timeout: 4096 ms, write timeout: 1 ms
  Buffer write timeout: 2 ms, buffer size: 32 bytes

  Sector Start Addresses:
  FC000000 E      FC080000 E      FC100000 E      FC180000 E      FC200000 E
 [...]
  FFC00000 E      FFC80000 E      FFD00000 E      FFD80000 E      FFE00000 E
  FFE80000 E      FFF00000   RO   FFF80000   RO

Bank # 2: CFI conformant flash (8 x 8)  Size: 8 MB in 64 Sectors
  Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x17
  Erase timeout: 4096 ms, write timeout: 1 ms
  Buffer write timeout: 2 ms, buffer size: 32 bytes

  Sector Start Addresses:
  EF800000 E      EF820000 E      EF840000 E      EF860000 E      EF880000 E
 [...]
  EFEE0000 E      EFF00000 E      EFF20000 E      EFF40000 E      EFF60000 E
  EFF80000 E      EFFA0000        EFFC0000        EFFE0000
 -----------------------
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The original memory map for the sbc8548 had the 64MB SODIMM flash
device misaligned by 8MB to allow a window of address space for
the soldered on 8MB device -- i.e.

 start           end             CS<n>   width   Desc.
 ----------------------------------------------------------
 fb80_0000       ff7f_ffff       CS6     32      SODIMM flash (64MB)
 ff80_0000       ffff_ffff       CS0     8       Boot flash (8MB)

However, if we want to change the configuration so that it boots
off the 64MB flash, it is in turn then aligned with a 64MB boundary,
starting at fc00_0000 (and the 8MB @ fb80_0000 -> fbff_ffff).

This makes for complicated updates, since what is the beginning
of the physical device is 8MB into its address space in the default
configuration shown above.

This issue was fixed as of u-boot commit 3fd673cf363bc86ed42eff713d4
("sbc8548: relocate 64MB user flash to sane boundary") -- in which
the SODIMM was mapped to ec00_0000 (natively aligned under efff_ffff)
and so when JP12/SW2.8 are switched, it will be a a simple 0xec --> 0xfc
mapping between the two instances.

Here we make the associated changes in the localbus flash memory
map in the dts file:  indicating the 64MB device starts at ec00_0000
and that the tail end of the 64MB device (last 2 sectors) can contain
a bootloader image.

The partitions for both flash devices get a clean-up; there were
non-meaningful assignments in there that probably originated from
the MPC8548CDS on which the file was based on.  Now there is just
the categorization of free space and bootloader images.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Updates to u-boot allow this board to boot off of either
the 8MB soldered on flash, or the 64MB SODIMM flash.

This is achieved by changing JP12 and SW2.8 which in turn
swaps which flash device appears on /CS0 and /CS6 respectively.

Since the flash devices are not the same size, this also
changes the MTD memory map layout on the local bus.

Here we split the common chunks out into a pre and post
include, so they can be reused by an upcoming "alternative
boot" dts file; leaving only the local bus chunk behind.

No content changes are made at this point - it is just purely
the move to using include files.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Use for_each_compatible_node() macro instead of open coding it.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

arch/powerpc/sysdev/fsl_msi.c:31:1: warning: symbol 'msi_head' was not declared. Should it be static?
arch/powerpc/sysdev/fsl_msi.c:138:40: warning: incorrect type in argument 1 (different base types)
arch/powerpc/sysdev/fsl_msi.c:138:40:    expected restricted __be64 const [usertype] *p
arch/powerpc/sysdev/fsl_msi.c:138:40:    got unsigned long long const [usertype] *[assigned] reg
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

arch/powerpc/sysdev/fsl_ifc.c:66:38: warning: incorrect type in initializer (different base types)
arch/powerpc/sysdev/fsl_ifc.c:66:38:    expected restricted __be32 [usertype] cspr
arch/powerpc/sysdev/fsl_ifc.c:66:38:    got unsigned int
arch/powerpc/sysdev/fsl_ifc.c:67:21: warning: restricted __be32 degrades to integer
arch/powerpc/sysdev/fsl_ifc.c:67:39: warning: restricted __be32 degrades to integer
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

arch/powerpc/sysdev/fsl_soc.c:70:67: warning: incorrect type in argument 2 (different base types)
arch/powerpc/sysdev/fsl_soc.c:70:67:    expected restricted __be32 const [usertype] *addr
arch/powerpc/sysdev/fsl_soc.c:70:67:    got unsigned int const [usertype] *
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

arch/powerpc/sysdev/fsl_lbc.c:77:36: warning: incorrect type in initializer (different base types)
arch/powerpc/sysdev/fsl_lbc.c:77:36:    expected restricted __be32 [usertype] br
arch/powerpc/sysdev/fsl_lbc.c:77:36:    got unsigned int
arch/powerpc/sysdev/fsl_lbc.c:78:36: warning: incorrect type in initializer (different base types)
arch/powerpc/sysdev/fsl_lbc.c:78:36:    expected restricted __be32 [usertype] or
arch/powerpc/sysdev/fsl_lbc.c:78:36:    got unsigned int
arch/powerpc/sysdev/fsl_lbc.c:80:21: warning: restricted __be32 degrades to integer
arch/powerpc/sysdev/fsl_lbc.c:80:38: warning: restricted __be32 degrades to integer
arch/powerpc/sysdev/fsl_lbc.c:111:12: warning: incorrect type in assignment (different base types)
arch/powerpc/sysdev/fsl_lbc.c:111:12:    expected restricted __be32 [usertype] br
arch/powerpc/sysdev/fsl_lbc.c:111:12:    got unsigned int
arch/powerpc/sysdev/fsl_lbc.c:113:17: warning: restricted __be32 degrades to integer
arch/powerpc/sysdev/fsl_lbc.c:127:17: warning: restricted __be32 degrades to integer
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This patch adds support for enabling and context switching the Target
Address Register in Power8. The TAR is a new special purpose register
that can be used for computed branches with the bctar[l] (branch
conditional to TAR) instruction in the same manner as the count and link
registers.
Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
Signed-off-by: NMatt Evans <matt@ozlabs.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

pseries/iommu: remove DDW on kexec

We currently insert a property in the device-tree when we successfully
configure DDW for a given slot. This was meant to be an optimization to
speed up kexec/kdump, so that we don't need to make the RTAS calls again
to re-configured DDW in the new kernel.

However, we end up tripping a plpar_tce_stuff failure on kexec/kdump
because we unconditionally parse the ibm,dma-window property for the
node at bus/dev setup time. This property contains the 32-bit DMA window
LIOBN, which is distinct from the DDW window's. We pass that LIOBN (via
iommu_table_init -> iommu_table_clear -> tce_free ->
tce_freemulti_pSeriesLP) to plpar_tce_stuff, which fails because that
32-bit window is no longer present after
25ebc45b ("powerpc/pseries/iommu: remove
default window before attempting DDW manipulation").

I believe the simplest, easiest-to-maintain fix is to just change our
initcall to, rather than detecting and updating the new kernel's DDW
knowledge, just remove all DDW configurations. When the drivers
re-initialize, we will set everything back up as it was before.
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The parameter is unused, and complicates a following fix. Just remove
it.
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

It seems, we're fine with just annotating the two functions.
Thus, this fixes the following build warnings on ppc64:

WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1664):
The function .ics_rtas_init() references
the function __init .xics_register_ics().
This is often because .ics_rtas_init lacks a __init
annotation or the annotation of .xics_register_ics is wrong.

WARNING: arch/powerpc/sysdev/built-in.o(.text+0x6044):
The function .ics_rtas_init() references
the function __init .xics_register_ics().
This is often because .ics_rtas_init lacks a __init
annotation or the annotation of .xics_register_ics is wrong.

WARNING: arch/powerpc/kernel/built-in.o(.text+0x2db30):
The function .start_secondary() references
the function __cpuinit .vdso_getcpu_init().
This is often because .start_secondary lacks a __cpuinit
annotation or the annotation of .vdso_getcpu_init is wrong.

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

There are now two kinds of DMA windows that might be presented by
PowerVM DDW support -- huge windows (that can map all of system memory
regardless of the LPAR configuration) and non-huge windows (which
can't). They are implemented slightly differently in PowerVM, and thus
have different characteristics. The most obvious is that slot isolate
doesn't clear the TCEs/window for us with non-huge windows. Thus, when a
DLPAR operation occurs on a slot using a non-huge window, TCEs are still
present (the notifier chain doesn't currently remove them explicitly)
and the DLPAR fails. Fix this by calling remove_ddw() first, which will
unmap the DDW TCEs.

Note: a corresponding change to drmgr is needed to actually successfully
DLPAR, such that the device-tree update (which causes the notifier chain
to fire) occurs before slot isolate.
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

tce_clearrange_multi_pSeriesLP is attempting to iterate over all TCEs in
a given range. However, is it not advancing the dma_offset value passed
to plpar_tce_stuff via the next value. This prevents DLPAR from
completing, because TCEs are still present at slot isolation time.
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Change the hardware breakpoint code so that we can support wider ranged
breakpoints.

This means both ptrace and perf hardware breakpoints can use upto 512 byte long
breakpoints when using the DAWR and only 8 byte when using the DABR.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Currently we set the length field in the DAWR to 0 which defaults it to one
double word (64bits) which is the same as the DABR.

Change this so that we can set it to longer values as supported by the DAWR.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

perf/Power: PERF_EVENT_IOC_ENABLE does not reenable event

If we disable a perf event because we exceeded the specified ->event_limit,
power_pmu_stop() sets the PERF_HES_STOPPED flag on the event.

If the application then re-enables the event using PERF_EVENT_IOC_ENABLE
ioctl, we don't ever clear this STOPPED flag. Consequently, the user space
is never notified of the event.

Following message has more background and test case.

    http://lists.eecs.utk.edu/pipermail/ptools-perfapi/2012-October/002528.html

Used the following test cases to verify that this patch works on latest PAPI.

	$ papi.git/src/ctests/nonthread PAPI_TOT_CYC@5000000

	$ papi.git/src/ctests/overflow_single_event

Changelog[v2]:
	- [Paul Mackerras] Also clear PERF_HES_UPTODATE flag since we are
	  restarting the event; cleanup comments and patch description.
Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Use local_paca directly in macro SHARED_PROCESSOR, as all processors
have the same value for the field shared_proc, so we don't need care
racy here.
Reported-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Uprobes uses emulate_step in sstep.c, but we haven't explicitly specified
the dependency. On pseries HAVE_HW_BREAKPOINT protects us, but 44x has no
such luxury.

Consolidate other users that depend on sstep and create a new config option.
Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: NSuzuki K. Poulose <suzuki@in.ibm.com>
Cc: linuxppc-dev@ozlabs.org
Cc: stable@vger.kernel.org
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

CTS-1000 is based on P4080. GPIO 27 is used to signal the FPGA to
switch off power, and also associates IRQ 8 with front-panel button
press (which we use to call orderly_poweroff()).

The relevant device-tree looks like this:

	gpio0: gpio@130000 {
		compatible = "fsl,qoriq-gpio";
		reg = <0x130000 0x1000>;
		interrupts = <55 2 0 0>;
		#gpio-cells = <2>;
		gpio-controller;

		/* Allows powering off the system via GPIO signal. */
		gpio-halt@27 {
			compatible = "sgy,gpio-halt";
			gpios = <&gpio0 27 0>;
			interrupts = <8 1 0 0>;
		};
	};

Because the driver cannot match on sgy,gpio-halt (because the node is never
processed through of_platform), it matches on fsl,qoriq-gpio and then
checks child nodes for the matching sgy,gpio-halt. This also ensures that
the GPIO controller is detected prior to sgy_cts1000's probe callback,
since that node wont match via of_platform until the controller is
registered.

Also, because the GPIO handler for triggering system poweroff might sleep,
the IRQ uses a workqueue to call orderly_poweroff().

As a final note, this driver may be expanded for other features specific to
the CTS-1000.
Signed-off-by: NBen Collins <ben.c@servergy.com>
Cc: Jack Smith <jack.s@servergy.com>
Cc: Vihar Rai <vihar.r@servergy.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

While this should be harmless now that distribute_irqs
obeys MPIC_SINGLE_DEST_CPU, there's no reason to enable this
on mpc85xx/mpc86xx since MPIC_SINGLE_DEST_CPU will always be set.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Previously we were setting an illegal configuration on mpc85xx
MPICs if CONFIG_IRQ_ALL_CPUS is enabled (which for some reason it is
in mpc85xx_smp_defconfig).
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>