[ARM] CNS3xxx: 3 regressions identified in v3.14-rc4+

[ARM] CNS3xxx: 3 regressions identified in v3.14-rc4+

[Krzysztof Hałasa]

Hello,

Linux version 3.14.0-rc4+ (current tip, no extra patches), CPU is Cavium
Econa CNS3420, board is Gateworks Laguna GW2388-4 (masqueraded as
CNS3420VB).


Issue #1 ###################################################

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(). I'll attach the patch.


Issue #2 ###################################################

PCI hangs system completely while trying to access any PCI MMIO region
(plain IO not tested).

The guilty commit is 928bea964827d7824b548c1f8e06eccbbc4d0d7d:

    PCI: Delay enabling bridges until they're needed

    We currently enable PCI bridges after scanning a bus and assigning
    resources.  This is often done in arch code.

    This patch changes this so we don't enable a bridge until necessary, i.e.,
    until we enable a PCI device behind the bridge.  We do this in the generic
    pci_enable_device() path, so this also removes the arch-specific code to
    enable bridges.

Reverting changes in arch/arm/kernel/bios32.c, drivers/pci/bus.c and
include/linux/pci.h (= essentially adding pci_enable_bridges(bus) in
ARM's pci_common_init_dev()) makes it work again.

Options?


Issue #3 ###################################################

NR_IRQS:16 nr_irqs:96 96

WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
Backtrace:
gic_init_bases    from cns3xxx_init_irq+0x24/0x34
cns3xxx_init_irq  from init_IRQ+0x24/0x2c
init_IRQ          from start_kernel+0x1a8/0x338
start_kernel      from 0x2000806c

I'm having problems understanding how is machine_desc->nr_irqs supposed
to work with CONFIG_ARM_GIC and CONFIG_SPARSE_IRQ set.

machine_desc->nr_irqs is set to NR_IRQS_CNS3XXX =
IRQ_TC11MP_GIC_START + 64 = 32 + 64 = 96.

At start, machine_desc->nr_irqs are pre-allocated via
start_kernel() -> early_irq_init().

Then, gic_init(0, 29, ...) ->  gic_init_bases(0, 29, ...) tries this
(and fails):

	/*
	 * For primary GICs, skip over SGIs.
	 * For secondary GICs, skip over PPIs, too.
	 */
	irq_start = (effectively) 16;

	irq_base = irq_alloc_descs(irq_start, 16, gic_irqs, numa_node_id());
	if (IS_ERR_VALUE(irq_base)) {
		WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
		     irq_start);

Does this mean machine_desc->nr_irqs is to be kept at 16
(NR_IRQS_LEGACY) or less, so it doesn't conflict with gic_init()?

Or perhaps gic_init() shouldn't warn about this?

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[ARM] CNS3xxx: 3 regressions identified in v3.14-rc4+

[Krzysztof Hałasa]

Hello,

Linux version 3.14.0-rc4+ (current tip, no extra patches), CPU is Cavium
Econa CNS3420, board is Gateworks Laguna GW2388-4 (masqueraded as
CNS3420VB).


Issue #1 ###################################################

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(). I'll attach the patch.


Issue #2 ###################################################

PCI hangs system completely while trying to access any PCI MMIO region
(plain IO not tested).

The guilty commit is 928bea964827d7824b548c1f8e06eccbbc4d0d7d:

    PCI: Delay enabling bridges until they're needed

    We currently enable PCI bridges after scanning a bus and assigning
    resources.  This is often done in arch code.

    This patch changes this so we don't enable a bridge until necessary, i.e.,
    until we enable a PCI device behind the bridge.  We do this in the generic
    pci_enable_device() path, so this also removes the arch-specific code to
    enable bridges.

Reverting changes in arch/arm/kernel/bios32.c, drivers/pci/bus.c and
include/linux/pci.h (= essentially adding pci_enable_bridges(bus) in
ARM's pci_common_init_dev()) makes it work again.

Options?


Issue #3 ###################################################

NR_IRQS:16 nr_irqs:96 96

WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
Backtrace:
gic_init_bases    from cns3xxx_init_irq+0x24/0x34
cns3xxx_init_irq  from init_IRQ+0x24/0x2c
init_IRQ          from start_kernel+0x1a8/0x338
start_kernel      from 0x2000806c

I'm having problems understanding how is machine_desc->nr_irqs supposed
to work with CONFIG_ARM_GIC and CONFIG_SPARSE_IRQ set.

machine_desc->nr_irqs is set to NR_IRQS_CNS3XXX =
IRQ_TC11MP_GIC_START + 64 = 32 + 64 = 96.

At start, machine_desc->nr_irqs are pre-allocated via
start_kernel() -> early_irq_init().

Then, gic_init(0, 29, ...) ->  gic_init_bases(0, 29, ...) tries this
(and fails):

	/*
	 * For primary GICs, skip over SGIs.
	 * For secondary GICs, skip over PPIs, too.
	 */
	irq_start = (effectively) 16;

	irq_base = irq_alloc_descs(irq_start, 16, gic_irqs, numa_node_id());
	if (IS_ERR_VALUE(irq_base)) {
		WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
		     irq_start);

Does this mean machine_desc->nr_irqs is to be kept at 16
(NR_IRQS_LEGACY) or less, so it doesn't conflict with gic_init()?

Or perhaps gic_init() shouldn't warn about this?

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>

--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -240,7 +240,7 @@ static void __init cns3420_map_io(void)
 {
 	cns3xxx_map_io();
 	iotable_init(cns3420_io_desc, ARRAY_SIZE(cns3420_io_desc));
-
+	cns3xxx_pcie_iotable_init();
 	cns3420_early_serial_setup();
 }
 
--- a/arch/arm/mach-cns3xxx/core.h
+++ b/arch/arm/mach-cns3xxx/core.h
@@ -14,6 +14,7 @@
 #include <linux/reboot.h>
 
 extern void cns3xxx_timer_init(void);
+extern void cns3xxx_pcie_iotable_init(void);
 
 #ifdef CONFIG_CACHE_L2X0
 void __init cns3xxx_l2x0_init(void);
--- a/arch/arm/mach-cns3xxx/pcie.c
+++ b/arch/arm/mach-cns3xxx/pcie.c
@@ -357,6 +357,15 @@ static int cns3xxx_pcie_abort_handler(unsigned long addr, unsigned int fsr,
 	return 0;
 }
 
+void __init cns3xxx_pcie_iotable_init()
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(cns3xxx_pcie); i++)
+		iotable_init(cns3xxx_pcie[i].cfg_bases,
+			     ARRAY_SIZE(cns3xxx_pcie[i].cfg_bases));
+}
+
 static int __init cns3xxx_pcie_init(void)
 {
 	int i;
@@ -368,8 +377,6 @@ static int __init cns3xxx_pcie_init(void)
 			"imprecise external abort");
 
 	for (i = 0; i < ARRAY_SIZE(cns3xxx_pcie); i++) {
-		iotable_init(cns3xxx_pcie[i].cfg_bases,
-			     ARRAY_SIZE(cns3xxx_pcie[i].cfg_bases));
 		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]);

