1. 20 10月, 2012 2 次提交
  2. 18 10月, 2012 1 次提交
    • R
      drm/i915: Insert i915_preliminary_hw_support variable. · 0a3af268
      Rodrigo Vivi 提交于
      On the worst scenario, users with new hardwares and old kernel from
      enabling times can get black screens.  So, from now on, this
      perliminary_hw_support module parameter shall be used by all upcoming
      platforms that are still under enabling. The second option would be to
      merge the pci ids after basic modeset works, but that makes testing
      and development while bringing up hw a rather tedious afair.
      
      Although it is uncomfortable for developers use this extra variable it
      brings more stability for end users.
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      Reviewed-by: NDave Airlie <airlied@redhat.com>
      [danvet: dropped the i915_ param prefix, i915.i915_ is just tedious.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0a3af268
  3. 17 10月, 2012 1 次提交
  4. 16 10月, 2012 5 次提交
  5. 12 10月, 2012 8 次提交
  6. 09 10月, 2012 1 次提交
  7. 08 10月, 2012 1 次提交
    • W
      drm/i915: remove useless BUG_ON which caused a regression in 3.5. · c77d7162
      Willy Tarreau 提交于
      starting an old X server causes a kernel BUG since commit 1b50247a:
      
      ------------[ cut here ]------------
      kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3661!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss uvcvideo
      +videobuf2_core videodev videobuf2_vmalloc videobuf2_memops uhci_hcd ath9k mac80211 snd_hda_codec_realtek ath9k_common microcode
      +ath9k_hw psmouse serio_raw sg ath cfg80211 atl1c lpc_ich mfd_core ehci_hcd snd_hda_intel snd_hda_codec snd_hwdep snd_pcm rtc_cmos
      +snd_timer snd evdev eeepc_laptop snd_page_alloc sparse_keymap
      
      Pid: 2866, comm: X Not tainted 3.5.6-rc1-eeepc #1 ASUSTeK Computer INC. 1005HA/1005HA
      EIP: 0060:[<c12dc291>] EFLAGS: 00013297 CPU: 0
      EIP is at i915_gem_entervt_ioctl+0xf1/0x110
      EAX: f5941df4 EBX: f5940000 ECX: 00000000 EDX: 00020000
      ESI: f5835400 EDI: 00000000 EBP: f51d7e38 ESP: f51d7e20
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      CR0: 8005003b CR2: b760e0a0 CR3: 351b6000 CR4: 000007d0
      DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      DR6: ffff0ff0 DR7: 00000400
      Process X (pid: 2866, ti=f51d6000 task=f61af8d0 task.ti=f51d6000)
      Stack:
       00000001 00000000 f5835414 f51d7e84 f5835400 f54f85c0 f51d7f10 c12b530b
       00000001 c151b139 c14751b6 c152e030 00000b32 00006459 00000059 0000e200
       00000001 00000000 00006459 c159ddd0 c12dc1a0 ffffffea 00000000 00000000
      Call Trace:
       [<c12b530b>] drm_ioctl+0x2eb/0x440
       [<c12dc1a0>] ? i915_gem_init+0xe0/0xe0
       [<c1052b2b>] ? enqueue_hrtimer+0x1b/0x50
       [<c1053321>] ? __hrtimer_start_range_ns+0x161/0x330
       [<c10530b3>] ? lock_hrtimer_base+0x23/0x50
       [<c1053163>] ? hrtimer_try_to_cancel+0x33/0x70
       [<c12b5020>] ? drm_version+0x90/0x90
       [<c10ca171>] vfs_ioctl+0x31/0x50
       [<c10ca2e4>] do_vfs_ioctl+0x64/0x510
       [<c10535de>] ? hrtimer_nanosleep+0x8e/0x100
       [<c1052c20>] ? update_rmtp+0x80/0x80
       [<c10ca7c9>] sys_ioctl+0x39/0x60
       [<c1433949>] syscall_call+0x7/0xb
      Code: 83 c4 0c 5b 5e 5f 5d c3 c7 44 24 04 2c 05 53 c1 c7 04 24 6f ef 47 c1 e8 6e e0 fd ff c7 83 38 1e 00 00 00 00 00 00 e9 3f ff ff
      +ff <0f> 0b eb fe 0f 0b eb fe 8d b4 26 00 00 00 00 0f 0b eb fe 8d b6
      EIP: [<c12dc291>] i915_gem_entervt_ioctl+0xf1/0x110 SS:ESP 0068:f51d7e20
      ---[ end trace dd332ec083cbd513 ]---
      
      The crash happens here in i915_gem_entervt_ioctl() :
      
          3659          BUG_ON(!list_empty(&dev_priv->mm.active_list));
          3660          BUG_ON(!list_empty(&dev_priv->mm.flushing_list));
       -> 3661          BUG_ON(!list_empty(&dev_priv->mm.inactive_list));
          3662          mutex_unlock(&dev->struct_mutex);
      
      Quoting Chris :
        "That BUG_ON there is silly and can simply be removed. The check is to
         verify that no batches were submitted to the kernel whilst the UMS/GEM
         client was suspended - to which the BUG_ONs are a crude approximation.
         Furthermore, the checks are too late, since it means we attempted to
         program the hardware whilst it was in an invalid state, the BUG_ONs are
         the least of your concerns at that point."
      
      Note that this regression has been introduced in
      
      commit 1b50247a
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Apr 24 15:47:30 2012 +0100
      
          drm/i915: Remove the list of pinned inactive objects
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      [danvet: Added note about the regressing commit and cc: stable.]
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c77d7162
  8. 05 10月, 2012 1 次提交
  9. 04 10月, 2012 5 次提交
  10. 03 10月, 2012 6 次提交
  11. 02 10月, 2012 2 次提交
    • C
      drm/i915: Flush the pending flips on the CRTC before modification · 5bb61643
      Chris Wilson 提交于
      This was meant to be the purpose of the
      intel_crtc_wait_for_pending_flips() function which is called whilst
      preparing the CRTC for a modeset or before disabling. However, as Ville
      Syrjala pointed out, we set the pending flip notification on the old
      framebuffer that is no longer attached to the CRTC by the time we come
      to flush the pending operations. Instead, we can simply wait on the
      pending unpin work to be finished on this CRTC, knowning that the
      hardware has therefore finished modifying the registers, before proceeding
      with our direct access.
      
      Fixes i-g-t/flip_test on non-pch platforms. pch platforms simply
      schedule the flip immediately when the pipe is disabled, leading
      to other funny issues.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      [danvet: Added i-g-t note and cc: stable]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5bb61643
    • C
      drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a · ac82ea2e
      Chris Wilson 提交于
      A side-effect of commit 7d54a904
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Aug 10 10:18:10 2012 +0100
      
          drm/i915: Apply post-sync write for pipe control invalidates
      
      was that only a request to emit invalidate flush would result in the
      TLB being invalidated (since it requires synchronisation and so incurs a
      performance penalty). However, the stated w/a for hardware contexts is
      that the TLBs must be invalidated prior to a MI_SET_CONTEXT, yet the w/a
      itself did not request the TLBs to be invalidated...
      
      Note this w/a does not prevent the hard system hang I experience when
      using hw contexts (with rc6 enabled) on SNB GT1.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ac82ea2e
  12. 27 9月, 2012 2 次提交
  13. 26 9月, 2012 3 次提交
  14. 24 9月, 2012 1 次提交
  15. 20 9月, 2012 1 次提交