1. 22 1月, 2015 1 次提交
  2. 30 9月, 2014 1 次提交
  3. 24 9月, 2014 2 次提交
  4. 23 9月, 2014 1 次提交
  5. 19 9月, 2014 1 次提交
  6. 11 9月, 2014 1 次提交
    • B
      PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device · b440bde7
      Bjorn Helgaas 提交于
      Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold),
      normally generates a hot-remove event that unbinds the driver.
      
      Some drivers expect to remain bound to a device even while they power it
      off and back on again.  This can be dangerous, because if the device is
      removed or replaced while it is powered off, the driver doesn't know that
      anything changed.  But some drivers accept that risk.
      
      Add pci_ignore_hotplug() for use by drivers that know their device cannot
      be removed.  Using pci_ignore_hotplug() tells the PCI core that hot-plug
      events for the device should be ignored.
      
      The radeon and nouveau drivers use this to switch between a low-power,
      integrated GPU and a higher-power, higher-performance discrete GPU.  They
      power off the unused GPU, but they want to remain bound to it.
      
      This is a reimplementation of f244d8b6 ("ACPIPHP / radeon / nouveau:
      Fix VGA switcheroo problem related to hotplug") but extends it to work with
      both acpiphp and pciehp.
      
      This fixes a problem where systems with dual GPUs using the radeon drivers
      become unusable, freezing every few seconds (see bugzillas below).  The
      resume of the radeon device may also fail, e.g.,
      
      This fixes problems on dual GPU systems where the radeon driver becomes
      unusable because of problems while suspending the device, as in bug 79701:
      
          [drm] radeon: finishing device.
          radeon 0000:01:00.0: Userspace still has active objects !
          radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free
          ...
          WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]()
          trying to unbind memory from uninitialized GART !
      
      or while resuming it, as in bug 77261:
      
          radeon 0000:01:00.0: ring 0 stalled for more than 10158msec
          radeon 0000:01:00.0: GPU lockup ...
          radeon 0000:01:00.0: GPU pci config reset
          pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1)
          radeon 0000:01:00.0: GPU reset succeeded, trying to resume
          *ERROR* radeon: dpm resume failed
          radeon 0000:01:00.0: Wait for MC idle timedout !
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701Reported-by: NShawn Starr <shawn.starr@rogers.com>
      Reported-by: NJose P. <lbdkmjdf@sharklasers.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Acked-by: NRajat Jain <rajatxjain@gmail.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NDave Airlie <airlied@redhat.com>
      CC: stable@vger.kernel.org	# v3.15+
      b440bde7
  7. 10 9月, 2014 1 次提交
  8. 15 8月, 2014 1 次提交
  9. 11 8月, 2014 1 次提交
    • C
      drm/radeon: add userptr support v8 · f72a113a
      Christian König 提交于
      This patch adds an IOCTL for turning a pointer supplied by
      userspace into a buffer object.
      
      It imposes several restrictions upon the memory being mapped:
      
      1. It must be page aligned (both start/end addresses, i.e ptr and size).
      
      2. It must be normal system memory, not a pointer into another map of IO
      space (e.g. it must not be a GTT mmapping of another object).
      
      3. The BO is mapped into GTT, so the maximum amount of memory mapped at
      all times is still the GTT limit.
      
      4. The BO is only mapped readonly for now, so no write support.
      
      5. List of backing pages is only acquired once, so they represent a
      snapshot of the first use.
      
      Exporting and sharing as well as mapping of buffer objects created by
      this function is forbidden and results in an -EPERM.
      
      v2: squash all previous changes into first public version
      v3: fix tabs, map readonly, don't use MM callback any more
      v4: set TTM_PAGE_FLAG_SG so that TTM never messes with the pages,
          pin/unpin pages on bind/unbind instead of populate/unpopulate
      v5: rebased on 3.17-wip, IOCTL renamed to userptr, reject any unknown
          flags, better handle READONLY flag, improve permission check
      v6: fix ptr cast warning, use set_page_dirty/mark_page_accessed on unpin
      v7: add warning about it's availability in the API definition
      v8: drop access_ok check, fix VM mapping bits
      Signed-off-by: NChristian König <christian.koenig@amd.com>
      Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v4)
      Reviewed-by: Jérôme Glisse <jglisse@redhat.com> (v4)
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      f72a113a
  10. 05 8月, 2014 3 次提交
  11. 22 7月, 2014 1 次提交
  12. 15 7月, 2014 1 次提交
    • O
      drm/radeon: Add radeon <--> amdkfd interface · e28740ec
      Oded Gabbay 提交于
      This patch adds the interface between the radeon driver and the amdkfd driver.
      The interface implementation is contained in radeon_kfd.c and radeon_kfd.h.
      
      The interface itself is represented by a pointer to struct
      kfd_dev. The pointer is located inside radeon_device structure.
      
      All the register accesses that amdkfd need are done using this interface. This
      allows us to avoid direct register accesses in amdkfd proper,  while also
      avoiding locking between amdkfd and radeon.
      
      The single exception is the doorbells that are used in both of the drivers.
      However, because they are located in separate pci bar pages, the danger of
      sharing registers between the drivers is minimal.
      
      Having said that, we are planning to move the doorbells as well to radeon.
      
      v3:
      
      Add interface for sa manager init and fini. The init function will allocate a
      buffer on system memory and pin it to the GART address space via the radeon sa
      manager.
      
      All mappings of buffers to GART address space are done via the radeon sa
      manager. The interface of allocate memory will use the radeon sa manager to sub
      allocate from the single buffer that was allocated during the init function.
      
      Change lower_32/upper_32 calls to use linux macros
      
      Add documentation for the interface
      
      v4:
      
      Change ptr field type in kgd_mem from uint32_t* to void* to match to type that
      is returned by radeon_sa_bo_cpu_addr
      
      v5:
      
      Change format of mqd structure to work with latest KV firmware
      Add support for AQL queues creation to enable working with open-source HSA
      runtime.
      Move generic kfd-->kgd interface and other generic kgd definitions to a generic
      header file that will be used by AMD's radeon and amdgpu drivers
      Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
      e28740ec
  13. 09 7月, 2014 1 次提交
  14. 01 7月, 2014 1 次提交
  15. 10 6月, 2014 3 次提交
  16. 23 4月, 2014 1 次提交
  17. 17 4月, 2014 1 次提交
  18. 08 4月, 2014 1 次提交
  19. 03 4月, 2014 1 次提交
  20. 28 3月, 2014 1 次提交
  21. 25 3月, 2014 1 次提交
  22. 03 3月, 2014 1 次提交
  23. 06 2月, 2014 1 次提交
  24. 30 1月, 2014 1 次提交
  25. 20 1月, 2014 1 次提交
  26. 09 1月, 2014 1 次提交
  27. 24 12月, 2013 1 次提交
  28. 18 12月, 2013 1 次提交
  29. 13 12月, 2013 1 次提交
  30. 18 11月, 2013 1 次提交
  31. 06 11月, 2013 1 次提交
  32. 02 11月, 2013 3 次提交
  33. 19 10月, 2013 1 次提交
    • A
      drm/radeon: rework audio option · 108dc8e8
      Alex Deucher 提交于
      In 3.12 I changed audio to be enabled by default,
      but you still had to turn it on via xrandr.  This
      was confusing to users so change it to minic the
      previous behavior:
      
      - audio option is set to -1 (auto) by default which is
        the current 3.12 behavior (audio is enabled but requires
        xrandr to turn it on).
      - if audio = 1, the audio is enabled without needing
        to mess with xrandr (previous behavior)
      - audio = 0 disables audio
      
      It retains the new feature of allowing the user to enable
      audio on the fly with xrandr, but turns audio on
      automatically if radeon.audio=1 is set which is what
      most users expect.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      108dc8e8