[PATCH] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl>

--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -240,7 +240,7 @@ static void __init cns3420_map_io(void)
 {
 	cns3xxx_map_io();
 	iotable_init(cns3420_io_desc, ARRAY_SIZE(cns3420_io_desc));
-
+	cns3xxx_pcie_iotable_init();
 	cns3420_early_serial_setup();
 }
 
--- a/arch/arm/mach-cns3xxx/core.h
+++ b/arch/arm/mach-cns3xxx/core.h
@@ -14,6 +14,7 @@
 #include <linux/reboot.h>
 
 extern void cns3xxx_timer_init(void);
+extern void cns3xxx_pcie_iotable_init(void);
 
 #ifdef CONFIG_CACHE_L2X0
 void __init cns3xxx_l2x0_init(void);
--- a/arch/arm/mach-cns3xxx/pcie.c
+++ b/arch/arm/mach-cns3xxx/pcie.c
@@ -357,6 +357,15 @@ static int cns3xxx_pcie_abort_handler(unsigned long addr, unsigned int fsr,
 	return 0;
 }
 
+void __init cns3xxx_pcie_iotable_init()
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(cns3xxx_pcie); i++)
+		iotable_init(cns3xxx_pcie[i].cfg_bases,
+			     ARRAY_SIZE(cns3xxx_pcie[i].cfg_bases));
+}
+
 static int __init cns3xxx_pcie_init(void)
 {
 	int i;
@@ -368,8 +377,6 @@ static int __init cns3xxx_pcie_init(void)
 			"imprecise external abort");
 
 	for (i = 0; i < ARRAY_SIZE(cns3xxx_pcie); i++) {
-		iotable_init(cns3xxx_pcie[i].cfg_bases,
-			     ARRAY_SIZE(cns3xxx_pcie[i].cfg_bases));
 		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]);

Re: [PATCH] CNS3xxx: Fix PCIe early iotable_init().

[Arnd Bergmann]

On Friday 28 February 2014 12:12:45 Krzysztof Hałasa wrote:
> Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
> 

Patch looks good, but please add the changeset description from
your first patch.

	Arnd

[PATCH] CNS3xxx: Fix PCIe early iotable_init().

[Arnd Bergmann]

