1. 07 1月, 2011 2 次提交
  2. 06 1月, 2011 2 次提交
  3. 05 1月, 2011 2 次提交
  4. 23 11月, 2010 3 次提交
  5. 22 11月, 2010 2 次提交
  6. 18 11月, 2010 1 次提交
  7. 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
  8. 06 10月, 2010 4 次提交
  9. 02 9月, 2010 1 次提交
  10. 30 8月, 2010 1 次提交
  11. 10 8月, 2010 1 次提交
    • A
      drm/radeon/kms: unify i2c handling · f376b94f
      Alex Deucher 提交于
      Previously we added i2c buses as needed when enumerating connectors
      power management, etc.  This only exposed the actual buses used and
      could have lead to the same buse getting created more than once if
      one buses was used for more than one purpose.  This patch sets up
      all i2c buses on the card in one place and users of the buses just
      point back to the one instance.
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      f376b94f
  12. 04 8月, 2010 1 次提交
  13. 02 8月, 2010 6 次提交
  14. 16 7月, 2010 1 次提交
    • A
      drm/radeon/kms: fix gtt MC base alignment on rs4xx/rs690/rs740 asics · 8d369bb1
      Alex Deucher 提交于
      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: NTorsten Kaiser <just.for.lkml@googlemail.com>
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      8d369bb1
  15. 01 7月, 2010 2 次提交
    • R
      DRM / radeon / KMS: Fix hibernation regression related to radeon PM (was: Re:... · 3f53eb6f
      Rafael J. Wysocki 提交于
      DRM / radeon / KMS: Fix hibernation regression related to radeon PM (was: Re: [Regression, post-2.6.34] Hibernation broken on machines with radeon/KMS and r300)
      
      There is a regression from 2.6.34 related to the recent radeon power
      management changes, caused by attempting to cancel a delayed work
      item that's never been scheduled.  However, the code as is has some
      other issues potentially leading to visible problems.
      
      First, the mutex around cancel_delayed_work() in radeon_pm_suspend()
      doesn't really serve any purpose, because cancel_delayed_work() only
      tries to delete the work's timer.  Moreover, it doesn't prevent the
      work handler from running, so the handler can do some wrong things if
      it wins the race and in that case it will rearm itself to do some
      more wrong things going forward.  So, I think it's better to wait for
      the handler to return in case it's already been queued up for
      execution.  Also, it should be prevented from rearming itself in that
      case.
      
      Second, in radeon_set_pm_method() the cancel_delayed_work() is not
      sufficient to prevent the work handler from running and queing up
      itself for the next run (the failure scenario is that
      cancel_delayed_work() returns 0, so the handler is run, it waits on
      the mutex and then rearms itself after the mutex has been released),
      so again the work handler should be prevented from rearming itself in
      that case..
      
      Finally, there's a potential deadlock in radeon_pm_fini(), because
      cancel_delayed_work_sync() is called under rdev->pm.mutex, but the
      work handler tries to acquire the same mutex (if it wins the race).
      
      Fix the issues described above.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3f53eb6f
    • A
      drm/radeon/kms/igp: fix possible divide by 0 in bandwidth code (v2) · f892034a
      Alex Deucher 提交于
      Some IGP systems specify the system memory clock in the Firmware
      table rather than the IGP info table.  Check both and make sure
      we have a value system memory clock value.
      
      v2: make sure rs690_pm_info is called on rs780/rs880 as well.
      
      fixes a regression since 07d4190327b02ab3aaad25a2d168f79d92e8f8c2.
      Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Tested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      f892034a
  16. 08 6月, 2010 2 次提交
  17. 03 6月, 2010 1 次提交
  18. 24 5月, 2010 1 次提交
  19. 21 5月, 2010 1 次提交
  20. 18 5月, 2010 5 次提交