1. 19 Nov, 2010 3 commits
    • Keith Packard's avatar
      drm/i915: Take advantage of auto-polling CRT hotplug detection on PCH hardware · e7dbb2f2
      Keith Packard authored
      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: default avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      e7dbb2f2
    • Chris Wilson's avatar
      drm/i915/crt: Introduce struct intel_crt · c9a1c4cd
      Chris Wilson authored
      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: default avatarKeith Packard <keithp@kithp.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      c9a1c4cd
    • Chris Wilson's avatar
      drm/i915: Do not hold mutex when faulting in user addresses · 51311d0a
      Chris Wilson authored
      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: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      51311d0a
  2. 15 Nov, 2010 3 commits
  3. 13 Nov, 2010 13 commits
  4. 12 Nov, 2010 21 commits