An error occurred fetching the project authors.
  1. 12 Oct, 2010 1 commit
    • Jerome Glisse's avatar
      drm/radeon/kms: avoid corner case issue with unmappable vram V2 · c919b371
      Jerome Glisse authored
      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: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      c919b371
  2. 03 Aug, 2010 1 commit
  3. 02 Aug, 2010 2 commits
  4. 16 Jul, 2010 1 commit
    • Alex Deucher's avatar
      drm/radeon/kms: fix gtt MC base alignment on rs4xx/rs690/rs740 asics · 8d369bb1
      Alex Deucher authored
      The asics in question have the following requirements with regard to
      their gart setups:
      
      1. The GART aperture size has to be in the form of 2^X bytes, where X is from 25 to 31
      2. The GART aperture MC base has to be aligned to a boundary equal to the size of the
      aperture.
      3. The GART page table has to be aligned to the boundary equal to the size of the table.
      4. The GART page table size is: table_entry_size * (aperture_size / page_size)
      5. The GART page table has to be allocated in non-paged, non-cached, contiguous system
      memory.
      
      This patch takes care 2.  The rest should already be handled properly.
      
      This fixes a regression noticed by: Torsten Kaiser <just.for.lkml@googlemail.com>
      Tested-by: default avatarTorsten Kaiser <just.for.lkml@googlemail.com>
      Signed-off-by: default avatarAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      8d369bb1
  5. 03 Jun, 2010 1 commit
  6. 01 Jun, 2010 1 commit
  7. 18 May, 2010 5 commits
  8. 19 Apr, 2010 1 commit
  9. 06 Apr, 2010 2 commits
    • Jerome Glisse's avatar
      drm/radeon/kms: simplify & improve GPU reset V2 · 90aca4d2
      Jerome Glisse authored
      This simplify and improve GPU reset for R1XX-R6XX hw, it's
      not 100% reliable here are result:
      - R1XX/R2XX works bunch of time in a row, sometimes it
        seems it can work indifinitly
      - R3XX/R3XX the most unreliable one, sometimes you will be
        able to reset few times, sometimes not even once
      - R5XX more reliable than previous hw, seems to work most
        of the times but once in a while it fails for no obvious
        reasons (same status than previous reset just no same
        happy ending)
      - R6XX/R7XX are lot more reliable with this patch, still
        it seems that it can fail after a bunch (reset every
        2sec for 3hour bring down the GPU & computer)
      
      This have been tested on various hw, for some odd reasons
      i wasn't able to lockup RS480/RS690 (while they use to
      love locking up).
      
      Note that on R1XX-R5XX the cursor will disapear after
      lockup haven't checked why, switch to console and back
      to X will restore cursor.
      
      Next step is to record the bogus command that leaded to
      the lockup.
      
      V2 Fix r6xx resume path to avoid reinitializing blit
      module, use the gpu_lockup boolean to avoid entering
      inifinite waiting loop on fence while reiniting the GPU
      Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      90aca4d2
    • Jerome Glisse's avatar
      drm/radeon/kms: rename gpu_reset to asic_reset · a2d07b74
      Jerome Glisse authored
      Patch rename gpu_reset to asic_reset in prevision of having
      gpu_reset doing more stuff than just basic asic reset.
      Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      a2d07b74
  10. 31 Mar, 2010 3 commits
  11. 30 Mar, 2010 1 commit
  12. 15 Mar, 2010 2 commits
  13. 25 Feb, 2010 1 commit
  14. 18 Feb, 2010 1 commit
    • Jerome Glisse's avatar
      drm/radeon/kms: simplify memory controller setup V2 · d594e46a
      Jerome Glisse authored
      Get rid of _location and use _start/_end also simplify the
      computation of vram_start|end & gtt_start|end. For R1XX-R2XX
      we place VRAM at the same address of PCI aperture, those GPU
      shouldn't have much memory and seems to behave better when
      setup that way. For R3XX and newer we place VRAM at 0. For
      R6XX-R7XX AGP we place VRAM before or after AGP aperture this
      might limit to limit the VRAM size but it's very unlikely.
      For IGP we don't change the VRAM placement.
      
      Tested on (compiz,quake3,suspend/resume):
      PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710
      AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730
      IGP:RS480(RPB*),RS690,RS780(RPB*),RS880
      
      RPB: resume previously broken
      
      V2 correct commit message to reflect more accurately the bug
      and move VRAM placement to 0 for most of the GPU to avoid
      limiting VRAM.
      Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      d594e46a
  15. 11 Feb, 2010 1 commit
  16. 08 Feb, 2010 2 commits
  17. 05 Feb, 2010 1 commit
  18. 08 Jan, 2010 3 commits
  19. 07 Jan, 2010 1 commit
  20. 10 Dec, 2009 1 commit
  21. 08 Dec, 2009 2 commits
  22. 07 Dec, 2009 2 commits
  23. 06 Dec, 2009 1 commit
  24. 04 Dec, 2009 2 commits
  25. 02 Dec, 2009 1 commit
    • Jerome Glisse's avatar
      drm/radeon/kms: Rework radeon object handling · 4c788679
      Jerome Glisse authored
      The locking & protection of radeon object was somewhat messy.
      This patch completely rework it to now use ttm reserve as a
      protection for the radeon object structure member. It also
      shrink down the various radeon object structure by removing
      field which were redondant with the ttm information. Last it
      converts few simple functions to inline which should with
      performances.
      
      airlied: rebase on top of r600 and other changes.
      Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      4c788679