1. 03 6月, 2013 1 次提交
    • A
      radeon: Fix system hang issue when using KMS with older cards · e49f3959
      Adis Hamzić 提交于
      The current radeon driver initialization routines, when using KMS, are written
      so that the IRQ installation routine is called before initializing the WB buffer
      and the CP rings. With some ASICs, though, the IRQ routine tries to access the
      GFX_INDEX ring causing a call to RREG32 with the value of -1 in
      radeon_fence_read. This, in turn causes the system to completely hang with some
      cards, requiring a hard reset.
      
      A call stack that can cause such a hang looks like this (using rv515 ASIC for the
      example here):
       * rv515_init (rv515.c)
       * radeon_irq_kms_init (radeon_irq_kms.c)
       * drm_irq_install (drm_irq.c)
       * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c)
       * rs600_irq_process (rs600.c)
       * radeon_fence_process - due to SW interrupt (radeon_fence.c)
       * radeon_fence_read (radeon_fence.c)
       * hang due to RREG32(-1)
      
      The patch moves the IRQ installation to the card startup routine, after the ring
      has been initialized, but before the IRQ has been set. This fixes the issue, but
      requires a check to see if the IRQ is already installed, as is the case in the
      system resume codepath.
      I have tested the patch on three machines using the rv515, the rv770 and the
      evergreen ASIC. They worked without issues.
      
      This seems to be a known issue and has been reported on several bug tracking
      sites by various distributions (see links below). Most of reports recommend
      booting the system with KMS disabled and then enabling KMS by reloading the
      radeon module. For some reason, this was indeed a usable workaround, however,
      UMS is now deprecated and disabled by default.
      
      Bug reports:
      https://bugzilla.redhat.com/show_bug.cgi?id=845745
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789
      https://bbs.archlinux.org/viewtopic.php?id=156964Signed-off-by: NAdis Hamzić <adis@hamzadis.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      e49f3959
  2. 22 4月, 2013 1 次提交
  3. 03 10月, 2012 1 次提交
  4. 21 9月, 2012 3 次提交
  5. 17 7月, 2012 2 次提交
  6. 21 6月, 2012 2 次提交
  7. 05 6月, 2012 1 次提交
  8. 03 5月, 2012 2 次提交
  9. 24 4月, 2012 1 次提交
  10. 29 2月, 2012 2 次提交
  11. 27 2月, 2012 1 次提交
  12. 22 2月, 2012 1 次提交
  13. 14 2月, 2012 1 次提交
  14. 13 1月, 2012 1 次提交
  15. 06 1月, 2012 1 次提交
  16. 21 12月, 2011 4 次提交
  17. 01 12月, 2011 1 次提交
  18. 04 11月, 2011 2 次提交
  19. 06 9月, 2011 1 次提交
  20. 25 7月, 2011 1 次提交
  21. 12 7月, 2011 1 次提交
  22. 13 4月, 2011 1 次提交
  23. 04 4月, 2011 1 次提交
  24. 14 3月, 2011 1 次提交
    • D
      drm/radeon: fix problem with changing active VRAM size. (v2) · 53595338
      Dave Airlie 提交于
      So we used to use lpfn directly to restrict VRAM when we couldn't
      access the unmappable area, however this was removed in
      93225b0d as it also restricted
      the gtt placements. However it was only later noticed that this
      broke on some hw.
      
      This removes the active_vram_size, and just explicitly sets it
      when it changes, TTM/drm_mm will always use the real_vram_size,
      and the active vram size will change the TTM size used for lpfn
      setting.
      
      We should re-work the fpfn/lpfn to per-placement at some point
      I suspect, but that is too late for this kernel.
      
      Hopefully this addresses:
      https://bugs.freedesktop.org/show_bug.cgi?id=35254
      
      v2: fix reported useful VRAM size to userspace to be correct.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      53595338
  25. 17 2月, 2011 1 次提交
  26. 17 1月, 2011 1 次提交
    • A
      drm/radeon/kms: balance asic_reset functions · 25b2ec5b
      Alex Deucher 提交于
      First, we were calling mc_stop() at the top of the function
      which turns off all MC (memory controller) clients,
      then checking if the GPU is idle.  If it was idle we
      returned without re-enabling the MC clients which would
      lead to a blank screen, etc.  This patch checks if the
      GPU is idle before calling mc_stop().
      
      Second, if the reset failed, we were returning without
      re-enabling the MC clients.  This patch re-enables
      the MC clients before returning regardless of whether
      the reset was successful or not.
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      25b2ec5b
  27. 06 1月, 2011 1 次提交
    • T
      drm/radeon: use system_wq instead of dev_priv->wq · 32c87fca
      Tejun Heo 提交于
      With cmwq, there's no reason for radeon to use a dedicated workqueue.
      Drop dev_priv->wq and use system_wq instead.
      
      Because radeon_driver_irq_uninstall_kms() may be called from
      unsleepable context, the work items can't be flushed from there.
      Instead, init and flush from radeon_irq_kms_init/fini().
      
      While at it, simplify canceling/flushing of rdev->pm.dynpm_idle_work.
      Always initialize and sync cancel instead of being unnecessarily smart
      about it.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NAlex Deucher <alexdeucher@gmail.com>
      Cc: dri-devel@lists.freedesktop.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      32c87fca
  28. 22 11月, 2010 2 次提交
  29. 09 11月, 2010 1 次提交