On Friday 28 February 2014 12:12:45 Krzysztof Ha?asa wrote:
> Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl>
> 

Patch looks good, but please add the changeset description from
your first patch.

	Arnd

Re: [ARM] CNS3xxx: 3 regressions identified in v3.14-rc4+

[Arnd Bergmann]

On Friday 28 February 2014 12:00:12 Krzysztof Hałasa wrote:
> 
> PCI hangs system completely while trying to access any PCI MMIO region
> (plain IO not tested).
> 
> The guilty commit is 928bea964827d7824b548c1f8e06eccbbc4d0d7d:
> 
>     PCI: Delay enabling bridges until they're needed
> 
>     We currently enable PCI bridges after scanning a bus and assigning
>     resources.  This is often done in arch code.
> 
>     This patch changes this so we don't enable a bridge until necessary, i.e.,
>     until we enable a PCI device behind the bridge.  We do this in the generic
>     pci_enable_device() path, so this also removes the arch-specific code to
>     enable bridges.
> 
> Reverting changes in arch/arm/kernel/bios32.c, drivers/pci/bus.c and
> include/linux/pci.h (= essentially adding pci_enable_bridges(bus) in
> ARM's pci_common_init_dev()) makes it work again.
> 
> Options?

Hmm, this was in 3.12 already, right?

Can you try adding the code in a host specific callback such as
hw->add_bus?

> Issue #3 ###################################################
> 
> NR_IRQS:16 nr_irqs:96 96
> 
> WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
> Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
> Backtrace:
> gic_init_bases    from cns3xxx_init_irq+0x24/0x34
> cns3xxx_init_irq  from init_IRQ+0x24/0x2c
> init_IRQ          from start_kernel+0x1a8/0x338
> start_kernel      from 0x2000806c
> 
> I'm having problems understanding how is machine_desc->nr_irqs supposed
> to work with CONFIG_ARM_GIC and CONFIG_SPARSE_IRQ set.
> 
> machine_desc->nr_irqs is set to NR_IRQS_CNS3XXX =
> IRQ_TC11MP_GIC_START + 64 = 32 + 64 = 96.
> 
> At start, machine_desc->nr_irqs are pre-allocated via
> start_kernel() -> early_irq_init().
> 
> Then, gic_init(0, 29, ...) ->  gic_init_bases(0, 29, ...) tries this
> (and fails):
> 
>         /*
>          * For primary GICs, skip over SGIs.
>          * For secondary GICs, skip over PPIs, too.
>          */
>         irq_start = (effectively) 16;
> 
>         irq_base = irq_alloc_descs(irq_start, 16, gic_irqs, numa_node_id());
>         if (IS_ERR_VALUE(irq_base)) {
>                 WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
>                      irq_start);
> 
> Does this mean machine_desc->nr_irqs is to be kept at 16
> (NR_IRQS_LEGACY) or less, so it doesn't conflict with gic_init()?
> 
> Or perhaps gic_init() shouldn't warn about this?

I think the problem is that both the board file and the gic code try to
set up legacy interrupts. Try just removing the 'nr_irqs=' line.

	Arnd

[ARM] CNS3xxx: 3 regressions identified in v3.14-rc4+

[Arnd Bergmann]

On Friday 28 February 2014 12:00:12 Krzysztof Ha?asa wrote:
> 
> PCI hangs system completely while trying to access any PCI MMIO region
> (plain IO not tested).
> 
> The guilty commit is 928bea964827d7824b548c1f8e06eccbbc4d0d7d:
> 
>     PCI: Delay enabling bridges until they're needed
> 
>     We currently enable PCI bridges after scanning a bus and assigning
>     resources.  This is often done in arch code.
> 
>     This patch changes this so we don't enable a bridge until necessary, i.e.,
>     until we enable a PCI device behind the bridge.  We do this in the generic
>     pci_enable_device() path, so this also removes the arch-specific code to
>     enable bridges.
> 
> Reverting changes in arch/arm/kernel/bios32.c, drivers/pci/bus.c and
> include/linux/pci.h (= essentially adding pci_enable_bridges(bus) in
> ARM's pci_common_init_dev()) makes it work again.
> 
> Options?

Hmm, this was in 3.12 already, right?

Can you try adding the code in a host specific callback such as
hw->add_bus?

> Issue #3 ###################################################
> 
> NR_IRQS:16 nr_irqs:96 96
> 
> WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
> Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
> Backtrace:
> gic_init_bases    from cns3xxx_init_irq+0x24/0x34
> cns3xxx_init_irq  from init_IRQ+0x24/0x2c
> init_IRQ          from start_kernel+0x1a8/0x338
> start_kernel      from 0x2000806c
> 
> I'm having problems understanding how is machine_desc->nr_irqs supposed
> to work with CONFIG_ARM_GIC and CONFIG_SPARSE_IRQ set.
> 
> machine_desc->nr_irqs is set to NR_IRQS_CNS3XXX =
> IRQ_TC11MP_GIC_START + 64 = 32 + 64 = 96.
> 
> At start, machine_desc->nr_irqs are pre-allocated via
> start_kernel() -> early_irq_init().
> 
> Then, gic_init(0, 29, ...) ->  gic_init_bases(0, 29, ...) tries this
> (and fails):
> 
>         /*
>          * For primary GICs, skip over SGIs.
>          * For secondary GICs, skip over PPIs, too.
>          */
>         irq_start = (effectively) 16;
> 
>         irq_base = irq_alloc_descs(irq_start, 16, gic_irqs, numa_node_id());
>         if (IS_ERR_VALUE(irq_base)) {
>                 WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
>                      irq_start);
> 
> Does this mean machine_desc->nr_irqs is to be kept at 16
> (NR_IRQS_LEGACY) or less, so it doesn't conflict with gic_init()?
> 
> Or perhaps gic_init() shouldn't warn about this?

I think the problem is that both the board file and the gic code try to
set up legacy interrupts. Try just removing the 'nr_irqs=' line.

	Arnd

Re: [PATCH] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

Arnd Bergmann <arnd@arndb.de> writes:

> Patch looks good, but please add the changeset description from
> your first patch.

I wonder if another approach would be better. I don't like the .pfn
messing and the bugs that function introduces.
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

Arnd Bergmann <arnd@arndb.de> writes:

> Patch looks good, but please add the changeset description from
> your first patch.

I wonder if another approach would be better. I don't like the .pfn
messing and the bugs that function introduces.
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH v2] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

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;
+		case 1: /* directly connected device */
+			base = cnspci->cfg0_regs;
+			break;
+		default:
+			return NULL; /* no such device */
+		}
+	} else /* remote PCI bus */
+		base = cnspci->cfg1_regs;
 
