1. 01 11月, 2011 1 次提交
  2. 04 4月, 2010 1 次提交
  3. 24 2月, 2010 2 次提交
    • B
      PCI: augment bus resource table with a list · 2fe2abf8
      Bjorn Helgaas 提交于
      Previously we used a table of size PCI_BUS_NUM_RESOURCES (16) for resources
      forwarded to a bus by its upstream bridge.  We've increased this size
      several times when the table overflowed.
      
      But there's no good limit on the number of resources because host bridges
      and subtractive decode bridges can forward any number of ranges to their
      secondary buses.
      
      This patch reduces the table to only PCI_BRIDGE_RESOURCE_NUM (4) entries,
      which corresponds to the number of windows a PCI-to-PCI (3) or CardBus (4)
      bridge can positively decode.  Any additional resources, e.g., PCI host
      bridge windows or subtractively-decoded regions, are kept in a list.
      
      I'd prefer a single list rather than this split table/list approach, but
      that requires simultaneous changes to every architecture.  This approach
      only requires immediate changes where we set up (a) host bridges with more
      than four windows and (b) subtractive-decode P2P bridges, and we can
      incrementally change other architectures to use the list.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      2fe2abf8
    • B
      PCI: add pci_bus_for_each_resource(), remove direct bus->resource[] refs · 89a74ecc
      Bjorn Helgaas 提交于
      No functional change; this converts loops that iterate from 0 to
      PCI_BUS_NUM_RESOURCES through pci_bus resource[] table to use the
      pci_bus_for_each_resource() iterator instead.
      
      This doesn't change the way resources are stored; it merely removes
      dependencies on the fact that they're in a table.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      89a74ecc
  4. 23 2月, 2010 2 次提交
  5. 05 11月, 2009 3 次提交
  6. 14 10月, 2009 1 次提交
  7. 01 7月, 2009 1 次提交
  8. 18 6月, 2009 2 次提交
  9. 16 1月, 2009 1 次提交
  10. 21 10月, 2008 1 次提交
  11. 19 8月, 2008 1 次提交
    • L
      [IA64] pci_acpi_scan_root cleanup · 8a20fd52
      Luck, Tony 提交于
      The code walks all the acpi _CRS methods to see how many windows
      to allocate.  It then scans them all again to insert_resource()
      for each *even if the first scan found that there were none*.
      
      Move the second scan inside the "if (windows)" clause.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      8a20fd52
  12. 21 4月, 2008 1 次提交
  13. 16 4月, 2008 1 次提交
  14. 07 3月, 2008 1 次提交
  15. 11 2月, 2008 1 次提交
  16. 26 7月, 2007 1 次提交
  17. 12 7月, 2007 1 次提交
    • A
      [IA64] prevent MCA when performing MMIO mmap to PCI config space · 012b7105
      Alex Chiang 提交于
      Example memory map (HP rx7640 with 'default' acpiconfig setting, VGA disabled):
         0x00000000 - 0x3FFFBFFF  supports only WB (cacheable) access
      
      If a user attempts to perform an MMIO mmap (using the PCIIOC_MMAP_IS_MEM ioctl)
      to PCI config space (like mmap'ing and accessing memory at 0xA0000),
      we will MCA because the kernel will attempt to use a mapping with the UC
      attribute.
      
      So check the memory attribute in kern_mmap and the EFI memmap. If WC is
      requested, and WC or UC access is supported for the region, allow it.
      Otherwise, use the same attribute the kernel uses.
      
      Updates documentation and test cases as well.
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      012b7105
  18. 23 5月, 2007 1 次提交
  19. 09 5月, 2007 1 次提交
  20. 31 3月, 2007 1 次提交
  21. 30 3月, 2007 1 次提交
  22. 29 3月, 2007 1 次提交
  23. 08 12月, 2006 1 次提交
  24. 07 12月, 2006 1 次提交
  25. 02 12月, 2006 2 次提交
    • J
      Altix: Add initial ACPI IO support · 8ea6091f
      John Keller 提交于
      First phase in introducing ACPI support to SN.
      In this phase, when running with an ACPI capable PROM,
      the DSDT will define the root busses and all SN nodes
      (SGIHUB, SGITIO). An ACPI bus driver will be registered
      for the node devices, with the acpi_pci_root_driver being
      used for the root busses. An ACPI vendor descriptor is
      now used to pass platform specific information for both
      nodes and busses, eliminating the need for the current
      SAL calls. Also, with ACPI support, SN fixup code is no longer
      needed to initiate the PCI bus scans, as the acpi_pci_root_driver
      does that.
      
      However, to maintain backward compatibility with non-ACPI capable
      PROMs, none of the current 'fixup' code can been deleted, though
      much restructuring has been done. For example, the bulk of the code
      in io_common.c is relocated code that is now common regardless
      of what PROM is running, while io_acpi_init.c and io_init.c contain
      routines specific to an ACPI or non ACPI capable PROM respectively.
      
      A new pci bus fixup platform vector has been created to provide
      a hook for invoking platform specific bus fixup from pcibios_fixup_bus().
      
      The size of io_space[] has been increased to support systems with
      large IO configurations.
      Signed-off-by: NJohn Keller <jpk@sgi.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      8ea6091f
    • M
      PCI: Use pci_generic_prep_mwi on ia64 · 3efe2d84
      Matthew Wilcox 提交于
      The pci_generic_prep_mwi() code does everything that pcibios_prep_mwi()
      does on ia64.  All we need to do is be sure that pci_cache_line_size
      is set appropriately, and we can delete pcibios_prep_mwi().
      
      Using SMP_CACHE_BYTES as the default was wrong on uniprocessor machines
      as it is only 8 bytes.  The default in the generic code of L1_CACHE_BYTES
      is at least as good.
      Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
      Acked-by: NJeff Garzik <jeff@garzik.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3efe2d84
  26. 04 10月, 2006 1 次提交
    • E
      [PATCH] genirq: msi: simplify the msi irq limit policy · 92db6d10
      Eric W. Biederman 提交于
      Currently we attempt to predict how many irqs we will be able to allocate with
      msi using pci_vector_resources and some complicated accounting, and then we
      only allow each device as many irqs as we think are available on average.
      
      Only the s2io driver even takes advantage of this feature all other drivers
      have a fixed number of irqs they need and bail if they can't get them.
      
      pci_vector_resources is inaccurate if anyone ever frees an irq.  The whole
      implmentation is racy.  The current irq limit policy does not appear to make
      sense with current drivers.  So I have simplified things.  We can revisit this
      we we need a more sophisticated policy.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      92db6d10
  27. 27 9月, 2006 1 次提交
  28. 11 7月, 2006 1 次提交
    • L
      [PATCH] make valid_mmap_phys_addr_range() take a pfn · 06c67bef
      Lennert Buytenhek 提交于
      Newer ARMs have a 40 bit physical address space, but mapping physical
      memory above 4G needs a special page table format which we (currently?) do
      not use for userspace mappings, so what happens instead is that mapping an
      address >= 4G will happily discard the upper bits and wrap.
      
      There is a valid_mmap_phys_addr_range() arch hook where we could check for
      >= 4G addresses and deny the mapping, but this hook takes an unsigned long
      address:
      
      	static inline int valid_mmap_phys_addr_range(unsigned long addr, size_t size);
      
      And drivers/char/mem.c:mmap_mem() calls it like this:
      
      	static int mmap_mem(struct file * file, struct vm_area_struct * vma)
      	{
      		size_t size = vma->vm_end - vma->vm_start;
      
      		if (!valid_mmap_phys_addr_range(vma->vm_pgoff << PAGE_SHIFT, size))
      
      So that's not much help either.
      
      This patch makes the hook take a pfn instead of a phys address.
      Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      06c67bef
  29. 01 7月, 2006 1 次提交
  30. 28 6月, 2006 1 次提交
  31. 26 6月, 2006 1 次提交
  32. 23 6月, 2006 1 次提交
  33. 09 5月, 2006 1 次提交
    • B
      [IA64] rework memory attribute aliasing · 32e62c63
      Bjorn Helgaas 提交于
      This closes a couple holes in our attribute aliasing avoidance scheme:
      
        - The current kernel fails mmaps of some /dev/mem MMIO regions because
          they don't appear in the EFI memory map.  This keeps X from working
          on the Intel Tiger box.
      
        - The current kernel allows UC mmap of the 0-1MB region of
          /sys/.../legacy_mem even when the chipset doesn't support UC
          access.  This causes an MCA when starting X on HP rx7620 and rx8620
          boxes in the default configuration.
      
      There's more detail in the Documentation/ia64/aliasing.txt file this
      adds, but the general idea is that if a region might be covered by
      a granule-sized kernel identity mapping, any access via /dev/mem or
      mmap must use the same attribute as the identity mapping.
      
      Otherwise, we fall back to using an attribute that is supported
      according to the EFI memory map, or to using UC if the EFI memory
      map doesn't mention the region.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      32e62c63
  34. 21 4月, 2006 1 次提交
    • S
      [IA64] eliminate compile time warnings · a72391e4
      Satoru Takeuchi 提交于
      This patch removes following compile time warnings:
      
      drivers/pci/pci-sysfs.c: In function `pci_read_legacy_io':
      drivers/pci/pci-sysfs.c:257: warning: implicit declaration of function `ia64_pci_legacy_read'
      drivers/pci/pci-sysfs.c: In function `pci_write_legacy_io':
      drivers/pci/pci-sysfs.c:280: warning: implicit declaration of function `ia64_pci_legacy_write'
      
      It also fixes wrong definition of ia64_pci_legacy_write (type of `bus' is not
      `pci_dev', but `pci_bus').
      Signed-Off-By: NSatoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a72391e4