1. 11 Nov, 2005 8 commits
    • rajesh.shah@intel.com's avatar
      [PATCH] pciehp: clean-up how we request control of hotplug hardware · a3a45ec8
      rajesh.shah@intel.com authored
      This patch further tweaks how we request control of hotplug
      controller hardware from BIOS. We first search the ACPI namespace
      corresponding to a specific hotplug controller looking for an
      _OSC or OSHP method. On failure, we successively move to the
      ACPI parent object, till we hit the highest level host bridge
      in the hierarchy. This allows for different types of BIOS's
      which place the _OSC/OSHP methods at various places in the acpi
      namespace, while still not encroaching on the namespace of
      some other root level host bridge.
      
      This patch also introduces a new load time option (pciehp_force)
      that allows us to bypass all _OSC/OSHP checking. Not supporting
      these methods seems to be be the most common ACPI firmware problem
      we've run into. This will still _not_ allow the pciehp driver to
      work correctly if the BIOS really doesn't support pciehp (i.e. if
      it doesn't generate a hotplug interrupt). Use this option with
      caution.  Some BIOS's may deliberately not build any _OSC/OSHP
      methods to make sure it retains control the hotplug hardware.
      Using the pciehp_force parameter for such systems can lead to
      two separate entities trying to control the same hardware.
      Signed-off-by: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      a3a45ec8
    • rajesh.shah@intel.com's avatar
      [PATCH] pciehp: request control of each hotplug controller individually · 427bf532
      rajesh.shah@intel.com authored
      This patch tweaks the way pciehp requests control of the hotplug
      hardware from BIOS. It now tries to invoke the ACPI _OSC method
      for a specific hotplug controller only, rather than walking the
      entire acpi namespace invoking all possible _OSC methods under
      all host bridges. This allows us to gain control of each hotplug
      controller individually, even if BIOS fails to give us control of
      some other hotplug controller in the system.
      Signed-off-by: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      427bf532
    • rajesh.shah@intel.com's avatar
      [PATCH] pciehp: reduce debug message verbosity · 1a9ed1bf
      rajesh.shah@intel.com authored
      Reduce the number of debug messages generated if pciehp debug is
      enabled. I tried to restrict this to removing debug messages that
      are either early-driver-debug type messages, or print information
      that can be inferred through other debug prints.
      Signed-off-by: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1a9ed1bf
    • rajesh.shah@intel.com's avatar
      [PATCH] pciehp: miscellaneous cleanups · ed6cbcf2
      rajesh.shah@intel.com authored
      Remove un-necessary header includes, remove dead code, remove
      some hardcoded constants...
      Signed-off-by: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ed6cbcf2
    • rajesh.shah@intel.com's avatar
      [PATCH] pciehp: remove redundant data structures · ca22a5e4
      rajesh.shah@intel.com authored
      State information is currently stored in per-slot as well as
      per-pci-function data structures in pciehp. There's a lot of
      overlap in the information kept, and some of it is never used.
      This patch consolidates the state information to per-slot and
      eliminates unused data structures. The biggest change is to
      eliminate the pci_func structure and the code around managing
      its lists.
      Signed-off-by: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ca22a5e4
    • rajesh.shah@intel.com's avatar
      [PATCH] pciehp: reduce dependence on ACPI · a8a2be94
      rajesh.shah@intel.com authored
      Reduce the PCI Express hotplug driver's dependence on ACPI.
      We don't walk the acpi namespace anymore to build a list of
      bridges and devices. We go to ACPI only to run the _OSC or
      _OSHP methods to transition control of hotplug hardware from
      system BIOS to the hotplug driver, and to run the _HPP
      method to get hotplug device parameters like cache line size,
      latency timer and SERR/PERR enable from BIOS.
      
      Note that one of the side effects of this patch is that pciehp
      does not automatically enable the hot-added device or its DMA
      bus mastering capability now. It expects the device driver to
      do that. This may break some drivers and we will have to fix
      them as they are reported.
      Signed-off-by: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      a8a2be94
    • rajesh.shah@intel.com's avatar
      [PATCH] patch 1/8] pciehp: use the PCI core for hotplug resource management · 71b720c0
      rajesh.shah@intel.com authored
      This patch converts the pci express hotplug controller driver
      to use the PCI core for resource management. This eliminates a
      lot of duplicated code and integrates pciehp with the system's
      normal PCI handling code.
      Signed-off-by: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      71b720c0
    • Roland Dreier's avatar
      [PATCH] PCI: add pci_find_next_capability() · 24a4e377
      Roland Dreier authored
      Some devices have more than one capability of the same type.  For
      example, the PCI header for the PathScale InfiniPath looks like:
      
      	04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02)
      		Subsystem: Unknown device 1fc1:000d
      		Flags: bus master, fast devsel, latency 0, IRQ 193
      		Memory at fea00000 (64-bit, non-prefetchable) [size=2M]
      		Capabilities: [c0] HyperTransport: Slave or Primary Interface
      		Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration
      
      There are _two_ HyperTransport capabilities, and the PathScale driver
      wants to look at both of them.
      
      The current pci_find_capability() API doesn't work for this, since it
      only allows us to get to the first capability of a given type.  The
      patch below introduces a new pci_find_next_capability(), which can be
      used in a loop like
      
      	for (pos = pci_find_capability(pdev, <ID>);
      	     pos;
      	     pos = pci_find_next_capability(pdev, pos, <ID>)) {
      		/* ... */
      	}
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      Signed-off-by: default avatarMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      24a4e377
  2. 10 Nov, 2005 32 commits