1. 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
  2. 07 10月, 2010 1 次提交
    • D
      drm: don't drop handle reference on unload · dab8dcfa
      Dave Airlie 提交于
      since the handle references are all tied to a file_priv, and when it disappears
      all the handle refs go with it.
      
      The fbcon ones we'd only notice on unload, but the nouveau notifier one
      would would happen on reboot.
      
      nouveau: Reported-by: Marc Dionne <marc.c.dionne@gmail.com>
      nouveau: Tested-by: Marc Dionne <marc.c.dionne@gmail.com>
      i915 unload: Reported-by: Keith Packard <keithp@keithp.com>
      Acked-by: NBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      dab8dcfa
  3. 01 10月, 2010 1 次提交
    • D
      drm/gem: handlecount isn't really a kref so don't make it one. · 29d08b3e
      Dave Airlie 提交于
      There were lots of places being inconsistent since handle count
      looked like a kref but it really wasn't.
      
      Fix this my just making handle count an atomic on the object,
      and have it increase the normal object kref.
      
      Now i915/radeon/nouveau drivers can drop the normal reference on
      userspace object creation, and have the handle hold it.
      
      This patch fixes a memory leak or corruption on unload, because
      the driver had no way of knowing if a handle had been actually
      added for this object, and the fbcon object needed to know this
      to clean itself up properly.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      29d08b3e
  4. 28 9月, 2010 2 次提交
  5. 27 9月, 2010 1 次提交
  6. 24 9月, 2010 1 次提交
  7. 22 9月, 2010 1 次提交
  8. 15 9月, 2010 1 次提交
    • A
      drm/radeon/kms: only warn on mipmap size checks in r600 cs checker (v2) · fe725d4f
      Alex Deucher 提交于
      The texture base address registers are in units of 256 bytes.
      The original CS checker treated these offsets as bytes, so the
      original check was wrong.  I fixed the units in a patch during
      the 2.6.36 cycle, but this ended up breaking some existing
      userspace (probably due to a bug in either userspace texture allocation
      or the drm texture mipmap checker).  So for now, until we come
      up with a better fix, just warn if the mipmap size it too large.
      This will keep existing userspace working and it should be just
      as safe as before when we were checking the wrong units.  These
      are GPU MC addresses, so if they fall outside of the VRAM or
      GART apertures, they end up at the GPU default page, so this should
      be safe from a security perspective.
      
      v2: Just disable the warning.  It just spams the log and there's
      nothing the user can do about it.
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Cc: Jerome Glisse <glisse@freedesktop.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      fe725d4f
  9. 14 9月, 2010 2 次提交
  10. 13 9月, 2010 8 次提交
  11. 07 9月, 2010 2 次提交
  12. 02 9月, 2010 5 次提交
  13. 30 8月, 2010 2 次提交
  14. 27 8月, 2010 2 次提交
  15. 23 8月, 2010 4 次提交
  16. 20 8月, 2010 6 次提交