1. 05 12月, 2009 4 次提交
  2. 12 8月, 2009 1 次提交
    • M
      IXP4xx: Fix IO_SPACE_LIMIT for 2.6.31-rc core PCI changes · dee2b904
      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>
      dee2b904
  3. 30 11月, 2008 1 次提交
  4. 29 11月, 2008 1 次提交
  5. 07 8月, 2008 2 次提交
  6. 04 2月, 2008 1 次提交
  7. 26 1月, 2008 1 次提交
  8. 20 10月, 2007 1 次提交
  9. 06 5月, 2007 1 次提交
    • R
      [ARM] mm 10: allow memory type to be specified with ioremap · 3603ab2b
      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>
      3603ab2b
  10. 22 4月, 2007 1 次提交
  11. 30 3月, 2007 1 次提交
  12. 10 2月, 2007 1 次提交
  13. 01 7月, 2006 1 次提交
  14. 30 4月, 2006 1 次提交
  15. 18 11月, 2005 1 次提交
  16. 02 11月, 2005 1 次提交
  17. 31 10月, 2005 1 次提交
  18. 01 9月, 2005 1 次提交
  19. 07 7月, 2005 1 次提交
    • D
      [PATCH] ARM: 2792/1: IXP4xx iomap API implementation · 450008b5
      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>
      450008b5
  20. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      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!
      1da177e4