For Freescale powerpc platform, the PCI-e bus number uses the reassign mode
by default. It means the second PCI-e controller's hose->first_busno is the
first controller's last bus number adding 1. For some hotpluged device(or
controlled by FPGA), the device is linked to PCI-e slot at linux runtime.
It needs rescan for the system to add it and driver it to work. It successes
to rescan the device linked to the first PCI-e controller's slot, but fails to
rescan the device linked to the second PCI-e controller's slot. The cause is
that the bus->number is reset to 0, which isn't equal to the hose->first_busno
for the second controller checking PCI-e link. So it doesn't really check the
PCI-e link status, the link status is always no_link. The device won't be
really rescaned. Reset the bus->number to hose->first_busno in the function
fsl_pcie_check_link(), it will do the real checking PCI-e link status for the
second controller, the device will be rescaned.
Signed-off-by: NYuanquan Chen <Yuanquan.Chen@freescale.com>
Tested-by: NRojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: NScott Wood <scottwood@freescale.com>

This function contains all the stuff we need to check if SWIOTLB
should be enabled or not. So it is more convenient to enable
the SWIOTLB here than later.
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Signed-off-by: NScott Wood <scottwood@freescale.com>

The (1ull << mem_log) is never greater than mem unless mem_log++;
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Signed-off-by: NScott Wood <scottwood@freescale.com>

A PCIe erratum of mpc85xx may causes a core hang when a link of PCIe
goes down. when the link goes down, Non-posted transactions issued
via the ATMU requiring completion result in an instruction stall.
At the same time a machine-check exception is generated to the core
to allow further processing by the handler. We implements the handler
which skips the instruction caused the stall.

This patch depends on patch:
powerpc/85xx: Add platform_device declaration to fsl_pci.h
Signed-off-by: NZhao Chenhui <b35336@freescale.com>
Signed-off-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NLiu Shuo <soniccat.liu@gmail.com>
Signed-off-by: NJia Hongtao <hongtao.jia@freescale.com>
Signed-off-by: NScott Wood <scottwood@freescale.com>

The following commit caused a fatal oops when booting on mpc83xx with
a non-express PCI bus (regardless of whether a PCI device is present):

commit 50d8f87d
Author: Rojhalat Ibrahim <imr@rtschenk.de>
Date:   Mon Apr 8 10:15:28 2013 +0200

    powerpc/fsl-pci Make PCIe hotplug work with Freescale PCIe controllers

    Up to now the PCIe link status on Freescale PCIe controllers was only
    checked once at boot time. So hotplug did not work. With this patch the
    link status is checked on every config read. PCIe devices not present at
    boot time are found after doing 'echo 1 >/sys/bus/pci/rescan'.
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This patch fixes the issue by calling setup_indirect_pci for all device types.
fsl_indirect_read_config is now only used for booke/86xx PCIe controllers.
Reported-by: NMichael Guntsche <mike@it-loops.com>
Cc: Scott Wood <scottwood@freescale.com>
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: NScott Wood <scottwood@freescale.com>

The PCI core supports an offset per aperture nowadays but our arch
code still has a single offset per host bridge representing the
difference betwen CPU memory addresses and PCI MMIO addresses.

This is a problem as new machines and hypervisor versions are
coming out where the 64-bit windows will have a different offset
(basically mapped 1:1) from the 32-bit windows.

This fixes it by using separate offsets. In the long run, we probably
want to get rid of that intermediary struct pci_controller and have
those directly stored into the pci_host_bridge as they are parsed
but this will be a more invasive change.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Linux next is currently failing to compile mpc85xx_defconfig with:
  arch/powerpc/sysdev/fsl_pci.c:944:2: error: too many arguments to function 'setup_pci_atmu'