-	base = (void __iomem *)cnspci->cfg_bases[type].virtual;
 	offset = ((busno & 0xf) << 20) | (devfn << 12) | (where & 0xffc);
-
 	return base + offset;
 }
 
@@ -180,36 +178,19 @@ static int cns3xxx_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 
 static struct cns3xxx_pcie cns3xxx_pcie[] = {
 	[0] = {
-		.cfg_bases = {
-			[CNS3XXX_HOST_TYPE] = {
-				.virtual = CNS3XXX_PCIE0_HOST_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE0_HOST_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-			[CNS3XXX_CFG0_TYPE] = {
-				.virtual = CNS3XXX_PCIE0_CFG0_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE0_CFG0_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-			[CNS3XXX_CFG1_TYPE] = {
-				.virtual = CNS3XXX_PCIE0_CFG1_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE0_CFG1_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-		},
+		.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,
-			.end = CNS3XXX_PCIE0_IO_BASE + SZ_16M - 1,
+			.end = CNS3XXX_PCIE0_CFG0_BASE - 1, /* 16 MiB */
 			.flags = IORESOURCE_IO,
 		},
 		.res_mem = {
 			.name = "PCIe0 non-prefetchable",
 			.start = CNS3XXX_PCIE0_MEM_BASE,
-			.end = CNS3XXX_PCIE0_MEM_BASE + SZ_16M - 1,
+			.end = CNS3XXX_PCIE0_HOST_BASE - 1, /* 176 MiB */
 			.flags = IORESOURCE_MEM,
 		},
 		.irqs = { IRQ_CNS3XXX_PCIE0_RC, IRQ_CNS3XXX_PCIE0_DEVICE, },
@@ -222,36 +203,19 @@ static struct cns3xxx_pcie cns3xxx_pcie[] = {
 		},
 	},
 	[1] = {
-		.cfg_bases = {
-			[CNS3XXX_HOST_TYPE] = {
-				.virtual = CNS3XXX_PCIE1_HOST_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE1_HOST_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-			[CNS3XXX_CFG0_TYPE] = {
-				.virtual = CNS3XXX_PCIE1_CFG0_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE1_CFG0_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-			[CNS3XXX_CFG1_TYPE] = {
-				.virtual = CNS3XXX_PCIE1_CFG1_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE1_CFG1_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-		},
+		.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,
-			.end = CNS3XXX_PCIE1_IO_BASE + SZ_16M - 1,
+			.end = CNS3XXX_PCIE1_CFG0_BASE - 1, /* 16 MiB */
 			.flags = IORESOURCE_IO,
 		},
 		.res_mem = {
 			.name = "PCIe1 non-prefetchable",
 			.start = CNS3XXX_PCIE1_MEM_BASE,
-			.end = CNS3XXX_PCIE1_MEM_BASE + SZ_16M - 1,
+			.end = CNS3XXX_PCIE1_HOST_BASE - 1, /* 176 MiB */
 			.flags = IORESOURCE_MEM,
 		},
 		.irqs = { IRQ_CNS3XXX_PCIE1_RC, IRQ_CNS3XXX_PCIE1_DEVICE, },
@@ -307,18 +271,15 @@ static void __init cns3xxx_pcie_hw_init(struct cns3xxx_pcie *cnspci)
 		.ops = &cns3xxx_pcie_ops,
 		.sysdata = &sd,
 	};
-	u32 io_base = cnspci->res_io.start >> 16;
-	u32 mem_base = cnspci->res_mem.start >> 16;
-	u32 host_base = cnspci->cfg_bases[CNS3XXX_HOST_TYPE].pfn;
-	u32 cfg0_base = cnspci->cfg_bases[CNS3XXX_CFG0_TYPE].pfn;
+	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;
 	u32 devfn = 0;
 	u8 tmp8;
 	u16 pos;
 	u16 dc;
 
-	host_base = (__pfn_to_phys(host_base) - 1) >> 16;
-	cfg0_base = (__pfn_to_phys(cfg0_base) - 1) >> 16;
-
 	pci_bus_write_config_byte(&bus, devfn, PCI_PRIMARY_BUS, 0);
 	pci_bus_write_config_byte(&bus, devfn, PCI_SECONDARY_BUS, 1);
 	pci_bus_write_config_byte(&bus, devfn, PCI_SUBORDINATE_BUS, 1);
@@ -328,9 +289,9 @@ static void __init cns3xxx_pcie_hw_init(struct cns3xxx_pcie *cnspci)
 	pci_bus_read_config_byte(&bus, devfn, PCI_SUBORDINATE_BUS, &tmp8);
 
 	pci_bus_write_config_word(&bus, devfn, PCI_MEMORY_BASE, mem_base);
-	pci_bus_write_config_word(&bus, devfn, PCI_MEMORY_LIMIT, host_base);
+	pci_bus_write_config_word(&bus, devfn, PCI_MEMORY_LIMIT, mem_limit);
 	pci_bus_write_config_word(&bus, devfn, PCI_IO_BASE_UPPER16, io_base);
-	pci_bus_write_config_word(&bus, devfn, PCI_IO_LIMIT_UPPER16, cfg0_base);
+	pci_bus_write_config_word(&bus, devfn, PCI_IO_LIMIT_UPPER16, io_limit);
 
 	if (!cnspci->linked)
 		return;
@@ -368,8 +329,6 @@ static int __init cns3xxx_pcie_init(void)
 			"imprecise external abort");
 
 	for (i = 0; i < ARRAY_SIZE(cns3xxx_pcie); i++) {
-		iotable_init(cns3xxx_pcie[i].cfg_bases,
-			     ARRAY_SIZE(cns3xxx_pcie[i].cfg_bases));
 		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]);

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH v2] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

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;
+		case 1: /* directly connected device */
+			base = cnspci->cfg0_regs;
+			break;
+		default:
+			return NULL; /* no such device */
+		}
+	} else /* remote PCI bus */
+		base = cnspci->cfg1_regs;
 
