summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-ixp4xx/include/mach/io.h
Commit message (Collapse)AuthorAgeFilesLines
* ARM: io: make iounmap() a simple macroRussell King2010-12-081-2/+2
| | | | | | | | | | Defining iounmap() with arguments prevents it from being used as a function pointer, causing platforms to work around this. Instead, define it to be a simple macro. Do the same for __arch_io(re|un)map too. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* IXP4xx: Fix sparse warnings in I/O primitives.Krzysztof Hałasa2010-05-271-3/+3
| | | | Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* IXP4xx: Extend PCI MMIO indirect address space to 1 GB.Krzysztof Hałasa2009-12-051-12/+10
| | | | | | | | | IXP4xx CPUs can indirectly access the whole 4 GB PCI MMIO address space (using the non-prefetch registers). Previously the available space depended on the CPU variant, since one of the IXP43x platforms needed more than the usual 128 MB. 1 GB should be enough for everyone, and if not, we can trivially increase it. Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* IXP4xx: Fix compilation failure with CONFIG_IXP4XX_INDIRECT_PCI.Krzysztof Hałasa2009-12-051-8/+15
| | | | | | | | Instead of including the heavy linux/mm.h for VMALLOC_START, test the addresses against PCI MIN and MAX addresses. Indirect PCI uses 1:1 mapping for MMIO space making this change possible. Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* IXP4xx: Drop "__ixp4xx_" prefix from in/out/ioread/iowrite functions for ↵Krzysztof Hałasa2009-12-051-95/+55
| | | | | | clarity. Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* IXP4xx: Rename indirect MMIO primitives from __ixp4xx_* to __indirect_*.Krzysztof Hałasa2009-12-051-57/+50
| | | | Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* ARM: fix insl() and outsl() endianness on IXP4xx architecture.Krzysztof Hałasa2009-12-051-3/+4
| | | | | | The repetitive in/out functions must preserve order, not value. Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* IXP4xx: Fix IO_SPACE_LIMIT for 2.6.31-rc core PCI changesMikael Pettersson2009-08-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2.6.31-rc kernels don't boot on my ixp4xx box (ds101), because the libata driver doesn't find the PCI IDE controller any more. 2.6.30 was fine. I traced this to a PCI update (1f82de10d6b1d845155363c895c552e61b36b51a) in 2.6.30-git19. Diffing the kernel boot logs from 2.6.30-git18 and 2.6.30-git19 illustrates the breakage: > --- dmesg-2.6.30-git18 2009-08-04 01:45:22.000000000 +0200 > +++ dmesg-2.6.30-git19 2009-08-04 01:45:46.000000000 +0200 > @@ -26,6 +26,13 @@ > pci 0000:00:02.2: PME# supported from D0 D1 D2 D3hot > pci 0000:00:02.2: PME# disabled > PCI: bus0: Fast back to back transfers disabled > +pci 0000:00:01.0: BAR 0: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:01.0: BAR 1: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:01.0: BAR 2: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:01.0: BAR 3: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:01.0: BAR 4: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:02.0: BAR 4: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:02.1: BAR 4: can't allocate I/O resource [0x10000-0xffff] > bio: create slab <bio-0> at 0 > SCSI subsystem initialized > NET: Registered protocol family 2 > @@ -44,11 +51,7 @@ > console [ttyS0] enabled > serial8250.0: ttyS1 at MMIO 0xc8001000 (irq = 13) is a XScale > Driver 'sd' needs updating - please use bus_type methods > -PCI: enabling device 0000:00:01.0 (0140 -> 0141) > -scsi0 : pata_artop > -scsi1 : pata_artop > -ata1: PATA max UDMA/100 cmd 0x1050 ctl 0x1060 bmdma 0x1040 irq 28 > -ata2: PATA max UDMA/100 cmd 0x1058 ctl 0x1064 bmdma 0x1048 irq 28 > +pata_artop 0000:00:01.0: no available native port > Using configured DiskOnChip probe address 0x50000000 > DiskOnChip found at 0x50000000 > NAND device: Manufacturer ID: 0x98, Chip ID: 0x73 (Toshiba NAND 16MiB 3,3V 8-bit) The specific change in 1f82de10d6b1d845155363c895c552e61b36b51a responsible for this failure turned out to be the following: > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -193,7 +193,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, > res->flags |= pci_calc_resource_flags(l) | IORESOURCE_SIZEALIGN; > if (type == pci_bar_io) { > l &= PCI_BASE_ADDRESS_IO_MASK; > - mask = PCI_BASE_ADDRESS_IO_MASK & 0xffff; > + mask = PCI_BASE_ADDRESS_IO_MASK & IO_SPACE_LIMIT; > } else { > l &= PCI_BASE_ADDRESS_MEM_MASK; > mask = (u32)PCI_BASE_ADDRESS_MEM_MASK; Every arch except arm's ixp4xx defines IO_SPACE_LIMIT as an all-bits-one bitmask, typically -1UL but sometimes only a 16-bit 0x0000ffff. But ixp4xx defines it as 0xffff0000, which is now causing the PCI failures. Russell King noted that ixp4xx has 64KB PCI IO space, so IO_SPACE_LIMIT should be 0x0000ffff. This patch makes that change, which fixes the PCI failures on my ixp4xx box. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* [ARM] Add a common typesafe __io implementationRussell King2008-11-301-1/+1
| | | | | | | | As Al did for Versatile in 2ad4f86b60b649fd7428265c08d73a3bd360c81b, add a typesafe __io implementation for platforms to use. Convert platforms to use this new simple typesafe implementation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] ixp4xx: clean up includesRussell King2008-11-281-2/+0
| | | | | | | mach/io.h doesn't need linux/mm.h. mach/dma.h doesn't need linux/device.h, asm/page.h or mach/hardware.h Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Move include/asm-arm/arch-* to arch/arm/*/include/machRussell King2008-08-071-0/+569
This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>