| Message ID | 1342231451-28861-6-git-send-email-robherring2@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Jul 14, 2012 at 4:04 AM, Rob Herring <robherring2@gmail.com> wrote: > From: Rob Herring <rob.herring@calxeda.com> > > Move integrator PCI to fixed i/o mapping and remove io.h. > > Signed-off-by: Rob Herring <rob.herring@calxeda.com> > Cc: Russell King <linux@arm.linux.org.uk> > Cc: Linus Walleij <linus.walleij@linaro.org> I think the PCI bus on my Integrator/AP is tilted and not suitable for tests. But IIRC Will Deacon actually has one of these machines and managed to get ethernet going on it. Maybe he can even test this patch? Yours, Linus Walleij
On Sat, Jul 14, 2012 at 10:49:47PM +0100, Linus Walleij wrote: > On Sat, Jul 14, 2012 at 4:04 AM, Rob Herring <robherring2@gmail.com> wrote: > > > From: Rob Herring <rob.herring@calxeda.com> > > > > Move integrator PCI to fixed i/o mapping and remove io.h. > > > > Signed-off-by: Rob Herring <rob.herring@calxeda.com> > > Cc: Russell King <linux@arm.linux.org.uk> > > Cc: Linus Walleij <linus.walleij@linaro.org> > > I think the PCI bus on my Integrator/AP is tilted and not suitable > for tests. But IIRC Will Deacon actually has one of these machines > and managed to get ethernet going on it. Maybe he can even test > this patch? I can try digging out my integrator at the weekend if you like. Are these patches sitting in a branch anywhere that I can grab? Will
On 07/17/2012 12:04 PM, Will Deacon wrote: > On Sat, Jul 14, 2012 at 10:49:47PM +0100, Linus Walleij wrote: >> On Sat, Jul 14, 2012 at 4:04 AM, Rob Herring <robherring2@gmail.com> wrote: >> >>> From: Rob Herring <rob.herring@calxeda.com> >>> >>> Move integrator PCI to fixed i/o mapping and remove io.h. >>> >>> Signed-off-by: Rob Herring <rob.herring@calxeda.com> >>> Cc: Russell King <linux@arm.linux.org.uk> >>> Cc: Linus Walleij <linus.walleij@linaro.org> >> >> I think the PCI bus on my Integrator/AP is tilted and not suitable >> for tests. But IIRC Will Deacon actually has one of these machines >> and managed to get ethernet going on it. Maybe he can even test >> this patch? > > I can try digging out my integrator at the weekend if you like. Are these > patches sitting in a branch anywhere that I can grab? > git://sources.calxeda.com/kernel/linux.git io-cleanup-pci Rob
Hi Rob, On Tue, Jul 17, 2012 at 07:02:12PM +0100, Rob Herring wrote: > On 07/17/2012 12:04 PM, Will Deacon wrote: > > On Sat, Jul 14, 2012 at 10:49:47PM +0100, Linus Walleij wrote: > >> I think the PCI bus on my Integrator/AP is tilted and not suitable > >> for tests. But IIRC Will Deacon actually has one of these machines > >> and managed to get ethernet going on it. Maybe he can even test > >> this patch? > > > > I can try digging out my integrator at the weekend if you like. Are these > > patches sitting in a branch anywhere that I can grab? > > > > git://sources.calxeda.com/kernel/linux.git io-cleanup-pci I dusted off the integrator, but I'm failing to boot at all if I build from that branch: Uncompressing Linux... done, booting the kernel. <silence> Using the same .config, I can boot v3.5-rc7 just fine (I even rebased your branch onto that in case something had been fixed in mainline, but it made no difference). Will
On Saturday 21 July 2012, Will Deacon wrote: > Hi Rob, > > On Tue, Jul 17, 2012 at 07:02:12PM +0100, Rob Herring wrote: > > On 07/17/2012 12:04 PM, Will Deacon wrote: > > > On Sat, Jul 14, 2012 at 10:49:47PM +0100, Linus Walleij wrote: > > >> I think the PCI bus on my Integrator/AP is tilted and not suitable > > >> for tests. But IIRC Will Deacon actually has one of these machines > > >> and managed to get ethernet going on it. Maybe he can even test > > >> this patch? > > > > > > I can try digging out my integrator at the weekend if you like. Are these > > > patches sitting in a branch anywhere that I can grab? > > > > > > > git://sources.calxeda.com/kernel/linux.git io-cleanup-pci > > I dusted off the integrator, but I'm failing to boot at all if I build from > that branch: > > Uncompressing Linux... done, booting the kernel. > <silence> > > Using the same .config, I can boot v3.5-rc7 just fine (I even rebased your > branch onto that in case something had been fixed in mainline, but it made > no difference). I've looked at integrator_defconfig, and could not find any code that actually uses the PIO accessors. Is your configuration different to that? Do you actually have PCI enabled and present on the machine? Do things change if you turn PCI off? Arnd
On Jul 21, 2012 5:56 PM, "Arnd Bergmann" <arnd@arndb.de> wrote: > > On Saturday 21 July 2012, Will Deacon wrote: > > Hi Rob, > > > > On Tue, Jul 17, 2012 at 07:02:12PM +0100, Rob Herring wrote: > > > On 07/17/2012 12:04 PM, Will Deacon wrote: > > > > On Sat, Jul 14, 2012 at 10:49:47PM +0100, Linus Walleij wrote: > > > >> I think the PCI bus on my Integrator/AP is tilted and not suitable > > > >> for tests. But IIRC Will Deacon actually has one of these machines > > > >> and managed to get ethernet going on it. Maybe he can even test > > > >> this patch? > > > > > > > > I can try digging out my integrator at the weekend if you like. Are these > > > > patches sitting in a branch anywhere that I can grab? > > > > > > > > > > git://sources.calxeda.com/kernel/linux.git io-cleanup-pci > > > > I dusted off the integrator, but I'm failing to boot at all if I build from > > that branch: > > > > Uncompressing Linux... done, booting the kernel. > > <silence> > > > > Using the same .config, I can boot v3.5-rc7 just fine (I even rebased your > > branch onto that in case something had been fixed in mainline, but it made > > no difference). > > I've looked at integrator_defconfig, and could not find any code that > actually uses the PIO accessors. Is your configuration different to that? > Do you actually have PCI enabled and present on the machine? Do things > change if you turn PCI off? > Could be overlapping static mappings. I manually checked that, but may have missed something. Can you turn on earlyprintk? Rob
On Sun, Jul 22, 2012 at 02:09:23PM +0100, Rob Herring wrote: > On Jul 21, 2012 5:56 PM, "Arnd Bergmann" <arnd@arndb.de<mailto:arnd@arndb.de>> wrote: > > On Saturday 21 July 2012, Will Deacon wrote: > > > I dusted off the integrator, but I'm failing to boot at all if I build from > > > that branch: > > > > > > Uncompressing Linux... done, booting the kernel. > > > <silence> > > > > > > Using the same .config, I can boot v3.5-rc7 just fine (I even rebased your > > > branch onto that in case something had been fixed in mainline, but it made > > > no difference). > > > > I've looked at integrator_defconfig, and could not find any code that > > actually uses the PIO accessors. Is your configuration different to that? > > Do you actually have PCI enabled and present on the machine? Do things > > change if you turn PCI off? I have PCI up and running, yes, but all I use it for is an Intel e100 ethernet card which isn't required for booting. Disabling PCI makes no difference, but see below. > Could be overlapping static mappings. I manually checked that, but may have missed something. > > Can you turn on earlyprintk? I had that turned on already... after banging my head against a wall, I realised that increasing the baudrate in u-boot (I have to use ymodem to transfer the kernel image...) kills the serial console completely when booting Linux if I forget to change it back. With that observation, I see booting get stuck: Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0 [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.5.0-rc6-00017-g52f1412 (will@tiny-lites) (gcc version 4.5.3 (Gent2 [ 0.000000] CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177 [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] Machine: ARM-Integrator [ 0.000000] bootconsole [earlycon0] enabled [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] On node 0 totalpages: 32768 [ 0.000000] free_area_init_node: node 0, pgdat c04ad1f0, node_mem_map c04c9000 [ 0.000000] Normal zone: 256 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 32512 pages, LIFO batch:7 [ 0.000000] CPU: found DTCM0 32k @ 00000000, not enabled [ 0.000000] CPU: moved DTCM0 32k to fffe8000, enabled [ 0.000000] CPU: found ITCM0 32k @ 00000000, not enabled [ 0.000000] CPU: moved ITCM0 32k to fffe0000, enabled [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [ 0.000000] Kernel command line: console=ttyAM0 mem=128M earlyprintk debug user_debug=31 logl9 [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Memory: 128MB = 128MB total [ 0.000000] Memory: 124968k/124968k available, 6104k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] DTCM : 0xfffe8000 - 0xffff0000 ( 32 kB) [ 0.000000] ITCM : 0xfffe0000 - 0xfffe8000 ( 32 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) [ 0.000000] .text : 0xc0008000 - 0xc036e9b0 (3483 kB) [ 0.000000] .init : 0xc036f000 - 0xc048e7a4 (1150 kB) [ 0.000000] .data : 0xc0490000 - 0xc04ad920 ( 119 kB) [ 0.000000] .bss : 0xc04ae024 - 0xc04c86b4 ( 106 kB) [ 0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:16 nr_irqs:34 34 [ 0.000000] FPGA IRQ chip 0 "SC" @ f1400000, 22 irqs [ 0.000000] sched_clock: 16 bits at 1500kHz, resolution 666ns, wraps every 43ms Now, the next line is usually when the VGA text console is poked. Sure enough, disabling that (CONFIG_VGA_CONSOLE) is enough to boot with your patches and PCI appears to work correctly (I can do basic networking). I guess there's some mapping race with the VGA code since vga_base = PCI_MEMORY_VADDR, but you left the static mapping alone for that region, so I'm not sure. Any ideas? Will
On Jul 22, 2012 11:08 AM, "Will Deacon" <will.deacon@arm.com> wrote: > > On Sun, Jul 22, 2012 at 02:09:23PM +0100, Rob Herring wrote: > > On Jul 21, 2012 5:56 PM, "Arnd Bergmann" <arnd@arndb.de<mailto: arnd@arndb.de>> wrote: > > > On Saturday 21 July 2012, Will Deacon wrote: > > > > I dusted off the integrator, but I'm failing to boot at all if I build from > > > > that branch: > > > > > > > > Uncompressing Linux... done, booting the kernel. > > > > <silence> > > > > > > > > Using the same .config, I can boot v3.5-rc7 just fine (I even rebased your > > > > branch onto that in case something had been fixed in mainline, but it made > > > > no difference). > > > > > > I've looked at integrator_defconfig, and could not find any code that > > > actually uses the PIO accessors. Is your configuration different to that? > > > Do you actually have PCI enabled and present on the machine? Do things > > > change if you turn PCI off? > > I have PCI up and running, yes, but all I use it for is an Intel e100 > ethernet card which isn't required for booting. Disabling PCI makes no > difference, but see below. > > > Could be overlapping static mappings. I manually checked that, but may have missed something. > > > > Can you turn on earlyprintk? > > I had that turned on already... after banging my head against a wall, I > realised that increasing the baudrate in u-boot (I have to use ymodem to > transfer the kernel image...) kills the serial console completely when > booting Linux if I forget to change it back. > > With that observation, I see booting get stuck: > > > Uncompressing Linux... done, booting the kernel. > [ 0.000000] Booting Linux on physical CPU 0 > [ 0.000000] Initializing cgroup subsys cpu > [ 0.000000] Linux version 3.5.0-rc6-00017-g52f1412 (will@tiny-lites) (gcc version 4.5.3 (Gent2 > [ 0.000000] CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177 > [ 0.000000] CPU: VIVT data cache, VIVT instruction cache > [ 0.000000] Machine: ARM-Integrator > [ 0.000000] bootconsole [earlycon0] enabled > [ 0.000000] Memory policy: ECC disabled, Data cache writeback > [ 0.000000] On node 0 totalpages: 32768 > [ 0.000000] free_area_init_node: node 0, pgdat c04ad1f0, node_mem_map c04c9000 > [ 0.000000] Normal zone: 256 pages used for memmap > [ 0.000000] Normal zone: 0 pages reserved > [ 0.000000] Normal zone: 32512 pages, LIFO batch:7 > [ 0.000000] CPU: found DTCM0 32k @ 00000000, not enabled > [ 0.000000] CPU: moved DTCM0 32k to fffe8000, enabled > [ 0.000000] CPU: found ITCM0 32k @ 00000000, not enabled > [ 0.000000] CPU: moved ITCM0 32k to fffe0000, enabled > [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 > [ 0.000000] pcpu-alloc: [0] 0 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 > [ 0.000000] Kernel command line: console=ttyAM0 mem=128M earlyprintk debug user_debug=31 logl9 > [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) > [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) > [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) > [ 0.000000] Memory: 128MB = 128MB total > [ 0.000000] Memory: 124968k/124968k available, 6104k reserved, 0K highmem > [ 0.000000] Virtual kernel memory layout: > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > [ 0.000000] DTCM : 0xfffe8000 - 0xffff0000 ( 32 kB) > [ 0.000000] ITCM : 0xfffe0000 - 0xfffe8000 ( 32 kB) > [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) > [ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB) > [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) > [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) > [ 0.000000] .text : 0xc0008000 - 0xc036e9b0 (3483 kB) > [ 0.000000] .init : 0xc036f000 - 0xc048e7a4 (1150 kB) > [ 0.000000] .data : 0xc0490000 - 0xc04ad920 ( 119 kB) > [ 0.000000] .bss : 0xc04ae024 - 0xc04c86b4 ( 106 kB) > [ 0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > [ 0.000000] NR_IRQS:16 nr_irqs:34 34 > [ 0.000000] FPGA IRQ chip 0 "SC" @ f1400000, 22 irqs > [ 0.000000] sched_clock: 16 bits at 1500kHz, resolution 666ns, wraps every 43ms > > > Now, the next line is usually when the VGA text console is poked. Sure > enough, disabling that (CONFIG_VGA_CONSOLE) is enough to boot with your > patches and PCI appears to work correctly (I can do basic networking). > > I guess there's some mapping race with the VGA code since vga_base = > PCI_MEMORY_VADDR, but you left the static mapping alone for that region, > so I'm not sure. Any ideas? Perhaps pcibios_min_io changing from 6000 to default of 1000 causes probing for vga? Rob
On Sun, Jul 22, 2012 at 05:21:33PM +0100, Rob Herring wrote: > On Jul 22, 2012 11:08 AM, "Will Deacon" <will.deacon@arm.com<mailto:will.deacon@arm.com>> wrote: > > Now, the next line is usually when the VGA text console is poked. Sure > > enough, disabling that (CONFIG_VGA_CONSOLE) is enough to boot with your > > patches and PCI appears to work correctly (I can do basic networking). > > > > I guess there's some mapping race with the VGA code since vga_base = > > PCI_MEMORY_VADDR, but you left the static mapping alone for that region, > > so I'm not sure. Any ideas? > > Perhaps pcibios_min_io changing from 6000 to default of 1000 causes probing for vga? I can try changing it back and see it makes a difference sometime this week. It certainly smells like some probing is going on before the PCI stuff is up and running and I suspect that the static mapping just leads to a hang rather than an abort. Will
On 07/23/2012 07:19 AM, Will Deacon wrote: > On Sun, Jul 22, 2012 at 05:21:33PM +0100, Rob Herring wrote: >> On Jul 22, 2012 11:08 AM, "Will Deacon" <will.deacon@arm.com<mailto:will.deacon@arm.com>> wrote: >>> Now, the next line is usually when the VGA text console is poked. Sure >>> enough, disabling that (CONFIG_VGA_CONSOLE) is enough to boot with your >>> patches and PCI appears to work correctly (I can do basic networking). >>> >>> I guess there's some mapping race with the VGA code since vga_base = >>> PCI_MEMORY_VADDR, but you left the static mapping alone for that region, >>> so I'm not sure. Any ideas? >> >> Perhaps pcibios_min_io changing from 6000 to default of 1000 causes probing for vga? > > I can try changing it back and see it makes a difference sometime this week. > It certainly smells like some probing is going on before the PCI stuff is up > and running and I suspect that the static mapping just leads to a hang rather > than an abort. Now that I have looked at the code. I think it is simply vgacon is postcore_init and pci setup of the i/o mapping is in subsys_init. It curious that you don't get an abort and backtrace though. vgacon is only enabled for footbridge and integrator. I guess the only way this worked before is if the bootloader has already setup the bus. So I can add back an early mapping function that these 2 platforms can call from .map_io. Something like this: static inline void __init pci_map_io_early(unsigned long pfn) { struct map_desc pci_io_desc = { .virtual = PCI_IO_VIRT_BASE, .type = MT_DEVICE, .length = SZ_64K, }; pci_io_desc.pfn = pfn; create_mapping(&pci_io_desc); } Rob
On Mon, Jul 23, 2012 at 4:05 PM, Rob Herring <robherring2@gmail.com> wrote: > Now that I have looked at the code. I think it is simply vgacon is > postcore_init and pci setup of the i/o mapping is in subsys_init. Makes perfect sense. > It curious that you don't get an abort and backtrace though. I never get that either, it just locks up. Probably some other oddity in these old boards. > vgacon is only enabled for footbridge and integrator. I guess the only > way this worked before is if the bootloader has already setup the bus. Yes that is the case with most of the "V3 PCI" code, without some bootloader or "BIOS" (boot monitor) poking, nothing works. Some of the V3 registers are only just poked once, from the boot monitor or boot loader. > So I can add back an early mapping function that these 2 platforms can > call from .map_io. Something like this: > > static inline void __init pci_map_io_early(unsigned long pfn) > { > struct map_desc pci_io_desc = { > .virtual = PCI_IO_VIRT_BASE, > .type = MT_DEVICE, > .length = SZ_64K, > }; > > pci_io_desc.pfn = pfn; > create_mapping(&pci_io_desc); > } Wouldn't the same kind of thing be necessary for all x86 systems, and for any other ARM system that wants to use a VGA console? How do these system handle it? BTW: in the integrator_defconfig the VGA console is disabled, for the very reason that it tends to lock things up if ther is no graphics card in the machine. Yours, Linus Walleij
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ac446e3..5d37628 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -261,7 +261,6 @@ config ARCH_INTEGRATOR select GENERIC_CLOCKEVENTS select PLAT_VERSATILE select PLAT_VERSATILE_FPGA_IRQ - select NEED_MACH_IO_H select NEED_MACH_MEMORY_H select SPARSE_IRQ select MULTI_IRQ_HANDLER diff --git a/arch/arm/mach-integrator/include/mach/io.h b/arch/arm/mach-integrator/include/mach/io.h deleted file mode 100644 index 8de70de..0000000 --- a/arch/arm/mach-integrator/include/mach/io.h +++ /dev/null @@ -1,33 +0,0 @@ -/* - * arch/arm/mach-integrator/include/mach/io.h - * - * Copyright (C) 1999 ARM Limited - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - */ -#ifndef __ASM_ARM_ARCH_IO_H -#define __ASM_ARM_ARCH_IO_H - -/* - * WARNING: this has to mirror definitions in platform.h - */ -#define PCI_MEMORY_VADDR 0xe8000000 -#define PCI_CONFIG_VADDR 0xec000000 -#define PCI_V3_VADDR 0xed000000 -#define PCI_IO_VADDR 0xee000000 - -#define __io(a) ((void __iomem *)(PCI_IO_VADDR + (a))) - -#endif diff --git a/arch/arm/mach-integrator/include/mach/platform.h b/arch/arm/mach-integrator/include/mach/platform.h index ec467ba..4c03475 100644 --- a/arch/arm/mach-integrator/include/mach/platform.h +++ b/arch/arm/mach-integrator/include/mach/platform.h @@ -324,6 +324,10 @@ */ #define PHYS_PCI_V3_BASE 0x62000000 +#define PCI_MEMORY_VADDR 0xe8000000 +#define PCI_CONFIG_VADDR 0xec000000 +#define PCI_V3_VADDR 0xed000000 + /* ------------------------------------------------------------------------ * Integrator Interrupt Controllers * ------------------------------------------------------------------------ diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c index c857501..83bee54 100644 --- a/arch/arm/mach-integrator/integrator_ap.c +++ b/arch/arm/mach-integrator/integrator_ap.c @@ -72,7 +72,7 @@ * e8000000 40000000 PCI memory PHYS_PCI_MEM_BASE (max 512M) * ec000000 61000000 PCI config space PHYS_PCI_CONFIG_BASE (max 16M) * ed000000 62000000 PCI V3 regs PHYS_PCI_V3_BASE (max 64k) - * ee000000 60000000 PCI IO PHYS_PCI_IO_BASE (max 16M) + * fee00000 60000000 PCI IO PHYS_PCI_IO_BASE (max 16M) * ef000000 Cache flush * f1000000 10000000 Core module registers * f1100000 11000000 System controller registers @@ -146,11 +146,6 @@ static struct map_desc ap_io_desc[] __initdata = { .pfn = __phys_to_pfn(PHYS_PCI_V3_BASE), .length = SZ_64K, .type = MT_DEVICE - }, { - .virtual = PCI_IO_VADDR, - .pfn = __phys_to_pfn(PHYS_PCI_IO_BASE), - .length = SZ_64K, - .type = MT_DEVICE } }; diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c index b866880..810f4ec 100644 --- a/arch/arm/mach-integrator/pci_v3.c +++ b/arch/arm/mach-integrator/pci_v3.c @@ -374,12 +374,9 @@ static int __init pci_v3_setup_resources(struct pci_sys_data *sys) } /* - * the IO resource for this bus * the mem resource for this bus * the prefetch mem resource for this bus */ - pci_add_resource_offset(&sys->resources, - &ioport_resource, sys->io_offset); pci_add_resource_offset(&sys->resources, &non_mem, sys->mem_offset); pci_add_resource_offset(&sys->resources, &pre_mem, sys->mem_offset);