- 05 12月, 2009 1 次提交
-
-
由 Krzysztof Hałasa 提交于
The repetitive in/out functions must preserve order, not value. Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
-
- 12 8月, 2009 1 次提交
-
-
由 Mikael Pettersson 提交于
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 (1f82de10) 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 1f82de10 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: NMikael Pettersson <mikpe@it.uu.se> Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
-
- 30 11月, 2008 1 次提交
-
-
由 Russell King 提交于
As Al did for Versatile in 2ad4f86b, add a typesafe __io implementation for platforms to use. Convert platforms to use this new simple typesafe implementation. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 29 11月, 2008 1 次提交
-
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 07 8月, 2008 2 次提交
-
-
由 Russell King 提交于
This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Remove includes of asm/hardware.h in addition to asm/arch/hardware.h. Then, since asm/hardware.h only exists to include asm/arch/hardware.h, update everything to directly include asm/arch/hardware.h and remove asm/hardware.h. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 04 2月, 2008 1 次提交
-
-
由 Rod Whitby 提交于
Add include of <linux/bitops.h> to io.h to solve compilations errors in files such as drivers/w1/w1_io.c caused by the ixp4xx version of io.h using the BIT() macro without including <linux/bitops.h> first. Signed-off-by: NRod Whitby <rod@whitby.id.au> Acked-by: NLennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 26 1月, 2008 1 次提交
-
-
由 Pavel Roskin 提交于
Don't lose __iomem in casts. Use __force to cast __iomem addresses to integers. Use __force to cast u32 to __le32 and vice versa. Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 20 10月, 2007 1 次提交
-
-
由 Jiri Slaby 提交于
define global BIT macro move all local BIT defines to the new globally define macro. Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Kumar Gala <galak@gate.crashing.org> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Jeff Garzik <jeff@garzik.org> Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Russell King <rmk@arm.linux.org.uk> Acked-by: NRalf Baechle <ralf@linux-mips.org> Cc: "John W. Linville" <linville@tuxdriver.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 06 5月, 2007 1 次提交
-
-
由 Russell King 提交于
__ioremap() took a set of page table flags (specifically the cacheable and bufferable bits) to control the mapping type. However, with the advent of ARMv6, this is far too limited. Replace the page table flags with a memory type index, so that the desired attributes can be selected from the mem_type table. Finally, to prevent silent miscompilation due to the differing arguments, rename the __ioremap() and __ioremap_pfn() functions. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 22 4月, 2007 1 次提交
-
-
由 Ruslan V. Sushko 提交于
Add Intel KIXRP435 Reference Platform based on IXP43x processor. Fixed after review : access to cp15 removed in identification functions, used access to global processor_id instead Signed-off-by: NVladimir Barinov <vbarinov@ru.mvista.com> Signed-off-by: NRuslan Sushko <rsushko@ru.mvista.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 30 3月, 2007 1 次提交
-
-
由 Vladimir Barinov 提交于
Fix compilation fail for ixp4xx platforms for the case when CONFIG_IXP4XX_INDIRECT_PCI is set. That is due to the check_signature() is appeared in include/linux/io.h. Signed-off-by: NVladimir Barinov <vbarinov@ru.mvista.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 10 2月, 2007 1 次提交
-
-
由 Al Viro 提交于
On all targets that sucker boils down to memcpy_fromio(sbk->data, from, len). The function name is highly misguiding (it _never_ does any checksums), the last argument is just a noise and simply expanding the call to memcpy_fromio() gives shorter and more readable source. For a lot of reasons it has almost no remaining users, so it's better to just outright kill it. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 01 7月, 2006 1 次提交
-
-
由 Adrian Bunk 提交于
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 30 4月, 2006 1 次提交
-
-
由 Deepak Saxena 提交于
Patch from Deepak Saxena This patch allows for the addition of IXP4xx systems that do not make use of the PCI interface by moving the CONFIG_PCI symbol selection to be platform-specific instead of for all of IXP4xx. If at least one machine with PCI support is built, the PCI code will be compiled in, but when building !PCI, this will drastically shrink the kernel size. Signed-off-by: NDeepak Saxena <dsaxena@plexity.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 18 11月, 2005 1 次提交
-
-
由 Russell King 提交于
The "align" argument in ARMs __ioremap is unused and provides a misleading expectation that it might do something. It doesn't. Remove it. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 02 11月, 2005 1 次提交
-
-
由 John Bowler 提交于
[ARM] 3083/1: include/asm-arm/arch-ixp4xx/io.h: eliminate warnings for pointer passed to integral function argument Patch from John Bowler Fix for a compiler warning, this wasn't apparent in 2.6.12, I believe the compiler options have been changed (somewhere) so that passing a (void*) to a (u32) argument is now warned. This accounts for the majority of the warnings in my builds of the 2.6.14 kernel for NSLU2. The patch changes pointer parameters declared as u32 to be declared as either, for read parameters: const volatile void __iomem * and for write parameters: volatile void __iomem * Signed-off-by: NJohn Bowler <jbowler@acm.org> Signed-off-by: NDeepak Saxena <dsaxena@plexity.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 31 10月, 2005 1 次提交
-
-
由 John Bowler 提交于
Compiler warning fix; the inline callers of these APIs were changed to have const vaddr parameters. Signed-off-by: NJohn Bowler <jbowler@acm.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 9月, 2005 1 次提交
-
-
由 David Vrabel 提交于
Patch from David Vrabel Correct the ioread* and iowrite* functions. In particular, add an offset to the cookie in ioport_map so we can map I/O port ranges starting from 0 (0 is for reporting errors). Signed-off-by: NDavid Vrabel <dvrabel@arcom.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 07 7月, 2005 1 次提交
-
-
由 Deepak Saxena 提交于
Patch from Deepak Saxena This patch implements the iomap API for Intel IXP4xx NPU systems. We need to implement our own version of the API functions b/c of the PCI hostbridge does not provide the capability to map PCI I/O space into the CPU's physical memory space. In addition, if a system has more than 64M of PCI memory mapped BARs, PCI memory must also be accessed indirectly. This patch changes the assignment of PCI I/O resources to fall into to 0x0000:0xffff range so that we can trap I/O areas in our ioread/iowrite macros. Signed-off-by: Deepak Saxena Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-