1. 21 12月, 2011 1 次提交
  2. 01 12月, 2011 1 次提交
  3. 04 11月, 2011 2 次提交
  4. 01 11月, 2011 1 次提交
  5. 18 10月, 2011 2 次提交
  6. 23 9月, 2011 1 次提交
  7. 19 9月, 2011 2 次提交
  8. 14 9月, 2011 1 次提交
  9. 06 9月, 2011 1 次提交
  10. 17 3月, 2011 1 次提交
  11. 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
  12. 13 3月, 2011 1 次提交
  13. 01 3月, 2011 1 次提交
  14. 23 2月, 2011 2 次提交
  15. 17 2月, 2011 1 次提交
  16. 14 2月, 2011 2 次提交
  17. 27 1月, 2011 1 次提交
  18. 24 1月, 2011 1 次提交
  19. 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
  20. 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
  21. 26 11月, 2010 1 次提交
  22. 22 11月, 2010 2 次提交
  23. 09 11月, 2010 1 次提交
  24. 28 10月, 2010 1 次提交
  25. 26 10月, 2010 1 次提交
  26. 12 10月, 2010 1 次提交
    • J
      drm/radeon/kms: avoid corner case issue with unmappable vram V2 · c919b371
      Jerome Glisse 提交于
      We should not allocate any object into unmappable vram if we
      have no means to access them which on all GPU means having the
      CP running and on newer GPU having the blit utility working.
      
      This patch limit the vram allocation to visible vram until
      we have acceleration up and running.
      
      Note that it's more than unlikely that we run into any issue
      related to that as when acceleration is not woring userspace
      should allocate any object in vram beside front buffer which
      should fit in visible vram.
      
      V2 use real_vram_size as mc_vram_size could be bigger than
         the actual amount of vram
      
      [airlied: fixup r700_cp_stop case]
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      c919b371
  27. 06 10月, 2010 1 次提交
    • A
      drm/radeon/kms: enable writeback (v2) · 724c80e1
      Alex Deucher 提交于
      When writeback is enabled, the GPU shadows writes to certain
      registers into a buffer in memory.  The driver can then read
      the values from the shadow rather than reading back from the
      register across the bus.  Writeback can be disabled by setting
      the no_wb module param to 1.
      
      On r6xx/r7xx/evergreen, the following registers are shadowed:
      - CP scratch registers
      - CP read pointer
      - IH write pointer
      On r1xx-rr5xx, the following registers are shadowed:
      - CP scratch registers
      - CP read pointer
      
      v2:
      - Combine wb patches for r6xx-evergreen and r1xx-r5xx
      - Writeback is disabled on AGP boards since it tends to be
      unreliable on AGP using the gart.
      - Check radeon_wb_init return values properly.
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      724c80e1
  28. 13 9月, 2010 2 次提交
    • M
      drm/radeon/kms: fix the colorbuffer CS checker for r300-r500 · a41ceb1c
      Marek Olšák 提交于
      This commit fixes bogus CS rejection if it contains a sequence
      of the following operations:
      
      - Set the color buffer 0. track->cb[i].robj becomes non-NULL.
      - Render.
      - Set a larger zbuffer than the previously-set color buffer.
      - Set a larger scissor area as well.
      - Set the color channel mask to 0 to do depth-only rendering.
      - Render. --> rejected, because track->cb[i].robj remained non-NULL,
        therefore the conditional checking for the color channel mask and
        friends is not performed, and the larger scissor area causes
        the rejection.
      
      This fixes bugs:
      - https://bugs.freedesktop.org/show_bug.cgi?id=29762
      - https://bugs.freedesktop.org/show_bug.cgi?id=28869
      And maybe some others which seem to look the same.
      
      If possible, this commit should go to stable as well.
      Signed-off-by: NMarek Olšák <maraeo@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      a41ceb1c
    • M
      drm/radeon/kms: increase lockup detection interval to 10 sec for r100-r500 · ec00efb7
      Marek Olšák 提交于
      One subtest of mesa/demos/gltestperf takes 9 seconds to complete,
      so to prevent an unnecessary gpu reset followed by a hardlock, I am
      increasing the interval to 10 seconds after which a GPU is considered
      in a locked-up state. This is on RV530. However, with a little slower GPU,
      we would surpass the interval easily, so this is not a good fix
      for gltestperf.
      
      Nevertheless, this commit also fixes hardlocks in the applications which
      render at speed of less than 1 frame per second, where the whole frame
      consists of only one command stream. The game Tiny & Big is an example.
      This bar is now lowered to 0.1 fps.
      
      Now the question comes down to whether we should (often unsuccessfully)
      reset the GPU at all? Once we have stable enough drivers, we won't have to.
      Has the time come already?
      
      If possible, this commit should go to stable as well.
      Signed-off-by: NMarek Olšák <maraeo@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      ec00efb7
  29. 02 8月, 2010 4 次提交
  30. 22 7月, 2010 1 次提交
    • D
      drm/radeon/kms: drop taking lock around crtc lookup. · 29508eb6
      Dave Airlie 提交于
      We only add/remove crtcs at driver load, you cannot remove when
      the GPU is running a CS packet since the fd is open, when
      GPU hotplugging on radeons actually is needed all this locking
      needs a review and I've started re-working kms core locking to deal
      with this better. But for now avoid long delays in CS processing when
      hotplug detect is happening in a different thread.
      
      this fixes a regression introduced with hotplug detection.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      29508eb6