Skip to content

K
Kernel

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

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 07 7月, 2021 1 次提交
    • T
      drm/i915: Use the correct IRQ during resume · 320ad343
      由 Thomas Zimmermann 提交于 
      The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.

Change all calls to synchronize_hardirq() to intel_synchronize_irq(),
which uses the correct interrupt. _hardirq() functions are not needed
in this context.

v5:
	* go back to _hardirq() after PCI probe reported wrong
	  context; add rsp comment
v4:
	* switch everything to intel_synchronize_irq() (Daniel)
v3:
	* also use intel_synchronize_hardirq() at another callsite
v2:
	* wrap irq code in intel_synchronize_hardirq() (Ville)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Fixes: 536f77b1 ("drm/i915/gt: Call stop_ring() from ring resume, again")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210701173618.10718-2-tzimmermann@suse.de
(cherry picked from commit 27e4b467)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      320ad343
  3. 06 6月, 2021 1 次提交
  5. 25 5月, 2021 2 次提交
  7. 25 3月, 2021 5 次提交
  9. 19 1月, 2021 3 次提交
  11. 15 1月, 2021 1 次提交
  13. 14 1月, 2021 3 次提交
  15. 13 1月, 2021 2 次提交
  17. 12 1月, 2021 2 次提交
  19. 10 1月, 2021 1 次提交
  21. 22 12月, 2020 1 次提交
  23. 11 12月, 2020 1 次提交
  25. 01 10月, 2020 1 次提交
  27. 07 9月, 2020 5 次提交
  29. 24 8月, 2020 1 次提交
  31. 09 7月, 2020 2 次提交
  33. 03 6月, 2020 1 次提交
  35. 02 6月, 2020 2 次提交
  37. 30 4月, 2020 1 次提交
    • C
      drm/i915/gt: Keep a no-frills swappable copy of the default context state · be1cb55a
      由 Chris Wilson 提交于 
      We need to keep the default context state around to instantiate new
contexts (aka golden rendercontext), and we also keep it pinned while
the engine is active so that we can quickly reset a hanging context.
However, the default contexts are large enough to merit keeping in
swappable memory as opposed to kernel memory, so we store them inside
shmemfs. Currently, we use the normal GEM objects to create the default
context image, but we can throw away all but the shmemfs file.

This greatly simplifies the tricky power management code which wants to
run underneath the normal GT locking, and we definitely do not want to
use any high level objects that may appear to recurse back into the GT.
Though perhaps the primary advantage of the complex GEM object is that
we aggressively cache the mapping, but here we are recreating the
vm_area everytime time we unpark. At the worst, we add a lightweight
cache, but first find a microbenchmark that is impacted.

Having started to create some utility functions to make working with
shmemfs objects easier, we can start putting them to wider use, where
GEM objects are overkill, such as storing persistent error state.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429172429.6054-1-chris@chris-wilson.co.uk
      be1cb55a
  39. 20 3月, 2020 1 次提交
  41. 19 3月, 2020 1 次提交
  43. 15 3月, 2020 1 次提交
  45. 08 3月, 2020 1 次提交