1. 03 5月, 2016 1 次提交
  2. 30 3月, 2016 1 次提交
  3. 28 2月, 2016 1 次提交
    • O
      drm/radeon: Return -EPROBE_DEFER when amdkfd not loaded · 412c8f7d
      Oded Gabbay 提交于
      radeon must load only after amdkfd's loading has been completed. If that
      is not enforced, then radeon's call into amdkfd's functions will cause a
      kernel BUG.
      
      When radeon and amdkfd are built as kernel modules, that rule is
      enforced by the kernel's modules loading mechanism. When radeon and
      amdkfd are built inside the kernel image, that rule is enforced by
      ordering in the drm Makefile (amdkfd before radeon).
      
      Instead of using drm Makefile ordering, we can now use deferred
      loading as amdkfd now returns -EPROBE_DEFER in kgd2kfd_init() when it is
      not yet loaded.
      
      This patch defers radeon loading by propagating -EPROBE_DEFER to the
      kernel's drivers loading infrastructure. That will put radeon into the
      pending drivers list (see description in dd.c). Once amdkfd is loaded,
      a call to kgd2kfd_init() will return successfully and radeon will be
      able to load.
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      412c8f7d
  4. 09 2月, 2016 1 次提交
  5. 03 12月, 2015 1 次提交
  6. 06 10月, 2015 1 次提交
    • T
      drm/irq: Use unsigned int pipe in public API · 88e72717
      Thierry Reding 提交于
      This continues the pattern started in commit cc1ef118 ("drm/irq:
      Make pipe unsigned and name consistent"). This is applied to the public
      APIs and driver callbacks, so pretty much all drivers need to be updated
      to match the new prototypes.
      
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Jianwei Wang <jianwei.wang.chn@gmail.com>
      Cc: Alison Wang <alison.wang@freescale.com>
      Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Philipp Zabel <p.zabel@pengutronix.de>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Mark Yao <mark.yao@rock-chips.com>
      Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
      Cc: Vincent Abriou <vincent.abriou@st.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      88e72717
  7. 25 9月, 2015 1 次提交
  8. 26 5月, 2015 1 次提交
  9. 09 4月, 2015 1 次提交
  10. 20 3月, 2015 3 次提交
  11. 22 1月, 2015 1 次提交
  12. 30 9月, 2014 1 次提交
  13. 24 9月, 2014 2 次提交
  14. 23 9月, 2014 1 次提交
  15. 19 9月, 2014 1 次提交
  16. 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
  17. 10 9月, 2014 1 次提交
  18. 15 8月, 2014 1 次提交
  19. 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
  20. 05 8月, 2014 3 次提交
  21. 22 7月, 2014 1 次提交
  22. 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
  23. 09 7月, 2014 1 次提交
  24. 01 7月, 2014 1 次提交
  25. 10 6月, 2014 3 次提交
  26. 23 4月, 2014 1 次提交
  27. 17 4月, 2014 1 次提交
  28. 08 4月, 2014 1 次提交
  29. 03 4月, 2014 1 次提交
  30. 28 3月, 2014 1 次提交
  31. 25 3月, 2014 1 次提交
  32. 03 3月, 2014 1 次提交
  33. 06 2月, 2014 1 次提交