1. 19 Mar, 2014 2 commits
  2. 12 Mar, 2014 3 commits
    • Daniel Vetter's avatar
      drm/i915: Don't enable display error interrupts from the start · 5c673b60
      Daniel Vetter authored
      We need to enable interrupt processing before all the modeset
      state is set up. But that means we can fall over when we get a pipe
      underrun. This shouldn't happen as long as the bios works correctly
      but as usual this turns out to be wishful thinking.
      
      So disable error interrupts at irq install time and rely on the
      re-enabling code in the modeset functions to take care of this.
      
      Note that due to the SDE interrupt handling race we must
      uncondtionally enable all interrupt sources in SDEIER, hence no need
      to enable the SERR bit specifically.
      
      On gmch platforms we don't have an explicit enable/mask bit for fifo
      underruns. Fixing this up would require a bit of software tracking,
      hence is material for a separate patch. To make this possible we need
      to switch all gmch platforms to the new pipestat interrupt handling
      scheme Imre implemented for vlv, and then also add a safe form of sw
      state checking to __cpu_fifo_underrun_reporting_enabled a bit.
      
      v2: Also handle the ilk/snb cpu fifo underrun bits accordingly.
      Spotted by Ville.
      
      v3: Also handle the south interrupt underrun bits on ibx. Again
      spotted by Ville.
      Reported-by: default avatarRob Clark <robdclark@gmail.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: stable@vger.kernel.org
      Tested-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      5c673b60
    • Ville Syrjälä's avatar
      drm/i915: Fix scanline counter fixup on BDW · 24302624
      Ville Syrjälä authored
      The display interrupts changed on BDW, so the current ILK-HSW specific
      code in ilk_pipe_in_vblank_locked() doesn't work there. Add the required
      bits for BDW, and while at it, change the existing code to use nicer
      looking vblank status bit macros.
      
      Also remove the now stale __raw_i915_read16() definition which was
      left over from the failed gen2 ISR experiment.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73962Tested-by: default avatarLu Hua <huax.lu@intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      24302624
    • Ville Syrjälä's avatar
      drm/i915: Add a workaround for HSW scanline counter weirdness · fcb81823
      Ville Syrjälä authored
      On HSW the scanline counter seems to behave differently depending on
      the output type. eDP on port A does what you would expect an the normal
      +1 fixup is sufficient to cover it. But on HDMI outputs we seem to need
      a +2 fixup. Just assume we always need the +2 fixup and accept the
      slight inaccuracy on eDP.
      
      This fixes a regression introduced in:
       commit 8072bfa6
       Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
       Date:   Mon Oct 28 21:22:52 2013 +0200
      
          drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()
      
      That commit removed the heuristic that tried to fix up the timestamps
      for vblank interrupts that fire a bit too early. Since then the vblank
      timestamp code would treat some vblank interrupts as spurious since the
      scanline counter would indicate that vblank_start wasn't reached yet.
      That in turn lead to incorrect vblank event sequence numbers being
      reported to userspace, which lead to unsteady framerate in applications
      such as XBMC which uses them for timing purposes.
      
      v2: Remember to call ilk_pipe_in_vblank_locked() on HSW too (Mika)
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75725
      Tested-by: bugzilla1@gmx.com
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      fcb81823
  3. 06 Mar, 2014 1 commit
    • Ben Widawsky's avatar
      drm/i915: Fix PSR programming · 24bd9bf5
      Ben Widawsky authored
      | has a higher precedence than ?. Therefore, the calculation doesn't do
      at all what you would expect. Thanks to Ken for convincing me that this
      was indeed the issue. Send me back to C programmer school, please.
      
      I'm sort of surprised PSR was continuing to work for people. It should
      be broken IMO (and it was broken for me, but I had assumed it never
      worked).
      
      Regression from:
      commit ed8546ac
      Author: Ben Widawsky <benjamin.widawsky@intel.com>
      Date:   Mon Nov 4 22:45:05 2013 -0800
      
          drm/i915/bdw: Support eDP PSR
      
      Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
      Cc: Kenneth Graunke <kenneth.w.graunke@intel.com>
      Cc: Art Runyan <arthur.j.runyan@intel.com>
      Reported-by: default avatar"Kumar, Kiran S" <kiran.s.kumar@intel.com>
      Cc: stable@vger.kernel.org [v3.13+]
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      24bd9bf5
  4. 03 Mar, 2014 7 commits
    • Ville Syrjälä's avatar
      drm/i915: Reject >165MHz modes w/ DVI monitors · 6375b768
      Ville Syrjälä authored
      Single-link DVI max dotclock is 165MHz. Filter out modes with higher
      dotclock when the monitor doesn't support HDMI.
      
      Modes higher than 165 MHz were allowed in
      
      commit 7d148ef5
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Mon Jul 22 18:02:39 2013 +0200
      
          drm/i915: fix hdmi portclock limits
      
      Also don't attempt to use 12bpc mode with DVI monitors.
      
      Cc: Adam Nielsen <a.nielsen@shikadi.net>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75345
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70331Tested-by: default avatarRalf Jung <post+kernel@ralfj.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      6375b768
    • Paulo Zanoni's avatar
      drm/i915: fix assert_cursor on BDW · d9d82081
      Paulo Zanoni authored
      We need to read the correct register, not a register that doesn't exist
      and will trigger "Unclaimed register" messages when we touch it.
      
      Also rearrange the checks in an attempt to prevent this error from
      happening again.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      [Jani: dropped an extra empty line introduced.]
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      d9d82081
    • Imre Deak's avatar
      drm/i915: vlv: reserve GT power context early · 17b0c1f7
      Imre Deak authored
      We reserve the space for the power context in stolen memory at a fixed
      address from a delayed work. This races with the subsequent driver
      init/resume code which could allocate something at that address, so the
      reservation for the power context fails. Reserve the space up-front, so
      this can't happen. This also adds a missing struct_mutex lock around the
      stolen allocation, which wasn't taken in the delayed work path.
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      17b0c1f7
    • Imre Deak's avatar
      drm/i915: fix pch pci device enumeration · bcdb72ac
      Imre Deak authored
      pci_get_class(class, from) drops the refcount for 'from', so the
      extra pci_dev_put we do on it will result in a use after free bug
      starting with the WARN below.
      
      Regression introduced in
      
      commit 6a9c4b35
      Author: Rui Guo <firemeteor@users.sourceforge.net>
      Date:   Wed Jun 19 21:10:23 2013 +0800
      
          drm/i915: Fix PCH detect with multiple ISA bridges in VM
      
      [  164.338460] WARNING: CPU: 1 PID: 2094 at include/linux/kref.h:47 klist_next+0xae/0x110()
      [  164.347731] CPU: 1 PID: 2094 Comm: modprobe Tainted: G           O 3.13.0-imre+ #354
      [  164.356468] Hardware name: Intel Corp. VALLEYVIEW B0 PLATFORM/NOTEBOOK, BIOS BYTICRB1.X64.0062.R70.1310112051 10/11/2013
      [  164.368796] Call Trace:
      [  164.371609]  [<ffffffff816a32a6>] dump_stack+0x4e/0x7a
      [  164.377447]  [<ffffffff8104f75d>] warn_slowpath_common+0x7d/0xa0
      [  164.384238]  [<ffffffff8104f83a>] warn_slowpath_null+0x1a/0x20
      [  164.390851]  [<ffffffff8169aeae>] klist_next+0xae/0x110
      [  164.396777]  [<ffffffff8130a110>] ? pci_do_find_bus+0x70/0x70
      [  164.403286]  [<ffffffff813cb4a9>] bus_find_device+0x89/0xc0
      [  164.409719]  [<ffffffff8130a373>] pci_get_dev_by_id+0x63/0xa0
      [  164.416238]  [<ffffffff8130a4e4>] pci_get_class+0x44/0x50
      [  164.422433]  [<ffffffffa034821f>] intel_dsm_detect+0x16f/0x1f0 [i915]
      [  164.429801]  [<ffffffffa03482ae>] intel_register_dsm_handler+0xe/0x10 [i915]
      [  164.437831]  [<ffffffffa02d30fe>] i915_driver_load+0xafe/0xf30 [i915]
      [  164.445126]  [<ffffffff8158a150>] ? intel_alloc_coherent+0x110/0x110
      [  164.452340]  [<ffffffffa0148c07>] drm_dev_register+0xc7/0x150 [drm]
      [  164.459462]  [<ffffffffa014b23f>] drm_get_pci_dev+0x11f/0x1f0 [drm]
      [  164.466554]  [<ffffffff816abb81>] ? _raw_spin_unlock_irqrestore+0x51/0x70
      [  164.474287]  [<ffffffffa02cf7a6>] i915_pci_probe+0x56/0x60 [i915]
      [  164.481185]  [<ffffffff8130a028>] pci_device_probe+0x78/0xf0
      [  164.487603]  [<ffffffff813cd495>] driver_probe_device+0x155/0x350
      [  164.494505]  [<ffffffff813cd74e>] __driver_attach+0x6e/0xa0
      [  164.500826]  [<ffffffff813cd6e0>] ? __device_attach+0x50/0x50
      [  164.507333]  [<ffffffff813cb2be>] bus_for_each_dev+0x6e/0xc0
      [  164.513752]  [<ffffffff813ccefe>] driver_attach+0x1e/0x20
      [  164.519870]  [<ffffffff813cc958>] bus_add_driver+0x138/0x260
      [  164.526289]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
      [  164.532116]  [<ffffffff813cde78>] driver_register+0x98/0xe0
      [  164.538558]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
      [  164.544389]  [<ffffffff813087b0>] __pci_register_driver+0x60/0x70
      [  164.551336]  [<ffffffffa014b37d>] drm_pci_init+0x6d/0x120 [drm]
      [  164.558040]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
      [  164.563928]  [<ffffffffa018806a>] i915_init+0x6a/0x6c [i915]
      [  164.570363]  [<ffffffff810002da>] do_one_initcall+0xaa/0x160
      [  164.576783]  [<ffffffff8103b140>] ? set_memory_nx+0x40/0x50
      [  164.583100]  [<ffffffff810ce7f5>] load_module+0x1fb5/0x2550
      [  164.589410]  [<ffffffff810caab0>] ? store_uevent+0x40/0x40
      [  164.595628]  [<ffffffff810cee7d>] SyS_init_module+0xed/0x100
      [  164.602048]  [<ffffffff816b3c52>] system_call_fastpath+0x16/0x1b
      
      v2: simplify the loop further (Chris)
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Reported-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65652
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74161Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      bcdb72ac
    • Akash Goel's avatar
      drm/i915: Resolving the memory region conflict for Stolen area · 3617dc96
      Akash Goel authored
      There is a conflict seen when requesting the kernel to reserve
      the physical space used for the stolen area. This is because
      some BIOS are wrapping the stolen area in the root PCI bus, but have
      an off-by-one error. As a workaround we retry the reservation with an
      offset of 1 instead of 0.
      
      v2: updated commit message & the comment in source file (Daniel)
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Tested-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      3617dc96
    • Jani Nikula's avatar
      drm/i915: use backlight legacy combination mode also for i915gm/i945gm · b6ab66aa
      Jani Nikula authored
      i915gm and i945gm also seem to use and need the legacy combination mode
      bit in BLC_PWM_CTL.
      
      v2: Also do this for i915gm (Ville).
      Reported-and-tested-by: default avatarLuis Ortega <luiorpe1@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75001Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      b6ab66aa
    • Linus Torvalds's avatar
      Linux 3.14-rc5 · 0414855f
      Linus Torvalds authored
      0414855f
  5. 02 Mar, 2014 15 commits
  6. 01 Mar, 2014 2 commits
  7. 28 Feb, 2014 10 commits