-	base = (void __iomem *)cnspci->cfg_bases[type].virtual;
 	offset = ((busno & 0xf) << 20) | (devfn << 12) | (where & 0xffc);
-
 	return base + offset;
 }
 
@@ -180,36 +178,19 @@ static int cns3xxx_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 
 static struct cns3xxx_pcie cns3xxx_pcie[] = {
 	[0] = {
-		.cfg_bases = {
-			[CNS3XXX_HOST_TYPE] = {
-				.virtual = CNS3XXX_PCIE0_HOST_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE0_HOST_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-			[CNS3XXX_CFG0_TYPE] = {
-				.virtual = CNS3XXX_PCIE0_CFG0_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE0_CFG0_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-			[CNS3XXX_CFG1_TYPE] = {
-				.virtual = CNS3XXX_PCIE0_CFG1_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE0_CFG1_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-		},
+		.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,
-			.end = CNS3XXX_PCIE0_IO_BASE + SZ_16M - 1,
+			.end = CNS3XXX_PCIE0_CFG0_BASE - 1, /* 16 MiB */
 			.flags = IORESOURCE_IO,
 		},
 		.res_mem = {
 			.name = "PCIe0 non-prefetchable",
 			.start = CNS3XXX_PCIE0_MEM_BASE,
-			.end = CNS3XXX_PCIE0_MEM_BASE + SZ_16M - 1,
+			.end = CNS3XXX_PCIE0_HOST_BASE - 1, /* 176 MiB */
 			.flags = IORESOURCE_MEM,
 		},
 		.irqs = { IRQ_CNS3XXX_PCIE0_RC, IRQ_CNS3XXX_PCIE0_DEVICE, },
@@ -222,36 +203,19 @@ static struct cns3xxx_pcie cns3xxx_pcie[] = {
 		},
 	},
 	[1] = {
-		.cfg_bases = {
-			[CNS3XXX_HOST_TYPE] = {
-				.virtual = CNS3XXX_PCIE1_HOST_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE1_HOST_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-			[CNS3XXX_CFG0_TYPE] = {
-				.virtual = CNS3XXX_PCIE1_CFG0_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE1_CFG0_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-			[CNS3XXX_CFG1_TYPE] = {
-				.virtual = CNS3XXX_PCIE1_CFG1_BASE_VIRT,
-				.pfn = __phys_to_pfn(CNS3XXX_PCIE1_CFG1_BASE),
-				.length = SZ_16M,
-				.type = MT_DEVICE,
-			},
-		},
+		.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,
-			.end = CNS3XXX_PCIE1_IO_BASE + SZ_16M - 1,
+			.end = CNS3XXX_PCIE1_CFG0_BASE - 1, /* 16 MiB */
 			.flags = IORESOURCE_IO,
 		},
 		.res_mem = {
 			.name = "PCIe1 non-prefetchable",
 			.start = CNS3XXX_PCIE1_MEM_BASE,
-			.end = CNS3XXX_PCIE1_MEM_BASE + SZ_16M - 1,
+			.end = CNS3XXX_PCIE1_HOST_BASE - 1, /* 176 MiB */
 			.flags = IORESOURCE_MEM,
 		},
 		.irqs = { IRQ_CNS3XXX_PCIE1_RC, IRQ_CNS3XXX_PCIE1_DEVICE, },
@@ -307,18 +271,15 @@ static void __init cns3xxx_pcie_hw_init(struct cns3xxx_pcie *cnspci)
 		.ops = &cns3xxx_pcie_ops,
 		.sysdata = &sd,
 	};
-	u32 io_base = cnspci->res_io.start >> 16;
-	u32 mem_base = cnspci->res_mem.start >> 16;
-	u32 host_base = cnspci->cfg_bases[CNS3XXX_HOST_TYPE].pfn;
-	u32 cfg0_base = cnspci->cfg_bases[CNS3XXX_CFG0_TYPE].pfn;
+	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;
 	u32 devfn = 0;
 	u8 tmp8;
 	u16 pos;
 	u16 dc;
 
-	host_base = (__pfn_to_phys(host_base) - 1) >> 16;
-	cfg0_base = (__pfn_to_phys(cfg0_base) - 1) >> 16;
-
 	pci_bus_write_config_byte(&bus, devfn, PCI_PRIMARY_BUS, 0);
 	pci_bus_write_config_byte(&bus, devfn, PCI_SECONDARY_BUS, 1);
 	pci_bus_write_config_byte(&bus, devfn, PCI_SUBORDINATE_BUS, 1);
@@ -328,9 +289,9 @@ static void __init cns3xxx_pcie_hw_init(struct cns3xxx_pcie *cnspci)
 	pci_bus_read_config_byte(&bus, devfn, PCI_SUBORDINATE_BUS, &tmp8);
 
 	pci_bus_write_config_word(&bus, devfn, PCI_MEMORY_BASE, mem_base);
-	pci_bus_write_config_word(&bus, devfn, PCI_MEMORY_LIMIT, host_base);
+	pci_bus_write_config_word(&bus, devfn, PCI_MEMORY_LIMIT, mem_limit);
 	pci_bus_write_config_word(&bus, devfn, PCI_IO_BASE_UPPER16, io_base);
-	pci_bus_write_config_word(&bus, devfn, PCI_IO_LIMIT_UPPER16, cfg0_base);
+	pci_bus_write_config_word(&bus, devfn, PCI_IO_LIMIT_UPPER16, io_limit);
 
 	if (!cnspci->linked)
 		return;
@@ -368,8 +329,6 @@ static int __init cns3xxx_pcie_init(void)
 			"imprecise external abort");
 
 	for (i = 0; i < ARRAY_SIZE(cns3xxx_pcie); i++) {
-		iotable_init(cns3xxx_pcie[i].cfg_bases,
-			     ARRAY_SIZE(cns3xxx_pcie[i].cfg_bases));
 		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]);

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH v2] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

khalasa@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 <khalasa@piap.pl>

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH v2] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

