Skip to content

K
Kernel

openeuler / Kernel
12 个月 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 19 11月, 2010 3 次提交
    • K
      drm/i915: Take advantage of auto-polling CRT hotplug detection on PCH hardware · e7dbb2f2
      由 Keith Packard 提交于 
      Both IBX and CPT have an automatic hotplug detection mode which appears to work reliably enough
that we can dispense with the manual force hotplug trigger stuff. This means that
hotplug detection is as simple as reading the current hotplug register values.

The first time the hotplug detection is activated, the code synchronously waits for a hotplug
sequence in case the hardware hasn't bothered to do a detection cycle since being initialized.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      e7dbb2f2
    • C
      drm/i915/crt: Introduce struct intel_crt · c9a1c4cd
      由 Chris Wilson 提交于 
      We will use this structure in future patches to store CRT specific
information on the encoder.

Split out and tweaked from a patch by Keith Packard.
Signed-off-by: NKeith Packard <keithp@kithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      c9a1c4cd
    • C
      drm/i915: Do not hold mutex when faulting in user addresses · 51311d0a
      由 Chris Wilson 提交于 
      Linus Torvalds found that it was rather trivial to trigger a system
freeze:

  In fact, with lockdep, I don't even need to do the sysrq-d thing: it
  shows the bug as it happens. It's the X server taking the same lock
  recursively.

  Here's the problem:

    =============================================
    [ INFO: possible recursive locking detected ]
    2.6.37-rc2-00012-gbdbd01ac #7
    ---------------------------------------------
    Xorg/2816 is trying to acquire lock:
     (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c626c>] i915_gem_fault+0x50/0x17e

    but task is already holding lock:
     (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a

    other info that might help us debug this:
    2 locks held by Xorg/2816:
     #0:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a
     #1:  (&mm->mmap_sem){++++++}, at: [<ffffffff81022d4f>] page_fault+0x156/0x37b

This recursion was introduced by rearranging the locking to avoid the
double locking on the fast path (4f27b5d and fbd5a26d) and the
introduction of the prefault to encourage the fast paths (b5e4f2b). In
order to undo the problem, we rearrange the code to perform the access
validation upfront, attempt to prefault and then fight for control of the
mutex.  the best case scenario where the mutex is uncontended the
prefaulting is not wasted.
Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      51311d0a
  3. 15 11月, 2010 3 次提交
  5. 14 11月, 2010 6 次提交
  7. 13 11月, 2010 28 次提交