1. 14 1月, 2013 1 次提交
    • R
      ACPI / PCI: Set root bridge ACPI handle in advance · 6c0cc950
      Rafael J. Wysocki 提交于
      The ACPI handles of PCI root bridges need to be known to
      acpi_bind_one(), so that it can create the appropriate
      "firmware_node" and "physical_node" files for them, but currently
      the way it gets to know those handles is not exactly straightforward
      (to put it lightly).
      
      This is how it works, roughly:
      
        1. acpi_bus_scan() finds the handle of a PCI root bridge,
           creates a struct acpi_device object for it and passes that
           object to acpi_pci_root_add().
      
        2. acpi_pci_root_add() creates a struct acpi_pci_root object,
           populates its "device" field with its argument's address
           (device->handle is the ACPI handle found in step 1).
      
        3. The struct acpi_pci_root object created in step 2 is passed
           to pci_acpi_scan_root() and used to get resources that are
           passed to pci_create_root_bus().
      
        4. pci_create_root_bus() creates a struct pci_host_bridge object
           and passes its "dev" member to device_register().
      
        5. platform_notify(), which for systems with ACPI is set to
           acpi_platform_notify(), is called.
      
      So far, so good.  Now it starts to be "interesting".
      
        6. acpi_find_bridge_device() is used to find the ACPI handle of
           the given device (which is the PCI root bridge) and executes
           acpi_pci_find_root_bridge(), among other things, for the
           given device object.
      
        7. acpi_pci_find_root_bridge() uses the name (sic!) of the given
           device object to extract the segment and bus numbers of the PCI
           root bridge and passes them to acpi_get_pci_rootbridge_handle().
      
        8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI
           root bridges and finds the one that matches the given segment
           and bus numbers.  Its handle is then used to initialize the
           ACPI handle of the PCI root bridge's device object by
           acpi_bind_one().  However, this is *exactly* the ACPI handle we
           started with in step 1.
      
      Needless to say, this is quite embarassing, but it may be avoided
      thanks to commit f3fd0c8a (ACPI: Allow ACPI handles of devices to be
      initialized in advance), which makes it possible to initialize the
      ACPI handle of a device before passing it to device_register().
      
      Accordingly, add a new __weak routine, pcibios_root_bridge_prepare(),
      defaulting to an empty implementation that can be replaced by the
      interested architecutres (x86 and ia64 at the moment) with functions
      that will set the root bridge's ACPI handle before its dev member is
      passed to device_register().  Make both x86 and ia64 provide such
      implementations of pcibios_root_bridge_prepare() and remove
      acpi_pci_find_root_bridge() and acpi_get_pci_rootbridge_handle() that
      aren't necessary any more.
      
      Included is a fix for breakage on systems with non-ACPI PCI host
      bridges from Bjorn Helgaas.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      6c0cc950
  2. 22 9月, 2012 1 次提交
  3. 19 9月, 2012 2 次提交
  4. 06 7月, 2012 1 次提交
  5. 14 6月, 2012 2 次提交
  6. 29 3月, 2012 1 次提交
  7. 24 2月, 2012 1 次提交
  8. 07 1月, 2012 3 次提交
  9. 01 11月, 2011 1 次提交
  10. 04 4月, 2010 1 次提交
  11. 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
  12. 23 2月, 2010 2 次提交
  13. 05 11月, 2009 3 次提交
  14. 14 10月, 2009 1 次提交
  15. 01 7月, 2009 1 次提交
  16. 18 6月, 2009 2 次提交
  17. 16 1月, 2009 1 次提交
  18. 21 10月, 2008 1 次提交
  19. 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
  20. 21 4月, 2008 1 次提交
  21. 16 4月, 2008 1 次提交
  22. 07 3月, 2008 1 次提交
  23. 11 2月, 2008 1 次提交
  24. 26 7月, 2007 1 次提交
  25. 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
  26. 23 5月, 2007 1 次提交
  27. 09 5月, 2007 1 次提交
  28. 31 3月, 2007 1 次提交
  29. 30 3月, 2007 1 次提交
  30. 29 3月, 2007 1 次提交
  31. 08 12月, 2006 1 次提交