khalasa at 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 <khalasa@piap.pl>

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH2] CNS3xxx: Fix a WARN() related to IRQ allocation.

[Krzysztof Hałasa]

WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
Backtrace:
gic_init_bases    from cns3xxx_init_irq+0x24/0x34
cns3xxx_init_irq  from init_IRQ+0x24/0x2c
init_IRQ          from start_kernel+0x1a8/0x338
start_kernel      from 0x2000806c

The problem is that 64 CNS3xxx CPU interrupts, starting at 32, are
allocated by the ARM platform-independent code (as requested by
machine_desc->nr_irqs = 96), and then the GIC code tries to allocate
them again.

Tested on Gateworks Laguna board, masqueraded as CNS3420VB.

Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH2] CNS3xxx: Fix a WARN() related to IRQ allocation.

[Krzysztof Hałasa]

WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
Backtrace:
gic_init_bases    from cns3xxx_init_irq+0x24/0x34
cns3xxx_init_irq  from init_IRQ+0x24/0x2c
init_IRQ          from start_kernel+0x1a8/0x338
start_kernel      from 0x2000806c

The problem is that 64 CNS3xxx CPU interrupts, starting at 32, are
allocated by the ARM platform-independent code (as requested by
machine_desc->nr_irqs = 96), and then the GIC code tries to allocate
them again.

