This patch adds wrappers for MMIO access to ELBI, PHY, and other
registers.  No functional change.

[bhelgaas: changelog]
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJingoo Han <jg1.han@samsung.com>

The "dbi_addr" argument to dw_pcie_readl_rc() and dw_pcie_writel_rc()
is redundant and misleading because we always have the "struct pcie_port"
and we always want to use the address from there.

This patch removes the argument and changes the callers to match.
No functional change.

[bhelgaas: changelog]
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJingoo Han <jg1.han@samsung.com>

Exynos PCIe IP consists of Synopsys specific part and Exynos
specific part. Only core block is a Synopsys Designware part;
other parts are Exynos specific.

Also, the Synopsys Designware part can be shared with other
platforms; thus, it can be split two parts such as Synopsys
Designware part and Exynos specific part.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Pratyush Anand <pratyush.anand@st.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>

The Marvell PCIe host controller driver is heavily tied to Device Tree
APIs, and can only be used on platforms where the Device Tree is
used.  Therefore, it should "depends on OF" to avoid build failures on
!OF configurations.
Reported-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit 75096579 ("lib: devres: Introduce devm_ioremap_resource()")
introduced devm_ioremap_resource() and deprecated the use of
devm_request_and_ioremap().

While at it, modify mvebu_pcie_map_registers() to propagate error code.
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>

The Marvell PCIe driver uses an emulated PCI-to-PCI bridge to be able
to dynamically set up MBus address decoding windows for PCI I/O and
memory regions depending on the PCI devices enumerated by Linux.

However, this emulated PCI-to-PCI bridge logic makes the Linux PCI
core believe that prefetchable memory regions are supported (because
the registers are read/write), while in fact no adress decoding window
is ever created for such regions. Since the Marvell MBus address
decoding windows do not distinguish memory regions and prefetchable
memory regions, this patch takes a simple approach: change the
PCI-to-PCI bridge emulation to let the Linux PCI core know that we
don't support prefetchable memory regions.

To achieve this, we simply make the prefetchable memory base a
read-only register that always returns 0. Reading/writing all the
other prefetchable memory related registers has no effect.

This problem was originally reported by Finn Hoffmann
<finn@uni-bremen.de>, who couldn't get a RTL8111/8168B PCI NIC working
on the NSA310 Kirkwood platform after updating to 3.11-rc. The problem
was that the PCI-to-PCI bridge emulation was making the Linux PCI core
believe that we support prefetchable memory, so the Linux PCI core was
only filling the prefetchable memory base and limit registers, which
does not lead to a MBus window being created. The below patch has been
confirmed by Finn Hoffmann to fix his problem on Kirkwood, and has
otherwise been successfully tested on the Armada XP GP platform with a
e1000e PCIe NIC and a Marvell SATA PCIe card.
Reported-by: NFinn Hoffmann <finn@uni-bremen.de>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Exynos5440 has a PCIe controller which can be used as Root Complex.
This driver supports a PCIe controller as Root Complex mode.
Signed-off-by: NSurendranath Gurivireddy Balla <suren.reddy@samsung.com>
Signed-off-by: NSiva Reddy Kallam <siva.kallam@samsung.com>
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Cc: Pratyush Anand <pratyush.anand@st.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

We allow the pci-mvebu driver to be compiled on the Kirkwood platform,
and add the 'marvell,kirkwood-pcie' as a compatible string supported
by the driver.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The status register of the PCI configuration space of PCI-to-PCI
bridges contain some read-only bits, and so write-1-to-clear bits. So,
the Linux PCI core sometimes writes 0xffff to this status register,
and in the current PCI-to-PCI bridge emulation code of the Marvell
driver, we do take all those 1s being written. Even the read-only bits
are being overwritten.

For now, all the read-only bits should be emulated to have the zero
value.

The other bits, that are write-1-to-clear bits are used to report
various kind of errors, and are never set by the emulated bridge, so
there is no need to support this write-1-to-clear bits mechanism.

As a conclusion, the easiest solution is to simply emulate this status
register by returning zero when read, and ignore the writes to it.

This has two visible effects:

 * The devsel is no longer 'unknown' in, i.e

   Flags: bus master, 66MHz, user-definable features, ?? devsel, latency 0

   becomes:

   Flags: bus master, 66MHz, user-definable features, fast devsel, latency 0

   in lspci -v.

   This was caused by a value of 11b being read for devsel, which is
   an invalid value. This 11b value being read was due to a previous
   write of 0xffff into the status register.

 * The capability list is no longer broken, because we indicate to the
   Linux PCI core that we don't have a Capabilities Pointer in the PCI
   configuration space of this bridge. The following message is
   therefore no longer visible in lspci -v:

   Capabilities: [fc] <chain broken>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Until now, the Marvell PCIe driver was only allowing the enumeration
of the devices in the secondary bus of the emulated PCI-to-PCI
bridge. This works fine when a PCIe device is directly connected into
a PCIe slot of the Marvell board.

However, when the device connected in the PCIe slot is a physical PCIe
bridge, beyond which a real PCIe device is connected, it no longer
worked, as the driver was preventing the Linux PCI core from seeing
such devices.

This commit fixes that by ensuring that configuration transactions on
subordinate busses are properly forwarded on the right PCIe interface.

Thanks to this patch, a PCIe card beyond a PCIe bridge, itself beyond
the emulated PCI-to-PCI bridge is properly detected, with the
following layout:

-[0000:00]-+-01.0-[01]----00.0
           +-09.0-[02-07]----00.0-[03-07]--+-01.0-[04]--
           |                               +-05.0-[05]--
           |                               +-07.0-[06]--
           |                               \-09.0-[07]----00.0
           \-0a.0-[08]----00.0

Where the PCIe interface that sits beyond the emulated PCI-to-PCI
bridge at 09.0 allows to access the secondary bus 02, on which there
is a PCIe bridge that allows to access the 3 to 7 busses, that are
subordinates to this bridge. And on one of this bus (bus 7), there is
one real PCIe device connected.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

By default, the Marvell hardware, for each PCIe interface, exhibits
the following devices:

 * On slot 0, a "Marvell Memory controller", identical on all PCIe
   interfaces, and which isn't useful when the Marvell SoC is the PCIe
   root complex (i.e, the normal case when we run Linux on the Marvell
   SoC).

 * On slot 1, the real PCIe card connected into the PCIe slot of the
   board.

So, what the Marvell PCIe driver was doing in its PCI-to-PCI bridge
emulation is that when the Linux PCI core was trying to access the
device in slot 0, we were in fact forwarding the configuration
transaction to the device in slot 1. For all other slots, we were
telling the Linux PCI core that there was no device connected.

However, new versions of bootloaders from Marvell change the default
PCIe configuration, and make the real device appear in slot 0, and the
"Marvell Memory controller" in slot 1.

Therefore, this commit modifies the Marvell PCIe driver to adjust the
PCIe hardware configuration to make sure that this behavior (real
device in slot 0, "Marvell Memory controller" in slot 1) is the one
we'll see regardless of what the bootloader has done. It allows to
remove the little hack that was forwarding configuration transactions
on slot 0 to slot 1, which is nice.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

In case of error, function of_clk_get_by_name() returns
ERR_PTR() never returns NULL. The NULL test in the return
value check should be replaced with IS_ERR().
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.

The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.

Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.

In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the mvebu-mbus driver.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>