Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 29 6月, 2011 2 次提交
    • C
      drm/i915: Use chipset-specific irq installers · f01c22fd
      由 Chris Wilson 提交于 
      Konstantin Belousov pointed out that 4697995b replaced the generic
i915_driver_irq_*install() functions with chipset specific routines
accessible only through driver->irq_*install(). So update the sanity
check in i915_request_wait() to match.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>
      f01c22fd
    • B
      drm/i915: forcewake fix after reset · 25732821
      由 Ben Widawsky 提交于 
      The failure is as follows:

1. Userspace gets forcewake lock, lock count >=1
2. GPU hang/reset occurs (forcewake bit is reset)
3. count is now incorrect

The failure can only occur when using the forcewake userspace lock.

This has the unfortunate consequence of messing up the driver as well as
userspace, unless userspace closes the debugfs file, the kernel will
never end up waking the GT since the refcount will be > 1.

The solution is to try to recover the correct forcewake state based on
the refcount. There is a period of time where userspace reads/writes may
occur after the reset, before the GT has been forcewaked. The interface
was never designed to be a perfect solution for userspace reads/writes,
and the kernel portion is fixed by this patch.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>
      25732821
  3. 28 6月, 2011 1 次提交
  5. 27 6月, 2011 2 次提交
  7. 25 6月, 2011 1 次提交
  9. 23 6月, 2011 1 次提交
  11. 22 6月, 2011 3 次提交
  13. 21 6月, 2011 1 次提交
  15. 20 6月, 2011 4 次提交
  17. 18 6月, 2011 5 次提交
  19. 17 6月, 2011 11 次提交
  21. 16 6月, 2011 7 次提交
  23. 14 6月, 2011 2 次提交
    • T
      drm: Compare only lower 32 bits of framebuffer map offsets · 66aa6962
      由 Tormod Volden 提交于 
      Drivers using multiple framebuffers got broken by commit
41c2e75e which ignored the framebuffer
(or register) map offset when looking for existing maps. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real offsets could not always be handed over for comparison.

Instead of ignoring the offset we will compare the lower 32 bit. Drivers
using multiple framebuffers should just make sure that the lower 32 bit
are different. The existing drivers in question are practically limited
to 32-bit systems so that should be fine for them.

It is assumed that current drivers always specify a correct framebuffer
map offset, even if this offset was ignored since above commit. So this
patch should not change anything for drivers using only one framebuffer.

Drivers needing multiple framebuffers with 64-bit map offsets will need
to cook up something, for instance keeping an ID in the lower bit which
is to be aligned away when it comes to using the offset.

All of above applies to _DRM_REGISTERS as well.
Signed-off-by: NTormod Volden <debian.tormod@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      66aa6962
    • J
      drm/i915: Don't leak in i915_gem_shmem_pread_slow() · b65552f0
      由 Jesper Juhl 提交于 
      It seems to me that we are leaking 'user_pages' in
drivers/gpu/drm/i915/i915_gem.c::i915_gem_shmem_pread_slow() if
read_cache_page_gfp() fails.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      b65552f0