Tested on Gateworks Laguna board, masqueraded as CNS3420VB.

Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl>
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH2] CNS3xxx: Fix a WARN() related to IRQ allocation.

[Krzysztof Hałasa]

WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
Backtrace:
gic_init_bases    from cns3xxx_init_irq+0x24/0x34
cns3xxx_init_irq  from init_IRQ+0x24/0x2c
init_IRQ          from start_kernel+0x1a8/0x338
start_kernel      from 0x2000806c

The problem is that 64 CNS3xxx CPU interrupts, starting at 32, are
allocated by the ARM platform-independent code (as requested by
machine_desc->nr_irqs = 96), and then the GIC code tries to allocate
them again.

Tested on Gateworks Laguna board, masqueraded as CNS3420VB.

Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>

--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -246,7 +246,6 @@ static void __init cns3420_map_io(void)
 
 MACHINE_START(CNS3420VB, "Cavium Networks CNS3420 Validation Board")
 	.atag_offset	= 0x100,
-	.nr_irqs	= NR_IRQS_CNS3XXX,
 	.map_io		= cns3420_map_io,
 	.init_irq	= cns3xxx_init_irq,
 	.init_time	= cns3xxx_timer_init,
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -400,7 +400,6 @@ static const char *cns3xxx_dt_compat[] __initdata = {
 
 DT_MACHINE_START(CNS3XXX_DT, "Cavium Networks CNS3xxx")
 	.dt_compat	= cns3xxx_dt_compat,
-	.nr_irqs	= NR_IRQS_CNS3XXX,
 	.map_io		= cns3xxx_map_io,
 	.init_irq	= cns3xxx_init_irq,
 	.init_time	= cns3xxx_timer_init,

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH2] CNS3xxx: Fix a WARN() related to IRQ allocation.

[Krzysztof Hałasa]

WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
Backtrace:
gic_init_bases    from cns3xxx_init_irq+0x24/0x34
cns3xxx_init_irq  from init_IRQ+0x24/0x2c
init_IRQ          from start_kernel+0x1a8/0x338
start_kernel      from 0x2000806c

The problem is that 64 CNS3xxx CPU interrupts, starting at 32, are
allocated by the ARM platform-independent code (as requested by
machine_desc->nr_irqs = 96), and then the GIC code tries to allocate
them again.

Tested on Gateworks Laguna board, masqueraded as CNS3420VB.

Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl>

--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -246,7 +246,6 @@ static void __init cns3420_map_io(void)
 
 MACHINE_START(CNS3420VB, "Cavium Networks CNS3420 Validation Board")
 	.atag_offset	= 0x100,
-	.nr_irqs	= NR_IRQS_CNS3XXX,
 	.map_io		= cns3420_map_io,
 	.init_irq	= cns3xxx_init_irq,
 	.init_time	= cns3xxx_timer_init,
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -400,7 +400,6 @@ static const char *cns3xxx_dt_compat[] __initdata = {
 
 DT_MACHINE_START(CNS3XXX_DT, "Cavium Networks CNS3xxx")
 	.dt_compat	= cns3xxx_dt_compat,
-	.nr_irqs	= NR_IRQS_CNS3XXX,
 	.map_io		= cns3xxx_map_io,
 	.init_irq	= cns3xxx_init_irq,
 	.init_time	= cns3xxx_timer_init,

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH2] CNS3xxx: Fix a WARN() related to IRQ allocation.

[Arnd Bergmann]

