1. 16 Oct, 2012 4 commits
    • Egbert Eich's avatar
      DRM/i915: Restore sdvo_flags after dtd->mode->dtd Roundrtrip. · e751823d
      Egbert Eich authored
      For TV and LVDS encoders intel_sdvo_set_input_timings_for_mode()
      is called to pass a mode to the sdvo chip and retrieve a dtd
      containing information needed to calculate the adjusted_mode which
      is done by intel_sdvo_get_dtd_from_mode().
      To set this adjusted_mode as input mode for the sdvo chip, a dtd is
      recalculated using intel_sdvo_get_mode_from_dtd(). During this round
      trip the sdvo_flags contained in the dtd obtained from the hardware
      are lost.
      Since these flags cannot be ignored in all cases this patch preserves
      and restores them.
      
      This regression has been introduced in
      
      commit 6651819b
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sun Apr 1 19:16:18 2012 +0200
      
          drm/i915: handle input/output sdvo timings separately in mode_set
      Signed-off-by: default avatarEgbert Eich <eich@suse.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e751823d
    • Egbert Eich's avatar
      DRM/i915: Don't clone SDVO LVDS with analog. · e3b86d69
      Egbert Eich authored
      SDVO LVDS are not clonable as the input mode gets adjusted by
      the LVDS encoder.
      Signed-off-by: default avatarEgbert Eich <eich@suse.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e3b86d69
    • Egbert Eich's avatar
      DRM/i915: Add QUIRK_INVERT_BRIGHTNESS for NCR machines. · 5f85f176
      Egbert Eich authored
      NCR machines with LVDS panels using Intel chipsets need to have the
      QUIRK_INVERT_BRIGHTNESS bit set.
      Unfortunately NCR doesn't set a meaningful subvendor/subdevice ID,
      therefore we add a DMI dependent quirk list.
      Signed-off-by: default avatarEgbert Eich <eich@suse.de>
      [danvet: fixup whitespace fail.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5f85f176
    • Egbert Eich's avatar
      DRM/i915: Don't delete DPLL Multiplier during DAC init. · 6478d414
      Egbert Eich authored
      The DPLL multipiler is set up in intel_display.c:i9xx_update_pll()
      called from i9xx_crtc_mode_set().
      There the DPLL multiplier is adjusted so that the SDVO gets a sufficient
      bus clock.
      When cloning a CRTC between an SDVO driven encoder and the standard
      DAC the DAC setup code reseted the multiplier value to 1 thus undoing
      the correct setup. There is no need to touch the multiplier in the DAC
      setup code: the correct value (i.e. 1 in case no SDVO encoder is used)
      is set by i9xx_update_pll() already.
      A comment at the code suggested that this code is a left over from the
      days when there was no setup for clone modes.
      Signed-off-by: default avatarEgbert Eich <eich@suse.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6478d414
  2. 12 Oct, 2012 9 commits
  3. 08 Oct, 2012 1 commit
  4. 07 Oct, 2012 1 commit
    • Willy Tarreau's avatar
      drm/i915: remove useless BUG_ON which caused a regression in 3.5. · c77d7162
      Willy Tarreau authored
      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: default avatarWilly Tarreau <w@1wt.eu>
      [danvet: Added note about the regressing commit and cc: stable.]
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c77d7162
  5. 04 Oct, 2012 6 commits
  6. 03 Oct, 2012 1 commit
  7. 02 Oct, 2012 8 commits
  8. 27 Sep, 2012 2 commits
  9. 26 Sep, 2012 3 commits
  10. 24 Sep, 2012 3 commits
    • Daniel Vetter's avatar
      Merge tag 'v3.6-rc7' into drm-intel-next-queued · 398b7a1b
      Daniel Vetter authored
      Manual backmerge of -rc7 to resolve a silent conflict leading to
      compile failure in drivers/gpu/drm/i915/intel_hdmi.c.
      
      This is due to the bugfix in -rc7:
      
      commit b98b6016
      Author: Wang Xingchao <xingchao.wang@intel.com>
      Date:   Thu Sep 13 07:43:22 2012 +0800
      
          drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
      
      Since this code moved around a lot in -next git put that snippet at
      the wrong spot. I've tried to fix this by making the conflict explicit
      by merging a version for next with:
      
      commit 3cce574f
      Author: Wang Xingchao <xingchao.wang@intel.com>
      Date:   Thu Sep 13 11:19:00 2012 +0800
      
          drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally
      
      But that failed to solve the entire problem. To avoid pushing out
      further -nightly branch to our QA where this is broken, do the
      backmerge and manually add the stuff git adds to -next from the patch
      in -fixes.
      
      Note that this doesn't show up in git's merge diff (and hence is also
      not handled by git rerere), which adds to the reasons why I'd like to
      fix this with a verbose backmerge. The git merge diff only shows a
      bunch of trivial conflicts of the "code changed in lines next to each
      another" kind.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      398b7a1b
    • Paulo Zanoni's avatar
      drm/i915: BUG() on unexpected HDMI register · 57df2ae9
      Paulo Zanoni authored
      This should never happen, but the silent "return" makes me wonder
      every time I try to debug InfoFrame bugs, so promote this to BUG() to
      make sure people will complain if we ever break this.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      57df2ae9
    • Linus Torvalds's avatar
      Linux 3.6-rc7 · 979570e0
      Linus Torvalds authored
      979570e0
  11. 23 Sep, 2012 2 commits