Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 21 12月, 2011 6 次提交
  3. 01 12月, 2011 1 次提交
  5. 04 11月, 2011 2 次提交
  7. 01 11月, 2011 1 次提交
  9. 18 10月, 2011 2 次提交
  11. 23 9月, 2011 1 次提交
  13. 19 9月, 2011 2 次提交
  15. 14 9月, 2011 1 次提交
  17. 06 9月, 2011 1 次提交
  19. 17 3月, 2011 1 次提交
  21. 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
  23. 13 3月, 2011 1 次提交
  25. 01 3月, 2011 1 次提交
  27. 23 2月, 2011 2 次提交
  29. 17 2月, 2011 1 次提交
  31. 14 2月, 2011 2 次提交
  33. 27 1月, 2011 1 次提交
  35. 24 1月, 2011 1 次提交
  37. 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
  39. 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
  41. 26 11月, 2010 1 次提交
  43. 22 11月, 2010 2 次提交
  45. 09 11月, 2010 1 次提交
  47. 28 10月, 2010 1 次提交
  49. 26 10月, 2010 1 次提交
  51. 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
  53. 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
  55. 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