1. 05 Jul, 2016 11 commits
  2. 29 Jun, 2016 3 commits
  3. 28 Jun, 2016 4 commits
  4. 24 Jun, 2016 7 commits
  5. 23 Jun, 2016 1 commit
  6. 21 Jun, 2016 14 commits
    • Gavin Shan's avatar
      powerpc/powernv: Print correct PHB type names · 9497a1c1
      Gavin Shan authored
      We're initializing "IODA1" and "IODA2" PHBs though they are IODA2
      and NPU PHBs as below kernel log indicates.
      
         Initializing IODA1 OPAL PHB /pciex@3fffe40700000
         Initializing IODA2 OPAL PHB /pciex@3fff000400000
      
      This fixes the PHB names. After it's applied, we get:
      
         Initializing IODA2 PHB (/pciex@3fffe40700000)
         Initializing NPU PHB (/pciex@3fff000400000)
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      9497a1c1
    • Gavin Shan's avatar
      PCI/hotplug: PowerPC PowerNV PCI hotplug driver · 66725152
      Gavin Shan authored
      This adds standalone driver to support PCI hotplug for PowerPC PowerNV
      platform that runs on top of skiboot firmware. The firmware identifies
      hotpluggable slots and marked their device tree node with proper
      "ibm,slot-pluggable" and "ibm,reset-by-firmware". The driver scans
      device tree nodes to create/register PCI hotplug slot accordingly.
      
      The PCI slots are organized in fashion of tree, which means one
      PCI slot might have parent PCI slot and parent PCI slot possibly
      contains multiple child PCI slots. At the plugging time, the parent
      PCI slot is populated before its children. The child PCI slots are
      removed before their parent PCI slot can be removed from the system.
      
      If the skiboot firmware doesn't support slot status retrieval, the PCI
      slot device node shouldn't have property "ibm,reset-by-firmware". In
      that case, none of valid PCI slots will be detected from device tree.
      The skiboot firmware doesn't export the capability to access attention
      LEDs yet and it's something for TBD.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      66725152
    • Gavin Shan's avatar
      powerpc/powernv: Functions to get/set PCI slot state · ea0d856c
      Gavin Shan authored
      This exports 4 functions, which base on the corresponding OPAL
      APIs to get/set PCI slot status. Those functions are going to
      be used by PowerNV PCI hotplug driver:
      
         pnv_pci_get_device_tree()    opal_get_device_tree()
         pnv_pci_get_presence_state() opal_pci_get_presence_state()
         pnv_pci_get_power_state()    opal_pci_get_power_state()
         pnv_pci_set_power_state()    opal_pci_set_power_state()
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      ea0d856c
    • Gavin Shan's avatar
      powerpc/powernv: Introduce pnv_pci_get_slot_id() · 7e19bf32
      Gavin Shan authored
      This introduces pnv_pci_get_slot_id() to get the hotpluggable PCI
      slot ID from the corresponding device node. It will be used by
      hotplug driver.
      Requested-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7e19bf32
    • Gavin Shan's avatar
      powerpc/powernv: Use PCI slot reset infrastructure · 9c0e1ecb
      Gavin Shan authored
      The (OPAL) firmware might provide the PCI slot reset capability
      which is identified by property "ibm,reset-by-firmware" on the
      PCI slot associated device node.
      
      This routes the reset request to firmware if "ibm,reset-by-firmware"
      exists in the PCI slot device node. Otherwise, the reset is done
      inside kernel as before.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      9c0e1ecb
    • Gavin Shan's avatar
      powerpc/powernv: Support PCI slot ID · ebe22531
      Gavin Shan authored
      The reset and poll functionality from (OPAL) firmware supports
      PHB and PCI slot at same time. They are identified by ID. This
      supports PCI slot ID by:
      
         * Rename the argument name for opal_pci_reset() and opal_pci_poll()
           accordingly
         * Rename pnv_eeh_phb_poll() to pnv_eeh_poll() and adjust its argument
           name.
         * One macro is added to produce PCI slot ID.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      ebe22531
    • Gavin Shan's avatar
      powerpc/pci: Delay populating pdn · 8cc7581c
      Gavin Shan authored
      The pdn (struct pci_dn) instances are allocated from memblock or
      bootmem when creating PCI controller (hoses) in setup_arch(). PCI
      hotplug, which will be supported by proceeding patches, releases
      PCI device nodes and their corresponding pdn on unplugging event.
      The memory chunks for pdn instances allocated from memblock or
      bootmem are hard to reused after being released.
      
      This delays creating pdn by pci_devs_phb_init() from setup_arch()
      to core_initcall() so that they are allocated from slab. The memory
      consumed by pdn can be released to system without problem during
      PCI unplugging time. It indicates that pci_dn is unavailable in
      setup_arch() and the the fixup on pdn (like AGP's) can't be carried
      out that time. We have to do that in pcibios_root_bridge_prepare()
      on maple/pasemi/powermac platforms where/when the pdn is available.
      pcibios_root_bridge_prepare is called from subsys_initcall() which
      is executed after core_initcall() so the code flow does not change.
      
      At the mean while, the EEH device is created when pdn is populated,
      meaning pdn and EEH device have same life cycle. In turn, we needn't
      call eeh_dev_init() to create EEH device explicitly.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      8cc7581c
    • Gavin Shan's avatar
      powerpc/pci: Update bridge windows on PCI plug · 7415c14c
      Gavin Shan authored
      On the PCI plugging event, PCI slot's subordinate devices are
      scanned and their (IO and MMIO) resources are assigned. Platform
      dependent resources (PE#, IO/MMIO/DMA windows) are allocated or
      created on updating windows of the slot's upstream bridge.
      
      This updates the windows of the hot plugged slot's upstream bridge
      in pcibios_finish_adding_to_bus() so that the platform resources
      (PE#, IO/MMIO/DMA segments) are allocated or created accordingly.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7415c14c
    • Gavin Shan's avatar
      powerpc/powernv: Dynamically release PE · c5f7700b
      Gavin Shan authored
      This supports releasing PEs dynamically. A reference count is
      introduced to PE representing number of PCI devices associated
      with the PE. The reference count is increased when PCI device
      joins the PE and decreased when PCI device leaves the PE in
      pnv_pci_release_device(). When the count becomes zero, the PE
      and its consumed resources are released. Note that the count
      is accessed concurrently. So a counter with "int" type is enough
      here.
      
      In order to release the sources consumed by the PE, couple of
      helper functions are introduced as below:
      
         * pnv_pci_ioda1_unset_window() - Unset IODA1 DMA32 window
         * pnv_pci_ioda1_release_dma_pe() - Release IODA1 DMA32 segments
         * pnv_pci_ioda2_release_dma_pe() - Release IODA2 DMA resource
         * pnv_ioda_release_pe_seg() - Unmap IO/M32/M64 segments
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      c5f7700b
    • Gavin Shan's avatar
      powerpc/powernv: Make pnv_ioda_deconfigure_pe() visible · 93e01a50
      Gavin Shan authored
      pnv_ioda_deconfigure_pe() is visible only when CONFIG_PCI_IOV is
      enabled. The function will be used to tear down PE's associated
      mapping in PCI hotplug path that doesn't depend on CONFIG_PCI_IOV.
      
      This makes pnv_ioda_deconfigure_pe() visible and not depend on
      CONFIG_PCI_IOV.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      93e01a50
    • Gavin Shan's avatar
      powerpc/powernv: Extend PCI bridge resources · 40e2a47e
      Gavin Shan authored
      The PCI slots are associated with root port or downstream ports
      of the PCIe switch connected to root port. When adapter is hot
      added to the PCI slot, it usually requests more IO or memory
      resource from the directly connected parent bridge (port) and
      update the bridge's windows accordingly. The resource windows
      of upstream bridges can't be updated automatically. It possibly
      leads to unbalanced resource across the bridges: The window of
      downstream bridge is overruning that of upstream bridge. The
      IO or MMIO path won't work.
      
      This resolves the above issue by extending bridge windows of
      root port and upstream port of the PCIe switch connected to
      the root port to PHB's windows.
      
      The windows of root port and bridge behind that are extended to
      the PHB's windows to accomodate the PCI hotplug happening in
      future. The PHB's 64KB 32-bits MSI region is included in bridge's
      M32 windows (in hardware) though it's excluded in the corresponding
      resource, as the bridge's M32 windows have 1MB as their minimal
      alignment. We observed EEH error during system boot when the MSI
      region is included in bridge's M32 window.
      
      This excludes top 1MB (including 64KB 32-bits MSI region) region
      from bridge's M32 windows when extending them.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      40e2a47e
    • Gavin Shan's avatar
      powerpc/powernv: Setup PE for root bus · 63803c39
      Gavin Shan authored
      There is no parent bridge for root bus, meaning pcibios_setup_bridge()
      isn't invoked for root bus. The PE for root bus is the ancestor of
      other PEs in PELTV. It means we need PE for root bus populated before
      all others.
      
      This populates the PE for root bus in pcibios_setup_bridge() path
      if it's not populated yet. The PE number next to the reserved one
      is used as the PE# to avoid holes in continuous M64 space.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      63803c39
    • Gavin Shan's avatar
      powerpc/powernv: Create PEs in pcibios_setup_bridge() · ccd1c191
      Gavin Shan authored
      Currently, the PEs and their associated resources are assigned in
      ppc_md.pcibios_fixup() except those used by SRIOV VFs. The function
      is called for once after PCI probing and resources assignment is
      completed. So it's obviously not hotplug friendly.
      
      This creates PEs dynamically in pcibios_setup_bridge() that is
      called for the event during system bootup and PCI hotplug: updating
      PCI bridge's windows after resource assignment/reassignment are done.
      In partial hotplug case, not all PCI devices included to one particular
      PE are unplugged and plugged again, we just need unbinding/binding the
      hot added PCI devices with the corresponding PE without creating new
      one. The change is applied to IODA1 and IODA2 PHBs only. The behaviour
      on NPU PHBs aren't changed. There are no PCI bridges on NPU PHBs,
      meaning pcibios_setup_bridge() won't be invoked there. We have to use
      old path (pnv_pci_ioda_fixup()) to setup PEs on NPU PHBs.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      ccd1c191
    • Gavin Shan's avatar
      powerpc/powernv: Allocate PE# in reverse order · 9fcd6f4a
      Gavin Shan authored
      PE number for one particular PE can be allocated dynamically or
      reserved according to the consumed M64 (64-bits prefetchable)
      segments of the PE. The M64 segment can't be remapped to arbitrary
      PE, meaning the PE number is determined according to the index
      of the consumed M64 segment. As below figure shows, M64 resource
      grows from low to high end, meaning the PE (number) reserved
      according to M64 segment grows from low to high end as well,
      so does the dynamically allocated PE number. It will lead to
      conflict: PE number (M64 segment) reserved by dynamic allocation
      is required by hot added PCI adapter at later point. It fails
      the PCI hotplug because of the PE number can't be reserved
      based on the index of the consumed M64 segment.
      
        +---+---+---+---+---+--------------------------------+-----+
        | 0 | 1 | 2 | 3 | 4 |      .......                   | 255 |
        +---+---+---+---+---+--------------------------------+-----+
      
        PE number for dynamic allocation          ----------------->
        PE number reserved for M64 segment        ----------------->
      
      To resolve above conflicts, this forces the PE number to be
      allocated dynamically in reverse order. With this patch applied,
      the PE numbers are reserved in ascending order, but allocated
      dynamically in reverse order.
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      9fcd6f4a