Re: [PATCH v2] CNS3xxx: Fix PCIe early iotable_init().
Arnd Bergmann writes: > Applied to next/fixes-non-critical. > > Since the problem is not new and you didn't mark the patch as 'stable', > this seems to be the right place. Let us know if you need backports > to stable kernels, also fo the other patch. Sure, BTW there is also that problem with PCI bridge configuration or something (maybe on certain boards only) which I can't fix at the moment, but will do eventually. So absolutely no rush with this/these patch(es) alone. I just want to make CNS3xxx some valid platform (the same with IXP4xx and I also have some i.MX6 stuff) but it has to wait for now. Thanks, -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] CNS3xxx: Fix PCIe early iotable_init().
Arnd Bergmann a...@arndb.de writes: Applied to next/fixes-non-critical. Since the problem is not new and you didn't mark the patch as 'stable', this seems to be the right place. Let us know if you need backports to stable kernels, also fo the other patch. Sure, BTW there is also that problem with PCI bridge configuration or something (maybe on certain boards only) which I can't fix at the moment, but will do eventually. So absolutely no rush with this/these patch(es) alone. I just want to make CNS3xxx some valid platform (the same with IXP4xx and I also have some i.MX6 stuff) but it has to wait for now. Thanks, -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] CNS3xxx: Fix PCIe early iotable_init().
On Tuesday 04 March 2014, Krzysztof Hałasa wrote: > khal...@piap.pl (Krzysztof Hałasa) writes: > > > 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(). > > That's obviously: > > Signed-off-by: Krzysztof Hałasa > Applied to next/fixes-non-critical. Since the problem is not new and you didn't mark the patch as 'stable', this seems to be the right place. Let us know if you need backports to stable kernels, also fo the other patch. In general, when submitting arm-soc patches for inclusion, please add a...@kernel.org to Cc, so we don't miss it. Thanks, Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] CNS3xxx: Fix PCIe early iotable_init().
On Tuesday 04 March 2014, Krzysztof Hałasa wrote: khal...@piap.pl (Krzysztof Hałasa) writes: 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(). That's obviously: Signed-off-by: Krzysztof Hałasa khal...@piap.pl Applied to next/fixes-non-critical. Since the problem is not new and you didn't mark the patch as 'stable', this seems to be the right place. Let us know if you need backports to stable kernels, also fo the other patch. In general, when submitting arm-soc patches for inclusion, please add a...@kernel.org to Cc, so we don't miss it. Thanks, Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] CNS3xxx: Fix PCIe early iotable_init().
khal...@piap.pl (Krzysztof Hałasa) writes: > 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(). That's obviously: Signed-off-by: Krzysztof Hałasa -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] CNS3xxx: Fix PCIe early iotable_init().
khal...@piap.pl (Krzysztof Hałasa) writes: 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(). That's obviously: Signed-off-by: Krzysztof Hałasa khal...@piap.pl -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] 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.
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -47,6 +47,38 @@ static struct map_desc cns3xxx_io_desc[] __initdata = {
.pfn= __phys_to_pfn(CNS3XXX_PM_BASE),
.length = SZ_4K,
.type = MT_DEVICE,
+#ifdef CONFIG_PCI
+ }, {
+ .virtual= CNS3XXX_PCIE0_HOST_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE0_HOST_BASE),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual= CNS3XXX_PCIE0_CFG0_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE0_CFG0_BASE),
+ .length = SZ_64K, /* really 4 KiB at offset 32 KiB */
+ .type = MT_DEVICE,
+ }, {
+ .virtual= CNS3XXX_PCIE0_CFG1_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE0_CFG1_BASE),
+ .length = SZ_16M,
+ .type = MT_DEVICE,
+ }, {
+ .virtual= CNS3XXX_PCIE1_HOST_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE1_HOST_BASE),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual= CNS3XXX_PCIE1_CFG0_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE1_CFG0_BASE),
+ .length = SZ_64K, /* really 4 KiB at offset 32 KiB */
+ .type = MT_DEVICE,
+ }, {
+ .virtual= CNS3XXX_PCIE1_CFG1_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE1_CFG1_BASE),
+ .length = SZ_16M,
+ .type = MT_DEVICE,
+#endif
},
};
--- a/arch/arm/mach-cns3xxx/pcie.c
+++ b/arch/arm/mach-cns3xxx/pcie.c
@@ -23,15 +23,10 @@
#include "cns3xxx.h"
#include "core.h"
-enum cns3xxx_access_type {
- CNS3XXX_HOST_TYPE = 0,
- CNS3XXX_CFG0_TYPE,
- CNS3XXX_CFG1_TYPE,
- CNS3XXX_NUM_ACCESS_TYPES,
-};
-
struct cns3xxx_pcie {
- struct map_desc cfg_bases[CNS3XXX_NUM_ACCESS_TYPES];
+ 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;
@@ -66,7 +61,6 @@ static void __iomem *cns3xxx_pci_cfg_base(struct pci_bus *bus,
int busno = bus->number;
int slot = PCI_SLOT(devfn);
int offset;
- enum cns3xxx_access_type type;
void __iomem *base;
/* If there is no link, just show the CNS PCI bridge. */
@@ -78,17 +72,21 @@ static void __iomem *cns3xxx_pci_cfg_base(struct pci_bus
*bus,
* we still want to access it. For this to work, we must place
* the first device on the same bus as the CNS PCI bridge.
*/
- if (busno == 0) {
- if (slot > 1)
- return NULL;
- type = slot;
- } else {
- type = CNS3XXX_CFG1_TYPE;
- }
+ if (busno == 0) { /* directly connected PCIe bus */
+ switch (slot) {
+ case 0: /* host bridge device, function 0 only */
+ base = cnspci->host_regs;
+
[PATCH v2] 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.
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -47,6 +47,38 @@ static struct map_desc cns3xxx_io_desc[] __initdata = {
.pfn= __phys_to_pfn(CNS3XXX_PM_BASE),
.length = SZ_4K,
.type = MT_DEVICE,
+#ifdef CONFIG_PCI
+ }, {
+ .virtual= CNS3XXX_PCIE0_HOST_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE0_HOST_BASE),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual= CNS3XXX_PCIE0_CFG0_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE0_CFG0_BASE),
+ .length = SZ_64K, /* really 4 KiB at offset 32 KiB */
+ .type = MT_DEVICE,
+ }, {
+ .virtual= CNS3XXX_PCIE0_CFG1_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE0_CFG1_BASE),
+ .length = SZ_16M,
+ .type = MT_DEVICE,
+ }, {
+ .virtual= CNS3XXX_PCIE1_HOST_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE1_HOST_BASE),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual= CNS3XXX_PCIE1_CFG0_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE1_CFG0_BASE),
+ .length = SZ_64K, /* really 4 KiB at offset 32 KiB */
+ .type = MT_DEVICE,
+ }, {
+ .virtual= CNS3XXX_PCIE1_CFG1_BASE_VIRT,
+ .pfn= __phys_to_pfn(CNS3XXX_PCIE1_CFG1_BASE),
+ .length = SZ_16M,
+ .type = MT_DEVICE,
+#endif
},
};
--- a/arch/arm/mach-cns3xxx/pcie.c
+++ b/arch/arm/mach-cns3xxx/pcie.c
@@ -23,15 +23,10 @@
#include cns3xxx.h
#include core.h
-enum cns3xxx_access_type {
- CNS3XXX_HOST_TYPE = 0,
- CNS3XXX_CFG0_TYPE,
- CNS3XXX_CFG1_TYPE,
- CNS3XXX_NUM_ACCESS_TYPES,
-};
-
struct cns3xxx_pcie {
- struct map_desc cfg_bases[CNS3XXX_NUM_ACCESS_TYPES];
+ 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;
@@ -66,7 +61,6 @@ static void __iomem *cns3xxx_pci_cfg_base(struct pci_bus *bus,
int busno = bus-number;
int slot = PCI_SLOT(devfn);
int offset;
- enum cns3xxx_access_type type;
void __iomem *base;
/* If there is no link, just show the CNS PCI bridge. */
@@ -78,17 +72,21 @@ static void __iomem *cns3xxx_pci_cfg_base(struct pci_bus
*bus,
* we still want to access it. For this to work, we must place
* the first device on the same bus as the CNS PCI bridge.
*/
- if (busno == 0) {
- if (slot 1)
- return NULL;
- type = slot;
- } else {
- type = CNS3XXX_CFG1_TYPE;
- }
+ if (busno == 0) { /* directly connected PCIe bus */
+ switch (slot) {
+ case 0: /* host bridge device, function 0 only */
+ base = cnspci-host_regs;
+ break;
+
