linux-sg2042/arch/arm/mach-cns3xxx/pcie.c

294 lines
8.1 KiB
C
Raw Normal View History

/*
* PCI-E support for CNS3xxx
*
* Copyright 2008 Cavium Networks
* Richard Liu <richard.liu@caviumnetworks.com>
* Copyright 2010 MontaVista Software, LLC.
* Anton Vorontsov <avorontsov@mvista.com>
*
* This file is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License, Version 2, as
* published by the Free Software Foundation.
*/
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/bug.h>
#include <linux/pci.h>
#include <linux/io.h>
#include <linux/ioport.h>
#include <linux/interrupt.h>
#include <linux/ptrace.h>
#include <asm/mach/map.h>
#include "cns3xxx.h"
#include "core.h"
struct cns3xxx_pcie {
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
void __iomem *host_regs; /* PCI config registers for host bridge */
void __iomem *cfg0_regs; /* PCI Type 0 config registers */
void __iomem *cfg1_regs; /* PCI Type 1 config registers */
unsigned int irqs[2];
struct resource res_io;
struct resource res_mem;
int port;
bool linked;
};
static struct cns3xxx_pcie *sysdata_to_cnspci(void *sysdata)
{
struct pci_sys_data *root = sysdata;
return root->private_data;
}
static struct cns3xxx_pcie *pdev_to_cnspci(const struct pci_dev *dev)
{
return sysdata_to_cnspci(dev->sysdata);
}
static struct cns3xxx_pcie *pbus_to_cnspci(struct pci_bus *bus)
{
return sysdata_to_cnspci(bus->sysdata);
}
static void __iomem *cns3xxx_pci_map_bus(struct pci_bus *bus,
unsigned int devfn, int where)
{
struct cns3xxx_pcie *cnspci = pbus_to_cnspci(bus);
int busno = bus->number;
int slot = PCI_SLOT(devfn);
void __iomem *base;
/* If there is no link, just show the CNS PCI bridge. */
if (!cnspci->linked && busno > 0)
return NULL;
/*
* The CNS PCI bridge doesn't fit into the PCI hierarchy, though
ARM: cns3xxx: pci: avoid potential stack overflow The cns3xxx_pcie_hw_init function uses excessive kernel stack space because of a hack that puts a fake struct pci_sys_data and struct pci_bus on the stack in order to call the generic pci_bus_read_config accessors, which causes a warning in ARM allmodconfig builds: arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes I've spent a few hours trying to find out what exactly this code is wants to achieve here. The obvious part is setting up the host_regs using config space accessors, and this can simply be changed to use direct MMIO accesses, as I do in this patch. The second part is how the driver sets up the Max_Read_Request_Size value for the first device/function on bus 1, i.e. the device plugged directly into the PCIe root port. For all I can tell, this is in fact incomplete, as it does not perform the same setting on devices attached to a PCIe switch, or multi-function devices. The solution for this part fortunately is even easier: if we just set the global pcie_bus_config variable to PCIE_BUS_PEER2PEER, all PCIe devices in the system are limited to 128 byte MPS, which in turn limits the MRRS to 128 bytes for all devices, and we no longer even need to touch any devices. With those two changes in place, we no longer need the fake pci_sys_data/pci_bus structures for faking config space writes, and the stack usage goes down as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl>
2015-10-08 04:05:49 +08:00
* we still want to access it.
* We place the host bridge on bus 0, and the directly connected
* device on bus 1, slot 0.
*/
if (busno == 0) { /* internal PCIe bus, host bridge device */
if (devfn == 0) /* device# and function# are ignored by hw */
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
base = cnspci->host_regs;
else
return NULL; /* no such device */
} else if (busno == 1) { /* directly connected PCIe device */
if (slot == 0) /* device# is ignored by hw */
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
base = cnspci->cfg0_regs;
else
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
return NULL; /* no such device */
} else /* remote PCI bus */
base = cnspci->cfg1_regs + ((busno & 0xf) << 20);
return base + (where & 0xffc) + (devfn << 12);
}
static int cns3xxx_pci_read_config(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
{
int ret;
u32 mask = (0x1ull << (size * 8)) - 1;
int shift = (where % 4) * 8;
ret = pci_generic_config_read32(bus, devfn, where, size, val);
if (ret == PCIBIOS_SUCCESSFUL && !bus->number && !devfn &&
(where & 0xffc) == PCI_CLASS_REVISION)
/*
* RC's class is 0xb, but Linux PCI driver needs 0x604
* for a PCIe bridge. So we must fixup the class code
* to 0x604 here.
*/
*val = ((((*val << shift) & 0xff) | (0x604 << 16)) >> shift) & mask;
return ret;
}
static int cns3xxx_pci_setup(int nr, struct pci_sys_data *sys)
{
struct cns3xxx_pcie *cnspci = sysdata_to_cnspci(sys);
struct resource *res_io = &cnspci->res_io;
struct resource *res_mem = &cnspci->res_mem;
BUG_ON(request_resource(&iomem_resource, res_io) ||
request_resource(&iomem_resource, res_mem));
pci_add_resource_offset(&sys->resources, res_io, sys->io_offset);
pci_add_resource_offset(&sys->resources, res_mem, sys->mem_offset);
return 1;
}
static struct pci_ops cns3xxx_pcie_ops = {
.map_bus = cns3xxx_pci_map_bus,
.read = cns3xxx_pci_read_config,
.write = pci_generic_config_write,
};
PCI: Make the struct pci_dev * argument of pci_fixup_irqs const. Aside of the usual motivation for constification, this function has a history of being abused a hook for interrupt and other fixups so I turned this function const ages ago in the MIPS code but it should be done treewide. Due to function pointer passing in varous places a few other functions had to be constified as well. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> To: Anton Vorontsov <avorontsov@mvista.com> To: Chris Metcalf <cmetcalf@tilera.com> To: Colin Cross <ccross@android.com> Acked-by: "David S. Miller" <davem@davemloft.net> To: Eric Miao <eric.y.miao@gmail.com> To: Erik Gilling <konkers@android.com> Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn> To: "H. Peter Anvin" <hpa@zytor.com> To: Imre Kaloz <kaloz@openwrt.org> To: Ingo Molnar <mingo@redhat.com> To: Ivan Kokshaysky <ink@jurassic.park.msu.ru> To: Jesse Barnes <jbarnes@virtuousgeek.org> To: Krzysztof Halasa <khc@pm.waw.pl> To: Lennert Buytenhek <kernel@wantstofly.org> To: Matt Turner <mattst88@gmail.com> To: Nicolas Pitre <nico@fluxnic.net> To: Olof Johansson <olof@lixom.net> Acked-by: Paul Mundt <lethal@linux-sh.org> To: Richard Henderson <rth@twiddle.net> To: Russell King <linux@arm.linux.org.uk> To: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-alpha@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-pci@vger.kernel.org Cc: linux-sh@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: sparclinux@vger.kernel.org Cc: x86@kernel.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-06-10 22:30:21 +08:00
static int cns3xxx_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
struct cns3xxx_pcie *cnspci = pdev_to_cnspci(dev);
int irq = cnspci->irqs[!!dev->bus->number];
pr_info("PCIe map irq: %04d:%02x:%02x.%02x slot %d, pin %d, irq: %d\n",
pci_domain_nr(dev->bus), dev->bus->number, PCI_SLOT(dev->devfn),
PCI_FUNC(dev->devfn), slot, pin, irq);
return irq;
}
static struct cns3xxx_pcie cns3xxx_pcie[] = {
[0] = {
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
.host_regs = (void __iomem *)CNS3XXX_PCIE0_HOST_BASE_VIRT,
.cfg0_regs = (void __iomem *)CNS3XXX_PCIE0_CFG0_BASE_VIRT,
.cfg1_regs = (void __iomem *)CNS3XXX_PCIE0_CFG1_BASE_VIRT,
.res_io = {
.name = "PCIe0 I/O space",
.start = CNS3XXX_PCIE0_IO_BASE,
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
.end = CNS3XXX_PCIE0_CFG0_BASE - 1, /* 16 MiB */
.flags = IORESOURCE_IO,
},
.res_mem = {
.name = "PCIe0 non-prefetchable",
.start = CNS3XXX_PCIE0_MEM_BASE,
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
.end = CNS3XXX_PCIE0_HOST_BASE - 1, /* 176 MiB */
.flags = IORESOURCE_MEM,
},
.irqs = { IRQ_CNS3XXX_PCIE0_RC, IRQ_CNS3XXX_PCIE0_DEVICE, },
.port = 0,
},
[1] = {
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
.host_regs = (void __iomem *)CNS3XXX_PCIE1_HOST_BASE_VIRT,
.cfg0_regs = (void __iomem *)CNS3XXX_PCIE1_CFG0_BASE_VIRT,
.cfg1_regs = (void __iomem *)CNS3XXX_PCIE1_CFG1_BASE_VIRT,
.res_io = {
.name = "PCIe1 I/O space",
.start = CNS3XXX_PCIE1_IO_BASE,
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
.end = CNS3XXX_PCIE1_CFG0_BASE - 1, /* 16 MiB */
.flags = IORESOURCE_IO,
},
.res_mem = {
.name = "PCIe1 non-prefetchable",
.start = CNS3XXX_PCIE1_MEM_BASE,
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
.end = CNS3XXX_PCIE1_HOST_BASE - 1, /* 176 MiB */
.flags = IORESOURCE_MEM,
},
.irqs = { IRQ_CNS3XXX_PCIE1_RC, IRQ_CNS3XXX_PCIE1_DEVICE, },
.port = 1,
},
};
static void __init cns3xxx_pcie_check_link(struct cns3xxx_pcie *cnspci)
{
int port = cnspci->port;
u32 reg;
unsigned long time;
reg = __raw_readl(MISC_PCIE_CTRL(port));
/*
* Enable Application Request to 1, it will exit L1 automatically,
* but when chip back, it will use another clock, still can use 0x1.
*/
reg |= 0x3;
__raw_writel(reg, MISC_PCIE_CTRL(port));
pr_info("PCIe: Port[%d] Enable PCIe LTSSM\n", port);
pr_info("PCIe: Port[%d] Check data link layer...", port);
time = jiffies;
while (1) {
reg = __raw_readl(MISC_PCIE_PM_DEBUG(port));
if (reg & 0x1) {
pr_info("Link up.\n");
cnspci->linked = 1;
break;
} else if (time_after(jiffies, time + 50)) {
pr_info("Device not found.\n");
break;
}
}
}
ARM: cns3xxx: pci: avoid potential stack overflow The cns3xxx_pcie_hw_init function uses excessive kernel stack space because of a hack that puts a fake struct pci_sys_data and struct pci_bus on the stack in order to call the generic pci_bus_read_config accessors, which causes a warning in ARM allmodconfig builds: arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes I've spent a few hours trying to find out what exactly this code is wants to achieve here. The obvious part is setting up the host_regs using config space accessors, and this can simply be changed to use direct MMIO accesses, as I do in this patch. The second part is how the driver sets up the Max_Read_Request_Size value for the first device/function on bus 1, i.e. the device plugged directly into the PCIe root port. For all I can tell, this is in fact incomplete, as it does not perform the same setting on devices attached to a PCIe switch, or multi-function devices. The solution for this part fortunately is even easier: if we just set the global pcie_bus_config variable to PCIE_BUS_PEER2PEER, all PCIe devices in the system are limited to 128 byte MPS, which in turn limits the MRRS to 128 bytes for all devices, and we no longer even need to touch any devices. With those two changes in place, we no longer need the fake pci_sys_data/pci_bus structures for faking config space writes, and the stack usage goes down as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl>
2015-10-08 04:05:49 +08:00
static void cns3xxx_write_config(struct cns3xxx_pcie *cnspci,
int where, int size, u32 val)
{
void __iomem *base = cnspci->host_regs + (where & 0xffc);
u32 v;
u32 mask = (0x1ull << (size * 8)) - 1;
int shift = (where % 4) * 8;
v = readl_relaxed(base);
ARM: cns3xxx: pci: avoid potential stack overflow The cns3xxx_pcie_hw_init function uses excessive kernel stack space because of a hack that puts a fake struct pci_sys_data and struct pci_bus on the stack in order to call the generic pci_bus_read_config accessors, which causes a warning in ARM allmodconfig builds: arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes I've spent a few hours trying to find out what exactly this code is wants to achieve here. The obvious part is setting up the host_regs using config space accessors, and this can simply be changed to use direct MMIO accesses, as I do in this patch. The second part is how the driver sets up the Max_Read_Request_Size value for the first device/function on bus 1, i.e. the device plugged directly into the PCIe root port. For all I can tell, this is in fact incomplete, as it does not perform the same setting on devices attached to a PCIe switch, or multi-function devices. The solution for this part fortunately is even easier: if we just set the global pcie_bus_config variable to PCIE_BUS_PEER2PEER, all PCIe devices in the system are limited to 128 byte MPS, which in turn limits the MRRS to 128 bytes for all devices, and we no longer even need to touch any devices. With those two changes in place, we no longer need the fake pci_sys_data/pci_bus structures for faking config space writes, and the stack usage goes down as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl>
2015-10-08 04:05:49 +08:00
v &= ~(mask << shift);
v |= (val & mask) << shift;
writel_relaxed(v, base);
readl_relaxed(base);
ARM: cns3xxx: pci: avoid potential stack overflow The cns3xxx_pcie_hw_init function uses excessive kernel stack space because of a hack that puts a fake struct pci_sys_data and struct pci_bus on the stack in order to call the generic pci_bus_read_config accessors, which causes a warning in ARM allmodconfig builds: arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes I've spent a few hours trying to find out what exactly this code is wants to achieve here. The obvious part is setting up the host_regs using config space accessors, and this can simply be changed to use direct MMIO accesses, as I do in this patch. The second part is how the driver sets up the Max_Read_Request_Size value for the first device/function on bus 1, i.e. the device plugged directly into the PCIe root port. For all I can tell, this is in fact incomplete, as it does not perform the same setting on devices attached to a PCIe switch, or multi-function devices. The solution for this part fortunately is even easier: if we just set the global pcie_bus_config variable to PCIE_BUS_PEER2PEER, all PCIe devices in the system are limited to 128 byte MPS, which in turn limits the MRRS to 128 bytes for all devices, and we no longer even need to touch any devices. With those two changes in place, we no longer need the fake pci_sys_data/pci_bus structures for faking config space writes, and the stack usage goes down as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl>
2015-10-08 04:05:49 +08:00
}
static void __init cns3xxx_pcie_hw_init(struct cns3xxx_pcie *cnspci)
{
CNS3xxx: Fix PCIe early iotable_init(). This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from machine_desc->map_io(), this patch adds the required mappings to the main CNS3xxx mapping table. This means we don't convert .pfn back to virtual addresses in pcie.c. The size of the address space consumed for PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this doesn't include MMIO address space required by PCI devices): - Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB. It's a PCI configuration address space for the local (on-chip) PCIe bridge. - Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for Type 0 Configuration accesses, i.e., accesses to the single device (with possible "functions") on the other end of the PCIe link. We really only need a 4 KiB page at 0x8000 (see the offset calculation in cns3xxx_pci_cfg_base()). There is still a potential problem with PCI bus numbers > 0xF, are they supported? - The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should be clearer now. - The maximum address space allocated for PCI MMIO is now correctly shown in /proc/iomem as 176 MiB (per each of the two PCI "domains" - previously only 16 MiB were reserved). This patch has been tested on Gateworks Laguna board, masqueraded as CNS3420VB. Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-03-04 15:37:10 +08:00
u16 mem_base = cnspci->res_mem.start >> 16;
u16 mem_limit = cnspci->res_mem.end >> 16;
u16 io_base = cnspci->res_io.start >> 16;
u16 io_limit = cnspci->res_io.end >> 16;
ARM: cns3xxx: pci: avoid potential stack overflow The cns3xxx_pcie_hw_init function uses excessive kernel stack space because of a hack that puts a fake struct pci_sys_data and struct pci_bus on the stack in order to call the generic pci_bus_read_config accessors, which causes a warning in ARM allmodconfig builds: arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes I've spent a few hours trying to find out what exactly this code is wants to achieve here. The obvious part is setting up the host_regs using config space accessors, and this can simply be changed to use direct MMIO accesses, as I do in this patch. The second part is how the driver sets up the Max_Read_Request_Size value for the first device/function on bus 1, i.e. the device plugged directly into the PCIe root port. For all I can tell, this is in fact incomplete, as it does not perform the same setting on devices attached to a PCIe switch, or multi-function devices. The solution for this part fortunately is even easier: if we just set the global pcie_bus_config variable to PCIE_BUS_PEER2PEER, all PCIe devices in the system are limited to 128 byte MPS, which in turn limits the MRRS to 128 bytes for all devices, and we no longer even need to touch any devices. With those two changes in place, we no longer need the fake pci_sys_data/pci_bus structures for faking config space writes, and the stack usage goes down as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl>
2015-10-08 04:05:49 +08:00
cns3xxx_write_config(cnspci, PCI_PRIMARY_BUS, 1, 0);
cns3xxx_write_config(cnspci, PCI_SECONDARY_BUS, 1, 1);
cns3xxx_write_config(cnspci, PCI_SUBORDINATE_BUS, 1, 1);
cns3xxx_write_config(cnspci, PCI_MEMORY_BASE, 2, mem_base);
cns3xxx_write_config(cnspci, PCI_MEMORY_LIMIT, 2, mem_limit);
cns3xxx_write_config(cnspci, PCI_IO_BASE_UPPER16, 2, io_base);
cns3xxx_write_config(cnspci, PCI_IO_LIMIT_UPPER16, 2, io_limit);
if (!cnspci->linked)
return;
/* Set Device Max_Read_Request_Size to 128 byte */
ARM: cns3xxx: pci: avoid potential stack overflow The cns3xxx_pcie_hw_init function uses excessive kernel stack space because of a hack that puts a fake struct pci_sys_data and struct pci_bus on the stack in order to call the generic pci_bus_read_config accessors, which causes a warning in ARM allmodconfig builds: arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes I've spent a few hours trying to find out what exactly this code is wants to achieve here. The obvious part is setting up the host_regs using config space accessors, and this can simply be changed to use direct MMIO accesses, as I do in this patch. The second part is how the driver sets up the Max_Read_Request_Size value for the first device/function on bus 1, i.e. the device plugged directly into the PCIe root port. For all I can tell, this is in fact incomplete, as it does not perform the same setting on devices attached to a PCIe switch, or multi-function devices. The solution for this part fortunately is even easier: if we just set the global pcie_bus_config variable to PCIE_BUS_PEER2PEER, all PCIe devices in the system are limited to 128 byte MPS, which in turn limits the MRRS to 128 bytes for all devices, and we no longer even need to touch any devices. With those two changes in place, we no longer need the fake pci_sys_data/pci_bus structures for faking config space writes, and the stack usage goes down as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl>
2015-10-08 04:05:49 +08:00
pcie_bus_config = PCIE_BUS_PEER2PEER;
/* Disable PCIe0 Interrupt Mask INTA to INTD */
ARM: cns3xxx: pci: avoid potential stack overflow The cns3xxx_pcie_hw_init function uses excessive kernel stack space because of a hack that puts a fake struct pci_sys_data and struct pci_bus on the stack in order to call the generic pci_bus_read_config accessors, which causes a warning in ARM allmodconfig builds: arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes I've spent a few hours trying to find out what exactly this code is wants to achieve here. The obvious part is setting up the host_regs using config space accessors, and this can simply be changed to use direct MMIO accesses, as I do in this patch. The second part is how the driver sets up the Max_Read_Request_Size value for the first device/function on bus 1, i.e. the device plugged directly into the PCIe root port. For all I can tell, this is in fact incomplete, as it does not perform the same setting on devices attached to a PCIe switch, or multi-function devices. The solution for this part fortunately is even easier: if we just set the global pcie_bus_config variable to PCIE_BUS_PEER2PEER, all PCIe devices in the system are limited to 128 byte MPS, which in turn limits the MRRS to 128 bytes for all devices, and we no longer even need to touch any devices. With those two changes in place, we no longer need the fake pci_sys_data/pci_bus structures for faking config space writes, and the stack usage goes down as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl>
2015-10-08 04:05:49 +08:00
__raw_writel(~0x3FFF, MISC_PCIE_INT_MASK(cnspci->port));
}
static int cns3xxx_pcie_abort_handler(unsigned long addr, unsigned int fsr,
struct pt_regs *regs)
{
if (fsr & (1 << 10))
regs->ARM_pc += 4;
return 0;
}
void __init cns3xxx_pcie_init_late(void)
{
int i;
void *private_data;
struct hw_pci hw_pci = {
.nr_controllers = 1,
.ops = &cns3xxx_pcie_ops,
.setup = cns3xxx_pci_setup,
.map_irq = cns3xxx_pcie_map_irq,
.private_data = &private_data,
};
pcibios_min_io = 0;
pcibios_min_mem = 0;
hook_fault_code(16 + 6, cns3xxx_pcie_abort_handler, SIGBUS, 0,
"imprecise external abort");
for (i = 0; i < ARRAY_SIZE(cns3xxx_pcie); i++) {
cns3xxx_pwr_clk_en(0x1 << PM_CLK_GATE_REG_OFFSET_PCIE(i));
cns3xxx_pwr_soft_rst(0x1 << PM_SOFT_RST_REG_OFFST_PCIE(i));
cns3xxx_pcie_check_link(&cns3xxx_pcie[i]);
cns3xxx_pcie_hw_init(&cns3xxx_pcie[i]);
private_data = &cns3xxx_pcie[i];
pci_common_init(&hw_pci);
}
pci_assign_unassigned_resources();
}