On Tuesday 04 March 2014, Krzysztof Hałasa wrote:
> WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
> Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
> Backtrace:
> gic_init_bases    from cns3xxx_init_irq+0x24/0x34
> cns3xxx_init_irq  from init_IRQ+0x24/0x2c
> init_IRQ          from start_kernel+0x1a8/0x338
> start_kernel      from 0x2000806c
> 
> The problem is that 64 CNS3xxx CPU interrupts, starting at 32, are
> allocated by the ARM platform-independent code (as requested by
> machine_desc->nr_irqs = 96), and then the GIC code tries to allocate
> them again.
> 
> Tested on Gateworks Laguna board, masqueraded as CNS3420VB.
> 
> Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>

Applied to next/fixes-non-critical.

	Arnd

> --- a/arch/arm/mach-cns3xxx/cns3420vb.c
> +++ b/arch/arm/mach-cns3xxx/cns3420vb.c
> @@ -246,7 +246,6 @@ static void __init cns3420_map_io(void)
>  
>  MACHINE_START(CNS3420VB, "Cavium Networks CNS3420 Validation Board")
>         .atag_offset    = 0x100,
> -       .nr_irqs        = NR_IRQS_CNS3XXX,
>         .map_io         = cns3420_map_io,
>         .init_irq       = cns3xxx_init_irq,
>         .init_time      = cns3xxx_timer_init,
> --- a/arch/arm/mach-cns3xxx/core.c
> +++ b/arch/arm/mach-cns3xxx/core.c
> @@ -400,7 +400,6 @@ static const char *cns3xxx_dt_compat[] __initdata = {
>  
>  DT_MACHINE_START(CNS3XXX_DT, "Cavium Networks CNS3xxx")
>         .dt_compat      = cns3xxx_dt_compat,
> -       .nr_irqs        = NR_IRQS_CNS3XXX,
>         .map_io         = cns3xxx_map_io,
>         .init_irq       = cns3xxx_init_irq,
>         .init_time      = cns3xxx_timer_init,

[PATCH2] CNS3xxx: Fix a WARN() related to IRQ allocation.

[Arnd Bergmann]

On Tuesday 04 March 2014, Krzysztof Ha?asa wrote:
> WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
> Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
> Backtrace:
> gic_init_bases    from cns3xxx_init_irq+0x24/0x34
> cns3xxx_init_irq  from init_IRQ+0x24/0x2c
> init_IRQ          from start_kernel+0x1a8/0x338
> start_kernel      from 0x2000806c
> 
> The problem is that 64 CNS3xxx CPU interrupts, starting at 32, are
> allocated by the ARM platform-independent code (as requested by
> machine_desc->nr_irqs = 96), and then the GIC code tries to allocate
> them again.
> 
> Tested on Gateworks Laguna board, masqueraded as CNS3420VB.
> 
> Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl>

Applied to next/fixes-non-critical.

	Arnd

> --- a/arch/arm/mach-cns3xxx/cns3420vb.c
> +++ b/arch/arm/mach-cns3xxx/cns3420vb.c
> @@ -246,7 +246,6 @@ static void __init cns3420_map_io(void)
>  
>  MACHINE_START(CNS3420VB, "Cavium Networks CNS3420 Validation Board")
>         .atag_offset    = 0x100,
> -       .nr_irqs        = NR_IRQS_CNS3XXX,
>         .map_io         = cns3420_map_io,
>         .init_irq       = cns3xxx_init_irq,
>         .init_time      = cns3xxx_timer_init,
> --- a/arch/arm/mach-cns3xxx/core.c
> +++ b/arch/arm/mach-cns3xxx/core.c
> @@ -400,7 +400,6 @@ static const char *cns3xxx_dt_compat[] __initdata = {
>  
>  DT_MACHINE_START(CNS3XXX_DT, "Cavium Networks CNS3xxx")
>         .dt_compat      = cns3xxx_dt_compat,
> -       .nr_irqs        = NR_IRQS_CNS3XXX,
>         .map_io         = cns3xxx_map_io,
>         .init_irq       = cns3xxx_init_irq,
>         .init_time      = cns3xxx_timer_init,

Re: [PATCH v2] CNS3xxx: Fix PCIe early iotable_init().

[Arnd Bergmann]

On Tuesday 04 March 2014, Krzysztof Hałasa wrote:
> khalasa@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 <khalasa@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
arm@kernel.org to Cc, so we don't miss it.

Thanks,

	Arnd

[PATCH v2] CNS3xxx: Fix PCIe early iotable_init().

[Arnd Bergmann]

On Tuesday 04 March 2014, Krzysztof Ha?asa wrote:
> khalasa at 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 <khalasa@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
arm at kernel.org to Cc, so we don't miss it.

Thanks,

	Arnd

Re: [PATCH v2] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

Arnd Bergmann <arnd@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

[PATCH v2] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

Arnd Bergmann <arnd@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