This is caused by (from Kumar's next branch):
  commit 34642bbb
  Author: Kumar Gala <galak@kernel.crashing.org>
  powerpc/fsl-pci: Keep PCI SoC controller registers in pci_controller

Which changed definition of setup_pci_atmu() but didn't update one of
the callers.  Below fixes this.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Reviewed-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

In patch 34642bbb (powerpc/fsl-pci: Keep PCI SoC controller registers in
pci_controller) we choose to keep the map of the PCI SoC controller
registers. But we missed to delete the unmap in setup_pci_atmu
function. This will cause the following call trace once we access
the PCI SoC controller registers later.

Unable to handle kernel paging request for data at address 0x8000080080040f14
Faulting instruction address: 0xc00000000002ea58
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=24 T4240 QDS
Modules linked in:
NIP: c00000000002ea58 LR: c00000000002eaf4 CTR: c00000000002eac0
REGS: c00000017e10b4a0 TRAP: 0300   Not tainted  (3.9.0-rc1-00052-gfa3529f-dirty)
MSR: 0000000080029000 <CE,EE,ME>  CR: 28adbe22  XER: 00000000
SOFTE: 0
DEAR: 8000080080040f14, ESR: 0000000000000000
TASK = c00000017e100000[1] 'swapper/0' THREAD: c00000017e108000 CPU: 2
GPR00: 0000000000000000 c00000017e10b720 c0000000009928d8 c00000017e578e00
GPR04: 0000000000000000 000000000000000c 0000000000000001 c00000017e10bb40
GPR08: 0000000000000000 8000080080040000 0000000000000000 0000000000000016
GPR12: 0000000088adbe22 c00000000fffa800 c000000000001ba0 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 c0000000008a5b70
GPR24: c0000000008af938 c0000000009a28d8 c0000000009bb5dc c00000017e10bb40
GPR28: c00000017e32a400 c00000017e10bc00 c00000017e32a400 c00000017e578e00
NIP [c00000000002ea58] .fsl_pcie_check_link+0x88/0xf0
LR [c00000000002eaf4] .fsl_indirect_read_config+0x34/0xb0
Call Trace:
[c00000017e10b720] [c00000017e10b7a0] 0xc00000017e10b7a0 (unreliable)
[c00000017e10ba30] [c00000000002eaf4] .fsl_indirect_read_config+0x34/0xb0
[c00000017e10bad0] [c00000000033aa08] .pci_bus_read_config_byte+0x88/0xd0
[c00000017e10bb90] [c00000000088d708] .pci_apply_final_quirks+0x9c/0x18c
[c00000017e10bc40] [c0000000000013dc] .do_one_initcall+0x5c/0x1f0
[c00000017e10bcf0] [c00000000086ebac] .kernel_init_freeable+0x180/0x26c
[c00000017e10bdb0] [c000000000001bbc] .kernel_init+0x1c/0x460
[c00000017e10be30] [c000000000000880] .ret_from_kernel_thread+0x64/0xe4
Instruction dump:
38210310 2b800015 4fdde842 7c600026 5463fffe e8010010 7c0803a6 4e800020
60000000 60000000 e92301d0 7c0004ac <80690f14> 0c030000 4c00012c 38210310
---[ end trace 7a8fe0cbccb7d992 ]---

Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Acked-by: NRoy Zang <tie-fei.zang@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Up to now the PCIe link status on Freescale PCIe controllers was only
checked once at boot time. So hotplug did not work. With this patch the
link status is checked on every config read. PCIe devices not present at
boot time are found after doing 'echo 1 >/sys/bus/pci/rescan'.
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Move to keeping the SoC registers that control and config the PCI
controllers on FSL SoCs in the pci_controller struct.  This allows us to
not need to ioremap() the registers in multiple different places that
use them.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The size might be 64 bit, so use ilog2() instead of __ilog2() or
__ilog2_u64().

ilog2() can select 32bit or 64bit function automatically.
Signed-off-by: NRoy Zang <tie-fei.zang@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The T4240 utilizes a new PCIe controller block that has some minor
programming model differences from previous versions.

The major one that impacts initialization is how we determine the link
state.  On the 3.x controllers we have a memory mapped SoC register
instead of a PCI config register that reports the link state.
Signed-off-by: NRoy Zang <tie-fei.zang@freescale.com>
Signed-off-by: NAndy Fleming <afleming@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>

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>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Power supply for PCI controller ATMU registers is off when system go to
deep-sleep state. So ATMU registers should be re-setup during PCI
controllers resume from sleep.
Signed-off-by: NJia Hongtao <B38951@freescale.com>
Signed-off-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Neither of these should ever be changed once set. Make them const and
fix up the users that try to modify it in-place. In one case
kmalloc+memcpy is replaced with kstrdup() to avoid modifying the string.

Build tested with defconfigs on ARM, PowerPC, Sparc, MIPS, x86 among
others.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Julian Calaby <julian.calaby@gmail.com>

The original code uses 'Programming Interface' field to judge if PCIE is
EP or RC mode, however, some latest silicons do not support this
functionality.  According to PCIE specification, 'Header Type' offset 0x0e
is used to indicate header type, so change code to use 'Header Type' field
to judge PCIE mode. Because FSL PCI controller does not support
'Header Type', patch still uses 'Programming Interface' to identify PCI
mode.
Signed-off-by: NMinghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: NRoy Zang <tie-fei.zang@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Fix the following warning:
arch/powerpc/sysdev/fsl_pci.c: In function 'fsl_pci_probe':
arch/powerpc/sysdev/fsl_pci.c:867:25: error: unused variable 'hose'
Signed-off-by: NJia Hongtao <B38951@freescale.com>
Acked-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

We unified the Freescale pci/pcie initialization by changing the fsl_pci
to a platform driver. In previous PCI code architecture the initialization
routine is called at board_setup_arch stage. Now the initialization is done
in probe function which is architectural better. Also It's convenient for
adding PM support for PCI controller in later patch.

Now we registered pci controllers as platform devices. So we combine two
initialization code as one platform driver.
Signed-off-by: NJia Hongtao <B38951@freescale.com>
Signed-off-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NChunhe Lan <Chunhe.Lan@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Freescale PCIe IP block revision bigger than rev2.2 will also need
redefine the sequence of inbound windows. So change to use IP block
revision instead of compatible for the judgment.
Signed-off-by: NRoy Zang <tie-fei.zang@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Remove the dependency on PCI initialization for SWIOTLB initialization.
So that PCI can be initialized at proper time.

SWIOTLB is partly determined by PCI inbound/outbound map which is assigned
in PCI initialization. But swiotlb_init() should be done at the stage of
mem_init() which is much earlier than PCI initialization. So we reserve the
memory for SWIOTLB first and free it if not necessary.

All boards are converted to fit this change.
Signed-off-by: NJia Hongtao <B38951@freescale.com>
Signed-off-by: NLi Yang <leoli@freescale.com>
Acked-by: NTony Breeds <tony@bakeyournoodle.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The PCI controller on the Freescale P5040 is v2.4.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

We change fsl_add_bridge to return -ENODEV if the controller is working in
agent mode. Then check the return value of fsl_add_bridge to guarantee
that only successfully added host bus will be scanned.
Signed-off-by: NJia Hongtao <B38951@freescale.com>
Signed-off-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

As an alternative incremental starting point to Jia Hongtao's patchset,
get the FSL PCI init out of the board files, but do not yet convert to a
platform driver.

Rather than having each board supply a magic register offset for
determining the "primary" bus, we look for which PCI host bridge
contains an ISA node within its subtree.  If there is no ISA node,
normally that would mean there is no primary bus, but until certain
bugs are fixed we arbitrarily designate a primary in this case.

Conversion to a platform driver and related improvements can happen
after this, as the ordering issues are sorted out.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Change quirk_fsl_pcie_header from __init to __devinit to ensure if we
have a runtime access (like via an FPGA being loaded after boot on the
PCIe link) that we dont access randomly freed memory.
Signed-off-by: NMatias Garcia <mgarcia@rossvideo.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The fixups are executed once the pci-device is found which is during
boot process so __init seems fine as long as the platform does not
support hotplug.

However it is possible to remove the PCI bus at run time and have it
rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call
the fixups again.

Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Upstream changes to the way PHB resources are registered
broke the resource fixup for FSL boards.

We can no longer rely on the resource pointer array for the PHB's
pci_bus structure, so let's leave it alone and go straight for
the PHB resources instead. This also makes the code generally
more readable.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.

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

// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
    when != iounmap(e)
*if (...)
   { ... when != iounmap(e)
     return ...; }
... when any
iounmap(e);
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Add support for vmpic-msi nodes to the fsl_msi driver.  The MSI is
virtualized by the hypervisor, so the vmpic-msi does not contain a 'reg'
property.  Instead, the driver uses hcalls.

Add support for the "msi-address-64" property to the fsl_pci driver.
The Freescale hypervisor typically puts the virtualized MSIIR register
in the page after the end of DDR, so we extend the DDR ATMU to cover it.
Any other location for MSIIR is not supported, for now.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

There is an issue on FSL-BookE 64-bit devices (P5020) in which PCIe
devices that are capable of doing 64-bit DMAs (like an Intel e1000) do
not function and crash the kernel if we have >4G of memory in the system.

The reason is that the existing code only sets up one inbound window for
access to system memory across PCIe.  That window is limited to a 32-bit
address space.  So on systems we'll end up utilizing SWIOTLB for dma
mappings.  However SWIOTLB dma ops implement dma_alloc_coherent() as
dma_direct_alloc_coherent().  Thus we can end up with dma addresses that
are not accessible because of the inbound window limitation.

We could possibly set the SWIOTLB alloc_coherent op to
swiotlb_alloc_coherent() however that does not address the issue since
the swiotlb_alloc_coherent() will behave almost identical to
dma_direct_alloc_coherent() since the devices coherent_dma_mask will be
greater than any address allocated by swiotlb_alloc_coherent() and thus
we'll never bounce buffer it into a range that would be dma-able.

The easiest and best solution is to just make it so that a 64-bit
capable device is able to DMA to any internal system address.

We accomplish this by opening up a second inbound window that maps all
of memory above the internal SoC address width so we can set it up to
access all of the internal SoC address space if needed.

We than fixup the dma_ops and dma_offset for PCIe devices with a dma
mask greater than the maximum internal SoC address.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This renames pci flags functions and enums in preparation for creating
generic version in asm-generic/pci-bridge.h. The following search and
replace is done:

s/ppc_pci_/pci_/
s/PPC_PCI_/PCI_/

Direct accesses to ppc_pci_flag variable are replaced with helper
functions.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>

FSL PCIe controller can act as agent(EP) or host(RC).  Under Agent(EP) mode
the controller will be configured by the host system.  So its not required
to be registered with the PCI(e) sub-system. We only register the
controller if its configured in host(RC) mode.
Signed-off-by: NVivek Mahajan <vivek.mahajan@freescale.com>
Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

We fixup every FSL PCIe Root Complex we need to fixup a few things.
Rather than adding every device under the sun we move to just matching
only on the vendor (PCI_VENDOR_ID_FREESCALE) and than check that we are
a PCIe controller in host mode in the fixup.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Several fixes as well where the +1 was missing.

Done via coccinelle scripts like:

@@
struct resource *ptr;
@@

- ptr->end - ptr->start + 1
+ resource_size(ptr)

and some grep and typing.

Mostly uncompiled, no cross-compilers.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

PCIe nodes with the property status="disabled" are not usable and so
avoid adding "disabled" PCIe bridge with the system.
Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

FSL PCIe controller v2.1:
     - New MSI inbound window
     - Same Inbound windows address as PCIe controller v1.x

Added new pit_t member(pmit) to struct ccsr_pci for MSI inbound window

FSL PCIe controller v2.2 and v2.3:
     - Different addresses for PCIe inbound window 3,2,1
     - Exposed PCIe inbound window 0
     - New PCIe interrupt status register

Added new config and interrupt Status register to struct ccsr_pci & updated
pit_t array size to reflect the 4 inbound windows.

Device tree is used to maintain backward compatibility i.e. update inbound
window 1 index depending upon "compatible" field witin PCIE node.
Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com>
Acked-by: NRoy Zang <tie-fei.zang@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The following commit broke 83xx because it assumed the 83xx platforms
exposed the "IMMR" address in BAR0 like the 85xx/86xx/QoriQ devices do:

commit 3da34aae
Author: Kumar Gala <galak@kernel.crashing.org>
Date:   Tue May 12 15:51:56 2009 -0500

    powerpc/fsl: Support unique MSI addresses per PCIe Root Complex

However that is not true, so we have to search through the inbound
window settings on 83xx to find which one matches the IMMR address to
determine its PCI address.
Reported-by: NIlya Yanok <yanok@emcraft.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This is needed for proper PCI-E support on P1021 SoCs.
Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>