1. 25 4月, 2017 1 次提交
    • L
      PCI: Implement devm_pci_remap_cfgspace() · 490cb6dd
      Lorenzo Pieralisi 提交于
      The introduction of the pci_remap_cfgspace() interface allows PCI host
      controller drivers to map PCI config space through a dedicated kernel
      interface. Current PCI host controller drivers use the devm_ioremap_*()
      devres interfaces to map PCI configuration space regions so in order to
      update them to the new pci_remap_cfgspace() mapping interface a new set of
      devres interfaces should be implemented so that PCI host controller drivers
      can make use of them.
      
      Introduce two new functions in the PCI kernel layer and Devres
      documentation:
      
      - devm_pci_remap_cfgspace()
      - devm_pci_remap_cfg_resource()
      
      so that PCI host controller drivers can make use of them to map PCI
      configuration space regions.
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      490cb6dd
  2. 20 4月, 2017 4 次提交
  3. 19 4月, 2017 4 次提交
  4. 14 4月, 2017 1 次提交
  5. 11 4月, 2017 1 次提交
  6. 04 4月, 2017 1 次提交
  7. 31 3月, 2017 1 次提交
    • L
      PCI: Recognize Thunderbolt devices · 8531e283
      Lukas Wunner 提交于
      Detect on probe whether a PCI device is part of a Thunderbolt controller.
      Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234
      on such devices.  Detect presence of this VSEC and cache it in a newly
      added is_thunderbolt bit in struct pci_dev.
      
      Also, add a helper to check whether a given PCI device is situated on a
      Thunderbolt daisy chain (i.e., below a PCI device with is_thunderbolt
      set).
      
      The necessity arises from the following:
      
      * If an external Thunderbolt GPU is connected to a dual GPU laptop,
        that GPU is currently registered with vga_switcheroo even though it
        can neither drive the laptop's panel nor be powered off by the
        platform.  To vga_switcheroo it will appear as if two discrete
        GPUs are present.  As a result, when the external GPU is runtime
        suspended, vga_switcheroo will cut power to the internal discrete GPU
        which may not be runtime suspended at all at this moment.  The
        solution is to not register external GPUs with vga_switcheroo, which
        necessitates a way to recognize if they're on a Thunderbolt daisy
        chain.
      
      * Dual GPU MacBook Pros introduced 2011+ can no longer switch external
        DisplayPort ports between GPUs.  (They're no longer just used for DP
        but have become combined DP/Thunderbolt ports.)  The driver to switch
        the ports, drivers/platform/x86/apple-gmux.c, needs to detect presence
        of a Thunderbolt controller and, if found, keep external ports
        permanently switched to the discrete GPU.
      
      v2: Make kerneldoc for pci_is_thunderbolt_attached() more precise,
          drop portion of commit message pertaining to separate series.
          (Bjorn Helgaas)
      
      Cc: Andreas Noever <andreas.noever@gmail.com>
      Cc: Michael Jamet <michael.jamet@intel.com>
      Cc: Tomas Winkler <tomas.winkler@intel.com>
      Cc: Amir Levy <amir.jer.levy@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Link: http://patchwork.freedesktop.org/patch/msgid/0ab165a4a35c0b60f29d4c306c653ead14fcd8f9.1489145162.git.lukas@wunner.de
      8531e283
  8. 30 3月, 2017 2 次提交
  9. 10 3月, 2017 1 次提交
  10. 02 3月, 2017 1 次提交
  11. 10 2月, 2017 1 次提交
  12. 21 1月, 2017 1 次提交
  13. 14 1月, 2017 1 次提交
  14. 08 12月, 2016 3 次提交
    • T
      PCI: Export host bridge registration interface · a52d1443
      Thierry Reding 提交于
      Allow PCI host bridge drivers to use the new host bridge interfaces to
      register their host bridge.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
      a52d1443
    • T
      PCI: Allow driver-specific data in host bridge · 59094065
      Thierry Reding 提交于
      Provide a way to allocate driver-specific data along with a PCI host bridge
      structure. The bridge's ->private field points to this data.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
      59094065
    • A
      PCI: Add pci_register_host_bridge() interface · 37d6a0a6
      Arnd Bergmann 提交于
      Make the existing pci_host_bridge structure a proper device that is usable
      by PCI host drivers in a more standard way. In addition to the existing
      pci_scan_bus(), pci_scan_root_bus(), pci_scan_root_bus_msi(), and
      pci_create_root_bus() interfaces, this unfortunately means having to add
      yet another interface doing basically the same thing, and add some extra
      code in the initial step.
      
      However, this time it's more likely to be extensible enough that we won't
      have to do another one again in the future, and we should be able to reduce
      code much more as a result.
      
      The main idea is to pull the allocation of 'struct pci_host_bridge' out of
      the registration, and let individual host drivers and architecture code
      fill the members before calling the registration function.
      
      There are a number of things we can do based on this:
      
      * Use a single memory allocation for the driver-specific structure
        and the generic PCI host bridge
      * consolidate the contents of driver-specific structures by moving
        them into pci_host_bridge
      * Add a consistent interface for removing a PCI host bridge again
        when unloading a host driver module
      * Replace the architecture specific __weak pcibios_*() functions with
        callbacks in a pci_host_bridge device
      * Move common boilerplate code from host drivers into the generic
        function, based on contents of the structure
      * Extend pci_host_bridge with additional members when needed without
        having to add arguments to pci_scan_*().
      * Move members of struct pci_bus into pci_host_bridge to avoid
        having lots of identical copies.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
      37d6a0a6
  15. 24 11月, 2016 1 次提交
  16. 09 11月, 2016 2 次提交
  17. 28 9月, 2016 1 次提交
  18. 23 9月, 2016 1 次提交
    • K
      PCI: pciehp: Allow exclusive userspace control of indicators · 576243b3
      Keith Busch 提交于
      PCIe hotplug supports optional Attention and Power Indicators, which are
      used internally by pciehp.  Users can't control the Power Indicator, but
      they can control the Attention Indicator by writing to a sysfs "attention"
      file.
      
      The Slot Control register has two bits for each indicator, and the PCIe
      spec defines the encodings for each as (Reserved/On/Blinking/Off).  For
      sysfs "attention" writes, pciehp_set_attention_status() maps into these
      encodings, so the only useful write values are 0 (Off), 1 (On), and 2
      (Blinking).
      
      However, some platforms use all four bits for platform-specific indicators,
      and they need to allow direct user control of them while preventing pciehp
      from using them at all.
      
      Add a "hotplug_user_indicators" flag to the pci_dev structure.  When set,
      pciehp does not use either the Attention Indicator or the Power Indicator,
      and the low four bits (values 0x0 - 0xf) of sysfs "attention" write values
      are written directly to the Attention Indicator Control and Power Indicator
      Control fields.
      
      [bhelgaas: changelog, rename flag and accessors to s/attention/indicator/]
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      576243b3
  19. 17 9月, 2016 1 次提交
  20. 15 9月, 2016 1 次提交
  21. 07 9月, 2016 1 次提交
  22. 02 9月, 2016 1 次提交
  23. 25 8月, 2016 1 次提交
    • B
      PCI: Add PTM clock granularity information · 8b2ec318
      Bjorn Helgaas 提交于
      The PTM Control register (PCIe r3.1, sec 7.32.3) contains an Effective
      Granularity field:
      
        This provides information relating to the expected accuracy of the PTM
        clock, but does not otherwise affect the PTM mechanism.
      
      Set the Effective Granularity based on the PTM Root and any intervening PTM
      Time Sources.
      
      This does not set Effective Granularity for Root Complex Integrated
      Endpoints because I don't know how to figure out clock granularity for
      them.  The spec says:
      
        ... system software must set [Effective Granularity] to the value
        reported in the Local Clock Granularity field by the associated PTM
        Time Source.
      
      but I don't know how to identify the associated PTM Time Source.  Normally
      it's the upstream bridge, but an integrated endpoint has no upstream
      bridge.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      8b2ec318
  24. 19 8月, 2016 1 次提交
  25. 17 8月, 2016 1 次提交
    • C
      PCI: Use positive flags in pci_alloc_irq_vectors() · 4fe0d154
      Christoph Hellwig 提交于
      Instead of passing negative flags like PCI_IRQ_NOMSI to prevent use of
      certain interrupt types, pass positive flags like PCI_IRQ_LEGACY,
      PCI_IRQ_MSI, etc., to specify the acceptable interrupt types.
      
      This is based on a number of pending driver conversions that just happend
      to be a whole more obvious to read this way, and given that we have no
      users in the tree yet it can still easily be done.
      
      I've also added a PCI_IRQ_ALL_TYPES catchall to keep the case of accepting
      all interrupt types very simple.
      
      [bhelgaas: changelog, fix PCI_IRQ_AFFINITY doc typo, remove mention of
      PCI_IRQ_NOLEGACY]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NAlexander Gordeev <agordeev@redhat.com>
      4fe0d154
  26. 16 8月, 2016 1 次提交
  27. 26 7月, 2016 1 次提交
  28. 22 7月, 2016 2 次提交
  29. 24 6月, 2016 1 次提交
    • L
      PCI: Add generic pci_bus_claim_resources() · 765bf9b7
      Lorenzo Pieralisi 提交于
      All PCI resources (bridge windows and BARs) should be inserted in the
      iomem_resource and ioport_resource trees so we know what space is occupied
      and what is available for other devices.  There's nothing arch-specific
      about this, but it is currently done by arch-specific code.
      
      Add a generic pci_bus_claim_resources() interface so we can migrate away
      from the arch-specific code.
      
      [bhelgaas: changelog]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Yinghai Lu <yinghai@kernel.org>
      765bf9b7