1. 21 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: fix up gt init sequence fallout · 181d1b9e
      Daniel Vetter authored
      The regression fix for gen6+ rps fallout
      
      commit 7dcd2677
      Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Date:   Wed Jul 17 10:22:58 2013 +0400
      
          drm/i915: fix long-standing SNB regression in power consumption after resume
      
      unintentionally also changed the init sequence ordering between
      gt_init and gt_reset - we need to reset BIOS damage like leftover
      forcewake references before we run our own code. Otherwise we can get
      nasty dmesg noise like
      
      [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.
      
      again. Since _reset suggests that we first need to have stuff
      initialized (which isn't the case here) call it sanitze instead.
      
      While at it also block out the rps disable introduced by the above
      commit on ilk: We don't have any knowledge of ilk rps being broken in
      similar ways. And the disable functions uses the default hw state
      which is only read out when we're enabling rps. So essentially we've
      been writing random grabage into that register.
      Reported-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: stable@vger.kernel.org
      Tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      181d1b9e
  2. 20 Jul, 2013 2 commits
  3. 18 Jul, 2013 2 commits
    • Daniel Vetter's avatar
      drm/i915: correctly restore fences with objects attached · 94a335db
      Daniel Vetter authored
      To avoid stalls we delay tiling changes and especially hold of
      committing the new fence state for as long as possible.
      Synchronization points are in the execbuf code and in our gtt fault
      handler.
      
      Unfortunately we've missed that tricky detail when adding proper fence
      restore code in
      
      commit 19b2dbde
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed Jun 12 10:15:12 2013 +0100
      
          drm/i915: Restore fences after resume and GPU resets
      
      The result was that we've restored fences for objects with no tiling,
      since the object<->fence link still existed after resume. Now that
      wouldn't have been too bad since any subsequent access would have
      fixed things up, but if we've changed from tiled to untiled real havoc
      happened:
      
      The tiling stride is stored -1 in the fence register, so a stride of 0
      resulted in all 1s in the top 32bits, and so a completely bogus fence
      spanning everything from the start of the object to the top of the
      GTT. The tell-tale in the register dumps looks like:
      
                       FENCE START 2: 0x0214d001
                       FENCE END 2: 0xfffff3ff
      
      Bit 11 isn't set since the hw doesn't store it, even when writing all
      1s (at least on my snb here).
      
      To prevent such a gaffle in the future add a sanity check for fences
      with an untiled object attached in i915_gem_write_fence.
      
      v2: Fix the WARN, spotted by Chris.
      
      v3: Trying to reuse get_fences looked ugly and obfuscated the code.
      Instead reuse update_fence and to make it really dtrt also move the
      fence dirty state clearing into update_fence.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Stéphane Marchesin <marcheu@chromium.org>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60530
      Cc: stable@vger.kernel.org (for 3.10 only)
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Tested-by: default avatarBjörn Bidar <theodorstormgrade@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      94a335db
    • Daniel Vetter's avatar
      Merge tag 'v3.10' into drm-intel-fixes · 8157ee21
      Daniel Vetter authored
      Backmerge Linux 3.10 to get at
      
      commit 19b2dbde
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed Jun 12 10:15:12 2013 +0100
      
          drm/i915: Restore fences after resume and GPU resets
      
      That commit is not in my current -fixes pile since that's based on my
      -next queue for 3.11. And the above mentioned fix was merged really
      late into 3.10 (and blew up, bad me) so was on a diverging branch.
      
      Option B would have been to rebase my current pile of fixes onto
      Dave's drm-fixes branch. But since some of the patches here are a bit
      tricky I've decided not to void all the testing by moving over the
      entire merge window.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8157ee21
  4. 17 Jul, 2013 3 commits
    • Chris Wilson's avatar
      drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off() · 2e57f47d
      Chris Wilson authored
      In commit e3de42b6
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Fri May 3 19:44:07 2013 +0200
      
          drm/i915: force full modeset if the connector is in DPMS OFF mode
      
      a new function was added that walked over the set of connectors to see
      if any of the currently associated CRTC was switched off. This function
      walked an array of connectors, rather than the array of pointers to
      connectors contained in the drm_mode_set - i.e. it was dereferencing far
      past the end of the first connector. This only becomes an issue if we
      attempt to use a clone mode (i.e. more than one connector per CRTC) such
      that set->num_connectors > 1.
      Reported-by: default avatarTimo Aaltonen <tjaalton@ubuntu.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65927Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Egbert Eich <eich@suse.de>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2e57f47d
    • Daniel Vetter's avatar
      drm/i915: Sanitize shared dpll state · 35c95375
      Daniel Vetter authored
      There seems to be no limit to the amount of gunk the firmware can
      leave behind. Some platforms leave pch dplls on which are not in
      active use at all. The example in the bug report is a Apple Macbook
      Pro.
      
      Note that this escape scrunity of the hw state checker until we've
      tried to use this enabled, but unused pll since we did only check for
      the inverse case of a in-used, but disabled pll.
      
      v2: Add a WARN in the pll state checker which would have caught this
      case.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66952Reported-and-tested-by: default avatarshui yangwei <yangweix.shui@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      35c95375
    • Konstantin Khlebnikov's avatar
      drm/i915: fix long-standing SNB regression in power consumption after resume v2 · 7dcd2677
      Konstantin Khlebnikov authored
      This patch fixes regression in power consumtion of sandy bridge gpu, which
      exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
      it's extremely busy. After that it never reaches rc6 state.
      
      Bug exists since kernel v3.6:
      
      commit b4ae3f22
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Thu Jun 14 11:04:48 2012 -0700
      
          drm/i915: load boot context at driver init time
      
      For some reason RC6 is already enabled at the beginning of resuming process.
      Following initliaztion breaks some internal state and confuses RPS engine.
      This patch disables RC6 at the beginnig of resume and initialization.
      
      I've rearranged initialization sequence, because intel_disable_gt_powersave()
      needs initialized force_wake_get/put and some locks from the dev_priv.
      
      Note: The culprit in the initialization sequence seems to be the write
      to MBCTL added in the above mentioned commit. The first version of
      this patch just held a forcewake reference across the clock gating
      init functions, which seems to have been enought to gather quite a few
      positive test reports. But since that smelled a bit like ad-hoc
      duct-tape v2 now just disables rps/rc6 across the entire hw setup.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
      References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
      References: https://patchwork.kernel.org/patch/2827634/ (patch v1)
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Add note about v1 vs. v2 of this patch and use standard
      layout for the commit citation. Also add the tested-bys from v1 and a
      cc: stable.]
      Cc: stable@vger.kernel.org (Note: tiny conflict due to the addition of
      the backlight lock in 3.11)
      Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> (v1)
      Tested-by: rocko <rockorequin@hotmail.com> (v1)
      Tested-by: JohnMB <johnmbryant@sky.com> (v1)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7dcd2677
  5. 13 Jul, 2013 1 commit
  6. 12 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: fix pfit regression for non-autoscaled resolutions · 21d8a475
      Daniel Vetter authored
      I.e. for letter/pillarboxing. For those cases we need to adjust the
      mode a bit, but Jesse gmch pfit refactoring in
      
      commit 2dd24552
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Thu Apr 25 12:55:01 2013 -0700
      
          drm/i915: factor out GMCH panel fitting code and use for eDP v3
      
      broke that by reordering the computation of the gmch pfit state with
      the block of code that prepared the adjusted mode for it and told the
      modeset core not to overwrite the adjusted mode with default settings.
      
      We might want to switch around the core code to just fill in defaults,
      but this code predates the pipe_config modeset rework. And in the old
      crtc helpers we did not have a suitable spot to do this.
      
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Hans de Bruin <jmdebruin@xmsnet.nl>
      Reported-and-tested-by: default avatarHans de Bruin <jmdebruin@xmsnet.nl>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      21d8a475
  7. 11 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: fix up readout of the lvds dither bit on gen2/3 · 06922821
      Daniel Vetter authored
      It's in the PFIT_CONTROL register, but very much associated with the
      lvds encoder. So move the readout for it (in the case of an otherwise
      disabled pfit) from the pipe to the lvds encoder's get_config
      function.
      
      Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
      output and we've left the dither bit enabled behind us. This can
      happen if the BIOS has set the bit (some seem to unconditionally do
      that, even in the complete absence of an lvds port), but not enabled
      pipe B at boot-up. Then we won't clear the pfit control register since
      we can only touch that if the pfit is associated with our pipe in the
      crtc configuration - we could trample over the pfit state of the other
      pipe otherwise since it's shared. Once pipe B is enabled we notice
      that the 6to8 dither bit is set and complain about the mismatch.
      
      Note that testing indicates that we don't actually need to set this
      bit when the pfit is disabled, dithering on 18bpp panels seems to work
      regardless. But ripping that code out is not something for a bugfix
      meant for -rc kernels.
      
      v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by
      comments from Chris on irc.
      
      v3: Use Chris suggestion to make the control flow in
      i9xx_get_pfit_config easier to understand.
      
      v4: Kill the extra line, spotted by Chris.
      Reported-by: default avatarKnut Petersen <Knut_Petersen@t-online.de>
      Cc: Knut Petersen <Knut_Petersen@t-online.de>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      References: http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.htmlTested-by: default avatarKnut Petersen <Knut_Petersen@t-online.de>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      06922821
  8. 10 Jul, 2013 4 commits
    • Chris Wilson's avatar
      Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs" · 46a0b638
      Chris Wilson authored
      This reverts commit 25ff1195 and the follow on for Valleyview commit 2dc8aae0.
      
      commit 25ff1195
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Apr 4 21:31:03 2013 +0100
      
          drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
      
      commit 2dc8aae0
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed May 22 17:08:06 2013 +0100
      
          drm/i915: Workaround incoherence with fence updates on Valleyview
      
      Jon Bloomfield came up with a plausible explanation and cheap fix
      (drm/i915: Fix incoherence with fence updates on Sandybridge+) for the
      race condition, so lets run with it.
      
      This is a candidate for stable as the old workaround incurs a
      significant cost (calling wbinvd on all CPUs before performing the
      register write) for some workloads as noted by Carsten Emde.
      
      Link: http://lists.freedesktop.org/archives/intel-gfx/2013-June/028819.html
      References: https://www.osadl.org/?id=1543#c7602
      References: https://bugs.freedesktop.org/show_bug.cgi?id=63825Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Carsten Emde <C.Emde@osadl.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      46a0b638
    • Chris Wilson's avatar
      drm/i915: Fix incoherence with fence updates on Sandybridge+ · d18b9619
      Chris Wilson authored
      This hopefully fixes the root cause behind the workaround added in
      
      commit 25ff1195
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Apr 4 21:31:03 2013 +0100
      
          drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
      
      Thanks to further investigation by Jon Bloomfield, he realised that
      the 64-bit register might be broken up by the hardware into two 32-bit
      writes (a problem we have encountered elsewhere). This non-atomicity
      would then cause an issue where a second thread would see an
      intermediate register state (new high dword, old low dword), and this
      register would randomly be used in preference to its own thread register.
      This would cause the second thread to read from and write into a fairly
      random tiled location.  Breaking the operation into 3 explicit 32-bit
      updates (first disable the fence, poke the upper bits, then poke the lower
      bits and enable) ensures that, given proper serialisation between the
      32-bit register write and the memory transfer, that the fence value is
      always consistent.
      
      Armed with this knowledge, we can explain how the previous workaround
      work. The key to the corruption is that a second thread sees an
      erroneous fence register that conflicts and overrides its own. By
      serialising the fence update across all CPUs, we have a small window
      where no GTT access is occurring and so hide the potential corruption.
      This also leads to the conclusion that the earlier workaround was
      incomplete.
      
      v2: Be overly paranoid about the order in which fence updates become
      visible to the GPU to make really sure that we turn the fence off before
      doing the update, and then only switch the fence on afterwards.
      Signed-off-by: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Carsten Emde <C.Emde@osadl.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d18b9619
    • Chris Wilson's avatar
      drm/i915: Fix write-read race with multiple rings · 02978ff5
      Chris Wilson authored
      Daniel noticed a problem where is we wrote to an object with ring A in
      the middle of a very long running batch, then executed a quick batch on
      ring B before a batch that reads from the same object, its obj->ring would
      now point to ring B, but its last_write_seqno would be still relative to
      ring A. This would allow for the user to read from the object before the
      GPU had completed the write, as set_domain would only check that ring B
      had passed the last_write_seqno.
      
      To fix this simply (and inelegantly), we bump the last_write_seqno when
      switching rings so that the last_write_seqno is always relative to the
      current obj->ring.
      
      This fixes igt/tests/gem_write_read_ring_switch.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      [danvet: Add note about the newly created igt which exercises this
      bug.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      02978ff5
    • Guenter Roeck's avatar
      Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" · c11e5f35
      Guenter Roeck authored
      This patch partially reverts commit 36ec8f87 for
      IvyBridge CPUs.
      
      The original commit results in repeated 'Timed out waiting for forcewake old
      ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
      with i7-3770K CPU. It ultimately results in a hangup if the system is highly
      loaded. Reverting the commit for IvyBridge CPUs fixes the issue.
      
      Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since
      this condition can result in secondary issues.
      
      v2: Only revert patch for Ivybridge CPUs
          Issue info message if mt forcewake is disabled on Ivybridge
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c11e5f35
  9. 09 Jul, 2013 4 commits
  10. 04 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: reinit status page registers after gpu reset · 035dc1e0
      Daniel Vetter authored
      This fixes gpu reset on my gm45 - without this patch the bsd thing is
      forever stuck since the seqno updates never reach the status page.
      
      Tbh I have no idea how this ever worked without rewriting the hws
      registers after a gpu reset.
      
      To satisfy my OCD also give the functions a bit more consistent names:
      - Use status_page everywhere, also for the physical addressed one.
      - Use init for the allocation part and setup for the register setup
        part consistently.
      
      Long term I'd really like to share the hw init parts completely
      between gpu reset, resume and driver load, i.e. to call
      i915_gem_init_hw instead of the individual pieces we might need.
      
      v2: Add the missing paragraph to the commit message about what bug
      exactly this patch here fixes.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65495
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarlu hua <huax.lu@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      035dc1e0
  11. 02 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: Don't try to tear down the stolen drm_mm if it's not there · 446f8d81
      Daniel Vetter authored
      Every other place properly checks whether we've managed to set
      up the stolen allocator at boot-up properly, with the exception
      of the cleanup code. Which results in an ugly
      
      *ERROR* Memory manager not clean. Delaying takedown
      
      at module unload time since the drm_mm isn't initialized at all.
      
      v2: While at it check whether the stolen drm_mm is initialized instead
      of the more obscure stolen_base == 0 check.
      
      v3: Fix up the logic. Also we need to keep the stolen_base check in
      i915_gem_object_create_stolen_for_preallocated since that can be
      called before stolen memory is fully set up. Spotted by Chris Wilson.
      
      v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
      the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
      allocatot must already be initialized when calling that function (if
      we indeed have stolen memory).
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Tested-by: lu hua <huax.lu@intel.com> (v3)
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      446f8d81
  12. 01 Jul, 2013 19 commits