1. 28 May, 2014 8 commits
  2. 27 May, 2014 17 commits
  3. 26 May, 2014 5 commits
    • Bjorn Helgaas's avatar
      Merge branches 'dma-api', 'pci/virtualization', 'pci/msi', 'pci/misc' and 'pci/resource' into next · e5558d1a
      Bjorn Helgaas authored
      * dma-api:
        iommu/exynos: Remove unnecessary "&" from function pointers
        DMA-API: Update dma_pool_create ()and dma_pool_alloc() descriptions
        DMA-API: Fix duplicated word in DMA-API-HOWTO.txt
        DMA-API: Capitalize "CPU" consistently
        sh/PCI: Pass GAPSPCI_DMA_BASE CPU & bus address to dma_declare_coherent_memory()
        DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t
        DMA-API: Clarify physical/bus address distinction
      
      * pci/virtualization:
        PCI: Mark RTL8110SC INTx masking as broken
      
      * pci/msi:
        PCI/MSI: Remove pci_enable_msi_block()
      
      * pci/misc:
        PCI: Remove pcibios_add_platform_entries()
        s390/pci: use pdev->dev.groups for attribute creation
        PCI: Move Open Firmware devspec attribute to PCI common code
      
      * pci/resource:
        PCI: Add resource allocation comments
        PCI: Simplify __pci_assign_resource() coding style
        PCI: Change pbus_size_mem() return values to be more conventional
        PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
        PCI: Support BAR sizes up to 8GB
        resources: Clarify sanity check message
        PCI: Don't add disabled subtractive decode bus resources
        PCI: Don't print anything while decoding is disabled
        PCI: Don't set BAR to zero if dma_addr_t is too small
        PCI: Don't convert BAR address to resource if dma_addr_t is too small
        PCI: Reject BAR above 4GB if dma_addr_t is too small
        PCI: Fail safely if we can't handle BARs larger than 4GB
        x86/gart: Tidy messages and add bridge device info
        x86/gart: Replace printk() with pr_info()
        x86/PCI: Move pcibios_assign_resources() annotation to definition
        x86/PCI: Mark ATI SBx00 HPET BAR as IORESOURCE_PCI_FIXED
        x86/PCI: Don't try to move IORESOURCE_PCI_FIXED resources
        x86/PCI: Fix Broadcom CNB20LE unintended sign extension
      e5558d1a
    • Bjorn Helgaas's avatar
      iommu/exynos: Remove unnecessary "&" from function pointers · 14574674
      Bjorn Helgaas authored
      Remove unnecessary "&" from function pointers in exynos_iommu_ops.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      14574674
    • Gioh Kim's avatar
      DMA-API: Update dma_pool_create ()and dma_pool_alloc() descriptions · 2af9da86
      Gioh Kim authored
      Use "boundary" to be more descriptive than "alloc" in the dma_pool_create()
      documentation.
      
      Replace "SLAB_KERNEL" and "SLAB_ATOMIC" with the correct "GFP_KERNEL" and
      "GFP_ATOMIC."
      
      [bhelgaas: changelog]
      Signed-off-by: default avatarGioh Kim <gioh.kim@lge.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      2af9da86
    • Emilio López's avatar
      DMA-API: Fix duplicated word in DMA-API-HOWTO.txt · 34c815fb
      Emilio López authored
      "coherent" is written twice when it should be just once.
      Signed-off-by: default avatarEmilio López <emilio@elopez.com.ar>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      34c815fb
    • Bjorn Helgaas's avatar
      DMA-API: Capitalize "CPU" consistently · f311a724
      Bjorn Helgaas authored
      Sometimes we used "cpu," other times "CPU."  Use "CPU" consistently.
      Suggested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      f311a724
  4. 23 May, 2014 10 commits
    • Bjorn Helgaas's avatar
      PCI: Add resource allocation comments · 67d29b5c
      Bjorn Helgaas authored
      Add comments in the code to match the allocation strategy of 7c671426dfc3
      ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources").
      
      No functional change.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      67d29b5c
    • Bjorn Helgaas's avatar
      PCI: Simplify __pci_assign_resource() coding style · d3689df0
      Bjorn Helgaas authored
      If an allocation succeeds, we can return success immediately.  Then we
      don't have to test for success in the subsequent code.
      
      No functional change.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      d3689df0
    • Bjorn Helgaas's avatar
      PCI: Change pbus_size_mem() return values to be more conventional · 30afe8d0
      Bjorn Helgaas authored
      pbus_size_mem() previously returned 0 for failure and 1 for success.
      Change it to return -ENOSPC for failure and 0 for success.
      
      No functional change.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      30afe8d0
    • Yinghai Lu's avatar
      PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources · 5b285415
      Yinghai Lu authored
      This patch changes the way we handle 64-bit prefetchable bridge windows to
      make it more likely that we can assign space to all devices.
      
      Previously we put all prefetchable resources in the prefetchable bridge
      window.  If any of those resources was 32-bit only, we restricted the
      window to be below 4GB.
      
      After this patch, we only put 64-bit prefetchable resources in a 64-bit
      prefetchable window.  We put all 32-bit prefetchable resources in the
      non-prefetchable window, even if there are no 64-bit prefetchable
      resources.
      
      With the previous approach, if there was a 32-bit prefetchable resource
      behind a bridge, we forced the bridge's prefetchable window below 4GB,
      which meant that even if there was plenty of space above 4GB available, we
      couldn't use it, and assignment of large 64-bit resources could fail, as
      in the bugzilla below.
      
      The new strategy is:
      
        1) If the prefetchable window is 64 bits wide, we put only 64-bit
           prefetchable resources in it.  Any 32-bit prefetchable resources go in
           the non-prefetchable window.
      
        2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
           prefetchable resources in it.
      
        3) If there is no prefetchable window, all MMIO resources go in the
           non-prefetchable window.
      
      This reduces performance for 32-bit prefetchable resources below a bridge
      with a 64-bit prefetchable window.  We previously assigned prefetchable
      space, but now we'll assign non-prefetchable space.  This is the case even
      if there are no 64-bit prefetchable resources, or if they would all fit
      below 4GB.  In those cases, the old strategy would work and would have
      better performance.
      
      [bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151Tested-by: default avatarGuo Chao <yan@linux.vnet.ibm.com>
      Tested-by: default avatarWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      5b285415
    • Alan's avatar
      PCI: Support BAR sizes up to 8GB · 14c8530d
      Alan authored
      This is needed for some of the Xeon Phi type systems.
      
      [bhelgaas: added Nikhil, use ARRAY_SIZE() to connect with decl, folded in
      Kevin's "order < 0" fix to ARRAY_SIZE() usage]
      Signed-off-by: default avatarNikhil P Rao <nikhil.rao@intel.com>
      Signed-off-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarKevin Hilman <khilman@linaro.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      14c8530d
    • Bjorn Helgaas's avatar
      resources: Clarify sanity check message · e4c72966
      Bjorn Helgaas authored
      The resource map sanity check message is a bit confusing.  Change it to be
      more readable:
      
        -resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01
        +resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than pnp 00:01 [mem 0xfed10000-0xfed13fff]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      e4c72966
    • Bjorn Helgaas's avatar
      PCI: Don't add disabled subtractive decode bus resources · d739a099
      Bjorn Helgaas authored
      For a subtractive decode bridge, we previously added and printed all
      resources of the primary bus, even if they were not valid.  In the example
      below, the bridge 00:1c.3 has no windows enabled, so there are no valid
      resources on bus 02.  But since 02:00.0 is subtractive decode bridge, we
      add and print all those invalid resources, which don't really make sense:
      
        pci 0000:00:1c.3: PCI bridge to [bus 02-03]
        pci 0000:02:00.0: PCI bridge to [bus 03] (subtractive decode)
        pci 0000:02:00.0:   bridge window [??? 0x00000000 flags 0x0] (subtractive decode)
      
      Add and print the subtractively-decoded resources only if they are valid.
      
      There's an example in the dmesg log attached to the bugzilla below (but
      this patch doesn't fix the bug reported there).
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=73141Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      d739a099
    • Bjorn Helgaas's avatar
      PCI: Don't print anything while decoding is disabled · 26370fc6
      Bjorn Helgaas authored
      If the console is a PCI device, and we try to print to it while its
      decoding is disabled, the system will hang.  This particular printk hasn't
      caused a problem yet, but it could, so this fixes it.
      
      See also 0ff9514b ("PCI: Don't print anything while decoding is
      disabled").
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      26370fc6
    • Bjorn Helgaas's avatar
      PCI: Don't set BAR to zero if dma_addr_t is too small · 31e9dd25
      Bjorn Helgaas authored
      If a BAR is above 4GB and our dma_addr_t is too small, don't clear the BAR
      to zero: that doesn't disable the BAR, and it makes it more likely that the
      BAR will conflict with things if we turn on the memory enable bit (as we
      will at "out:" if the device was already enabled at the handoff).
      
      We should also print the BAR info and its original size so we can follow
      the process when we try to assign space to it.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      31e9dd25
    • Bjorn Helgaas's avatar
      PCI: Don't convert BAR address to resource if dma_addr_t is too small · 72dc5601
      Bjorn Helgaas authored
      If dma_addr_t is too small to represent the BAR value,
      pcibios_bus_to_resource() will fail, so just remember the BAR size directly
      in the resource.  The resource is already marked UNSET, so we know the
      address isn't valid anyway.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      72dc5601